Hmm, wouldn't a jaxws factory be a good replacement. So plan would be 1. deprecate current impl 2. replace them by CxfFeature native implementations (+ delegation for 1) 3. provide a WSFeature.convert(cxfFeature) factory, also cxf can surely wrap them automatically in its impl.
wdyt? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le ven. 31 mai 2019 à 17:00, Daniel Kulp <[email protected]> a écrit : > > > > On May 31, 2019, at 10:54 AM, Romain Manni-Bucau <[email protected]> > wrote: > > > > Was not thinking to drop it from the parent but more to get soap free > > flavors of cxf features which would then be usable in jaxrs apps without > > any issue. > > In other words we would get a cxf.AbstractCxfFeature used as base for all > > impl and current existing ones would be deprecated and would delegate to > > the new ones. No backward compat issue I think. > > We cannot deprecate them as they would still be required for JAX-WS > users. We then have extra naming issues which can be confusing. > “LoggingFeature” is the jax-ws one, what is the non-jax-ws one called? > Maybe prefix them all with CXF like “CXFLoggingFeature”. > > > > -- > Daniel Kulp > [email protected] <mailto:[email protected]> - http://dankulp.com/blog < > http://dankulp.com/blog> > Talend Community Coder - http://talend.com <http://coders.talend.com/> >
