You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2019/05/31 09:09:57 UTC
Can LoggingFeature not depend on javax.xml.ws?
Hi everyone,
I just realized LoggingFeature depends on javax.xml.ws.WebServiceFeature
Is it possible to drop that dependency in the target to run on java ~11
without javax.xml.ws dependencies?
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>
Re: Can LoggingFeature not depend on javax.xml.ws?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
And it is blue/green (https://builds.apache.org/job/CXF-Trunk-PR/1206/) :)
Le sam. 1 juin 2019 à 10:57, Romain Manni-Bucau <rm...@gmail.com> a
écrit :
> Converted it to a PR -> https://github.com/apache/cxf/pull/561
> For now i'm waiting for some CI feedback but basic mecanism is functional
> :).
>
> 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 à 19:50, Romain Manni-Bucau <rm...@gmail.com> a
> écrit :
>
>> Here is a draft - I didn't rerun the build but wanted to share the idea:
>> https://github.com/rmannibucau/cxf/commit/53c3c7016ce72dab61035a5417a7bba448fc3e43.
>> The pattern is the same for all: add a nested Portable feature which is
>> preferred for jaxrs over jaxws.
>>
>> Do you think we can get a fix for the original soon - this one or another?
>> On my side I'd love to drop jaxws dead dependency ASAP in my apps which
>> are using logging feature and gzip feature.
>>
>> 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 à 18:38, Romain Manni-Bucau <rm...@gmail.com>
>> a écrit :
>>
>>> Created https://issues.apache.org/jira/browse/CXF-8053 to try to
>>> summarize it, feel free to comment/adjust the description if I miss
>>> anything.
>>>
>>> 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 à 18:17, Daniel Kulp <dk...@apache.org> a écrit :
>>>
>>>>
>>>>
>>>> > On May 31, 2019, at 11:09 AM, Romain Manni-Bucau <
>>>> rmannibucau@gmail.com> wrote:
>>>> >
>>>> > Hmm, wouldn't a jaxws factory be a good replacement. So plan would be
>>>>
>>>> I’d prefer not as then you’d have a different programming model for
>>>> jax-ws built in features (MTOMFeature, AddressingFeature) and CXF provided
>>>> features. And of course there is the “it would break everyone’s existing
>>>> code” issue.
>>>>
>>>> Having the JAX-WS versions wrapper/delegate to the native versions
>>>> would be fine and should be mostly seamless. For the most part, there
>>>> aren’t any protected fields or anything that subclasses would be using so
>>>> it should work.
>>>>
>>>> Dan
>>>>
>>>>
>>>>
>>>> > 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 <
>>>> https://twitter.com/rmannibucau>> | Blog
>>>> > <https://rmannibucau.metawerx.net/ <https://rmannibucau.metawerx.net/>>
>>>> | Old Blog
>>>> > <http://rmannibucau.wordpress.com <http://rmannibucau.wordpress.com/>>
>>>> | Github <https://github.com/rmannibucau <
>>>> https://github.com/rmannibucau>> |
>>>> > LinkedIn <https://www.linkedin.com/in/rmannibucau <
>>>> https://www.linkedin.com/in/rmannibucau>> | Book
>>>> > <
>>>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>>> <
>>>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>>> >>
>>>> >
>>>> >
>>>> > Le ven. 31 mai 2019 à 17:00, Daniel Kulp <dkulp@apache.org <mailto:
>>>> dkulp@apache.org>> a écrit :
>>>> >
>>>> >>
>>>> >>
>>>> >>> On May 31, 2019, at 10:54 AM, Romain Manni-Bucau <
>>>> rmannibucau@gmail.com>
>>>> >> 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
>>>> >> dkulp@apache.org <ma...@apache.org> <mailto:dkulp@apache.org
>>>> <ma...@apache.org>> - http://dankulp.com/blog <
>>>> http://dankulp.com/blog> <
>>>> >> http://dankulp.com/blog <http://dankulp.com/blog>>
>>>> >> Talend Community Coder - http://talend.com <http://talend.com/> <
>>>> http://coders.talend.com/ <http://coders.talend.com/>>
>>>>
>>>> --
>>>> Daniel Kulp
>>>> dkulp@apache.org <ma...@apache.org> - http://dankulp.com/blog <
>>>> http://dankulp.com/blog>
>>>> Talend Community Coder - http://talend.com <http://coders.talend.com/>
>>>>
>>>
Re: Can LoggingFeature not depend on javax.xml.ws?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Converted it to a PR -> https://github.com/apache/cxf/pull/561
For now i'm waiting for some CI feedback but basic mecanism is functional
:).
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 à 19:50, Romain Manni-Bucau <rm...@gmail.com> a
écrit :
> Here is a draft - I didn't rerun the build but wanted to share the idea:
> https://github.com/rmannibucau/cxf/commit/53c3c7016ce72dab61035a5417a7bba448fc3e43.
> The pattern is the same for all: add a nested Portable feature which is
> preferred for jaxrs over jaxws.
>
> Do you think we can get a fix for the original soon - this one or another?
> On my side I'd love to drop jaxws dead dependency ASAP in my apps which
> are using logging feature and gzip feature.
>
> 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 à 18:38, Romain Manni-Bucau <rm...@gmail.com> a
> écrit :
>
>> Created https://issues.apache.org/jira/browse/CXF-8053 to try to
>> summarize it, feel free to comment/adjust the description if I miss
>> anything.
>>
>> 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 à 18:17, Daniel Kulp <dk...@apache.org> a écrit :
>>
>>>
>>>
>>> > On May 31, 2019, at 11:09 AM, Romain Manni-Bucau <
>>> rmannibucau@gmail.com> wrote:
>>> >
>>> > Hmm, wouldn't a jaxws factory be a good replacement. So plan would be
>>>
>>> I’d prefer not as then you’d have a different programming model for
>>> jax-ws built in features (MTOMFeature, AddressingFeature) and CXF provided
>>> features. And of course there is the “it would break everyone’s existing
>>> code” issue.
>>>
>>> Having the JAX-WS versions wrapper/delegate to the native versions would
>>> be fine and should be mostly seamless. For the most part, there aren’t
>>> any protected fields or anything that subclasses would be using so it
>>> should work.
>>>
>>> Dan
>>>
>>>
>>>
>>> > 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 <
>>> https://twitter.com/rmannibucau>> | Blog
>>> > <https://rmannibucau.metawerx.net/ <https://rmannibucau.metawerx.net/>>
>>> | Old Blog
>>> > <http://rmannibucau.wordpress.com <http://rmannibucau.wordpress.com/>>
>>> | Github <https://github.com/rmannibucau <https://github.com/rmannibucau>>
>>> |
>>> > LinkedIn <https://www.linkedin.com/in/rmannibucau <
>>> https://www.linkedin.com/in/rmannibucau>> | Book
>>> > <
>>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> <
>>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> >>
>>> >
>>> >
>>> > Le ven. 31 mai 2019 à 17:00, Daniel Kulp <dkulp@apache.org <mailto:
>>> dkulp@apache.org>> a écrit :
>>> >
>>> >>
>>> >>
>>> >>> On May 31, 2019, at 10:54 AM, Romain Manni-Bucau <
>>> rmannibucau@gmail.com>
>>> >> 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
>>> >> dkulp@apache.org <ma...@apache.org> <mailto:dkulp@apache.org
>>> <ma...@apache.org>> - http://dankulp.com/blog <
>>> http://dankulp.com/blog> <
>>> >> http://dankulp.com/blog <http://dankulp.com/blog>>
>>> >> Talend Community Coder - http://talend.com <http://talend.com/> <
>>> http://coders.talend.com/ <http://coders.talend.com/>>
>>>
>>> --
>>> Daniel Kulp
>>> dkulp@apache.org <ma...@apache.org> - http://dankulp.com/blog <
>>> http://dankulp.com/blog>
>>> Talend Community Coder - http://talend.com <http://coders.talend.com/>
>>>
>>
Re: Can LoggingFeature not depend on javax.xml.ws?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Here is a draft - I didn't rerun the build but wanted to share the idea:
https://github.com/rmannibucau/cxf/commit/53c3c7016ce72dab61035a5417a7bba448fc3e43.
The pattern is the same for all: add a nested Portable feature which is
preferred for jaxrs over jaxws.
Do you think we can get a fix for the original soon - this one or another?
On my side I'd love to drop jaxws dead dependency ASAP in my apps which are
using logging feature and gzip feature.
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 à 18:38, Romain Manni-Bucau <rm...@gmail.com> a
écrit :
> Created https://issues.apache.org/jira/browse/CXF-8053 to try to
> summarize it, feel free to comment/adjust the description if I miss
> anything.
>
> 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 à 18:17, Daniel Kulp <dk...@apache.org> a écrit :
>
>>
>>
>> > On May 31, 2019, at 11:09 AM, Romain Manni-Bucau <rm...@gmail.com>
>> wrote:
>> >
>> > Hmm, wouldn't a jaxws factory be a good replacement. So plan would be
>>
>> I’d prefer not as then you’d have a different programming model for
>> jax-ws built in features (MTOMFeature, AddressingFeature) and CXF provided
>> features. And of course there is the “it would break everyone’s existing
>> code” issue.
>>
>> Having the JAX-WS versions wrapper/delegate to the native versions would
>> be fine and should be mostly seamless. For the most part, there aren’t
>> any protected fields or anything that subclasses would be using so it
>> should work.
>>
>> Dan
>>
>>
>>
>> > 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 <
>> https://twitter.com/rmannibucau>> | Blog
>> > <https://rmannibucau.metawerx.net/ <https://rmannibucau.metawerx.net/>>
>> | Old Blog
>> > <http://rmannibucau.wordpress.com <http://rmannibucau.wordpress.com/>>
>> | Github <https://github.com/rmannibucau <https://github.com/rmannibucau>>
>> |
>> > LinkedIn <https://www.linkedin.com/in/rmannibucau <
>> https://www.linkedin.com/in/rmannibucau>> | Book
>> > <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >>
>> >
>> >
>> > Le ven. 31 mai 2019 à 17:00, Daniel Kulp <dkulp@apache.org <mailto:
>> dkulp@apache.org>> a écrit :
>> >
>> >>
>> >>
>> >>> On May 31, 2019, at 10:54 AM, Romain Manni-Bucau <
>> rmannibucau@gmail.com>
>> >> 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
>> >> dkulp@apache.org <ma...@apache.org> <mailto:dkulp@apache.org
>> <ma...@apache.org>> - http://dankulp.com/blog <
>> http://dankulp.com/blog> <
>> >> http://dankulp.com/blog <http://dankulp.com/blog>>
>> >> Talend Community Coder - http://talend.com <http://talend.com/> <
>> http://coders.talend.com/ <http://coders.talend.com/>>
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org <ma...@apache.org> - http://dankulp.com/blog <
>> http://dankulp.com/blog>
>> Talend Community Coder - http://talend.com <http://coders.talend.com/>
>>
>
Re: Can LoggingFeature not depend on javax.xml.ws?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Created https://issues.apache.org/jira/browse/CXF-8053 to try to summarize
it, feel free to comment/adjust the description if I miss anything.
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 à 18:17, Daniel Kulp <dk...@apache.org> a écrit :
>
>
> > On May 31, 2019, at 11:09 AM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
> >
> > Hmm, wouldn't a jaxws factory be a good replacement. So plan would be
>
> I’d prefer not as then you’d have a different programming model for jax-ws
> built in features (MTOMFeature, AddressingFeature) and CXF provided
> features. And of course there is the “it would break everyone’s existing
> code” issue.
>
> Having the JAX-WS versions wrapper/delegate to the native versions would
> be fine and should be mostly seamless. For the most part, there aren’t
> any protected fields or anything that subclasses would be using so it
> should work.
>
> Dan
>
>
>
> > 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 <
> https://twitter.com/rmannibucau>> | Blog
> > <https://rmannibucau.metawerx.net/ <https://rmannibucau.metawerx.net/>>
> | Old Blog
> > <http://rmannibucau.wordpress.com <http://rmannibucau.wordpress.com/>>
> | Github <https://github.com/rmannibucau <https://github.com/rmannibucau>>
> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau <
> https://www.linkedin.com/in/rmannibucau>> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >>
> >
> >
> > Le ven. 31 mai 2019 à 17:00, Daniel Kulp <dkulp@apache.org <mailto:
> dkulp@apache.org>> a écrit :
> >
> >>
> >>
> >>> On May 31, 2019, at 10:54 AM, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> >> 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
> >> dkulp@apache.org <ma...@apache.org> <mailto:dkulp@apache.org
> <ma...@apache.org>> - http://dankulp.com/blog <
> http://dankulp.com/blog> <
> >> http://dankulp.com/blog <http://dankulp.com/blog>>
> >> Talend Community Coder - http://talend.com <http://talend.com/> <
> http://coders.talend.com/ <http://coders.talend.com/>>
>
> --
> Daniel Kulp
> dkulp@apache.org <ma...@apache.org> - http://dankulp.com/blog <
> http://dankulp.com/blog>
> Talend Community Coder - http://talend.com <http://coders.talend.com/>
>
Re: Can LoggingFeature not depend on javax.xml.ws?
Posted by Daniel Kulp <dk...@apache.org>.
> On May 31, 2019, at 11:09 AM, Romain Manni-Bucau <rm...@gmail.com> wrote:
>
> Hmm, wouldn't a jaxws factory be a good replacement. So plan would be
I’d prefer not as then you’d have a different programming model for jax-ws built in features (MTOMFeature, AddressingFeature) and CXF provided features. And of course there is the “it would break everyone’s existing code” issue.
Having the JAX-WS versions wrapper/delegate to the native versions would be fine and should be mostly seamless. For the most part, there aren’t any protected fields or anything that subclasses would be using so it should work.
Dan
> 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 <https://twitter.com/rmannibucau>> | Blog
> <https://rmannibucau.metawerx.net/ <https://rmannibucau.metawerx.net/>> | Old Blog
> <http://rmannibucau.wordpress.com <http://rmannibucau.wordpress.com/>> | Github <https://github.com/rmannibucau <https://github.com/rmannibucau>> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau <https://www.linkedin.com/in/rmannibucau>> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance <https://www.packtpub.com/application-development/java-ee-8-high-performance>>
>
>
> Le ven. 31 mai 2019 à 17:00, Daniel Kulp <dkulp@apache.org <ma...@apache.org>> a écrit :
>
>>
>>
>>> On May 31, 2019, at 10:54 AM, Romain Manni-Bucau <rm...@gmail.com>
>> 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
>> dkulp@apache.org <ma...@apache.org> <mailto:dkulp@apache.org <ma...@apache.org>> - http://dankulp.com/blog <http://dankulp.com/blog> <
>> http://dankulp.com/blog <http://dankulp.com/blog>>
>> Talend Community Coder - http://talend.com <http://talend.com/> <http://coders.talend.com/ <http://coders.talend.com/>>
--
Daniel Kulp
dkulp@apache.org <ma...@apache.org> - http://dankulp.com/blog <http://dankulp.com/blog>
Talend Community Coder - http://talend.com <http://coders.talend.com/>
Re: Can LoggingFeature not depend on javax.xml.ws?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <dk...@apache.org> a écrit :
>
>
> > On May 31, 2019, at 10:54 AM, Romain Manni-Bucau <rm...@gmail.com>
> 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
> dkulp@apache.org <ma...@apache.org> - http://dankulp.com/blog <
> http://dankulp.com/blog>
> Talend Community Coder - http://talend.com <http://coders.talend.com/>
>
Re: Can LoggingFeature not depend on javax.xml.ws?
Posted by Daniel Kulp <dk...@apache.org>.
> On May 31, 2019, at 10:54 AM, Romain Manni-Bucau <rm...@gmail.com> 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
dkulp@apache.org <ma...@apache.org> - http://dankulp.com/blog <http://dankulp.com/blog>
Talend Community Coder - http://talend.com <http://coders.talend.com/>
Re: Can LoggingFeature not depend on javax.xml.ws?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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.
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 à 16:49, Daniel Kulp <dk...@apache.org> a écrit :
>
>
> > I just realized LoggingFeature depends on javax.xml.ws.WebServiceFeature
> >
> > Is it possible to drop that dependency in the target to run on java ~11
> > without javax.xml.ws dependencies?
>
> Certainly not without breaking compatibility and everyone using any of the
> CXF provided features. AbstractFeature (in core) subclasses
> WebServiceFeature so that any of the features can be added directly to any
> of the jax-ws endpoints/clients directly and everyone using them does so.
> Thus, removing that as a parent would completely break everyone.
>
>
> --
> Daniel Kulp
> dkulp@apache.org <ma...@apache.org> - http://dankulp.com/blog <
> http://dankulp.com/blog>
> Talend Community Coder - http://talend.com <http://coders.talend.com/>
>
Re: Can LoggingFeature not depend on javax.xml.ws?
Posted by Daniel Kulp <dk...@apache.org>.
> I just realized LoggingFeature depends on javax.xml.ws.WebServiceFeature
>
> Is it possible to drop that dependency in the target to run on java ~11
> without javax.xml.ws dependencies?
Certainly not without breaking compatibility and everyone using any of the CXF provided features. AbstractFeature (in core) subclasses WebServiceFeature so that any of the features can be added directly to any of the jax-ws endpoints/clients directly and everyone using them does so. Thus, removing that as a parent would completely break everyone.
--
Daniel Kulp
dkulp@apache.org <ma...@apache.org> - http://dankulp.com/blog <http://dankulp.com/blog>
Talend Community Coder - http://talend.com <http://coders.talend.com/>