You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Mark Struberg <st...@yahoo.de.INVALID> on 2018/04/25 20:26:49 UTC
A few 'Feature' questions
hi folks!
I have two questions:
1.) Could anybody plz take a quick look at CXF-7713 and review the patch?
2.) I've created a DynamicFeature @Provider and tried to register a CXF LoggingInterceptor.
And this doesn't work since it seems to only pick up javax.ws.rs.core.Feature instances, but not
org.apache.cxf.feature.Feature
Is this observation correct?
Is this behaviour intended?
I know I can register it via Bus#setFeatures, but that is not as modular in comparison to the @Provider.
txs and LieGrue,
strub
Re: A few 'Feature' questions
Posted by Andriy Redko <dr...@gmail.com>.
My apologies for delaying the response, Mark. So I have been looking for options here,
and I believe we could have it solved. The suggestion would be to provide the JAX-RS
feature (f.e. org.apache.cxf.ext.logging.jaxrs.LoggingFeature), which would internally
be implemented using the interceptors logic (so 99% of the implementation would be shared
between both features). Mark, Christian, would it make sense guys?
Best Regards,
Andriy Redko
Monday, April 30, 2018, 4:56:48 AM, you wrote:
MS> Well, we tried that via the @Feature annotation but then it was enabled for very endpoint.
MS> And the config switch to disable logging didn't work somehow.
MS> The solution with the Bus works great in my setup. But I'd love to find a more portable solution.
MS> LieGrue,
MS> strub
>> Am 29.04.2018 um 14:27 schrieb Christian Schneider <ch...@die-schneider.net>:
>> It does not work automagically. You still have to add the logging feature
>> to your service.
>> Christan
>> 2018-04-28 21:39 GMT+02:00 Mark Struberg <st...@yahoo.de.invalid>:
>>> Hi Christian!
>>>> ( I hope you are talking about the new logging feature described here:
>>>> http://cxf.apache.org/docs/message-logging.html).
>>> Yes. I actually tried that but failed. Probably I missed something.
>>> Should this work like a plugin? Means, should it simply work out of the
>>> box if I just drop it into the classpath?
>>> Because I tried that and it didn't work...
>>> Note that I'm using CXF as part of Apache Meecrowave. So not with Spring
>>> but with Apache OpenWebBeans as CDI container.
>>> txs and LieGrue,
>>> strub
>>>> Am 27.04.2018 um 09:10 schrieb Christian Schneider <
>>> chris@die-schneider.net>:
>>>> I think your case is valid in general.
>>>> What I do not understand is why you do not install the logging feature in
>>>> production
>>>> ( I hope you are talking about the new logging feature described here:
>>>> http://cxf.apache.org/docs/message-logging.html).
>>>> The feature is designed to be added to all services and then be enabled /
>>>> disabled via the logging configuration. So it should have almost no
>>>> performance impact
>>>> when switched off). I think it is very important to be able to enable
>>>> logging while in production if it is needed and you typically do not know
>>>> if it is needed at build time.
>>>> Christian
>>>> 2018-04-27 8:36 GMT+02:00 Mark Struberg <st...@yahoo.de.invalid>:
>>>>> Sure, here is my use case:
>>>>> We want to make use of the LoggingFeature, but would love to completely
>>>>> disable it in production. So we don't even want to enable the Feature
>>>>> depending on a configuration setting.
>>>>> That means we also cannot use the @Feature annotation but need to apply
>>> it
>>>>> programmatically.
>>>>> I know that I can enable a Feature programmatically via the Bus. But
>>>>> setFeatures() has to be done at exactly the right point in time. This
>>> is a
>>>>> bit tricky as it depends on the integration scenario.
>>>>> In my case (Apache Meecrowave) I went the way of doing this in my
>>>>> Application.
>>>>>> @ApplicationScoped
>>>>>> @ApplicationPath("/api")
>>>>>> public class MyApp extends Application {
>>>>>> // configuration is done via Apache DeltaSpike
>>>>>> private static ConfigResolver.TypedResolver<Boolean> logEnabled
>>>>>> = ConfigResolver.resolve("myapp.cxf.logging.enabled")
>>>>>> .as(Boolean.class)
>>>>>> .evaluateVariables(true)
>>>>>> .withDefault(Boolean.FALSE)
>>>>>> .cacheFor(TimeUnit.MINUTES, 30);
>>>>>> private @Inject Bus bus;
>>>>>> @PostConstruct
>>>>>> public void initKonnektorApp() {
>>>>>> if (Boolean.TRUE == logEnabled.getValue()) {
>>>>>> log.info("CXF LogInterceptors enabled");
>>>>>> Collection<Feature> features = new ArrayList<>();
>>>>>> features.add(new LoggingFeature());
>>>>>> bus.setFeatures(features);
>>>>>> }
>>>>>> }
>>>>>> }
>>>>> This works great in Meecrowave since the Application is picked up as CDI
>>>>> bean and the Bus is also available via CDI.
>>>>> But this is actually not guaranteed, so it's not really portable. It
>>> isn't
>>>>> guaranteed to work that way in say IBM Liberty or Apache TomEE.
>>>>> That's the reason why I'd love to see a more portable version.
>>>>> Which brought me to using @DynamicFeature to register that Feature.
>>>>> But as already noted: cxf.Feature != javax rs.Feature
>>>>> Makes sense?
>>>>> Is there another way to enable that feature in a programmatic way which
>>>>> I've simply missed?
>>>>> txs and LieGrue,
>>>>> strub
>>>>>> Am 26.04.2018 um 22:22 schrieb Andrey Redko <dr...@gmail.com>:
>>>>>> Yeah, certainly, would be good to get a bit more details or small code
>>>>>> snippets to understand the problem. Mark, is it possible? Thanks.
>>>>>> Best Regards,
>>>>>> Andriy Redko
>>>>>> On Thu, Apr 26, 2018, 12:40 AM Romain Manni-Bucau <
>>> rmannibucau@gmail.com
>>>>>> wrote:
>>>>>>> Hi guys
>>>>>>> Think CXF should support that case or support its own features (for
>>> cdi
>>>>>>> integ it is easy since we have the bus ;)). Otherwise as a user you
>>> are
>>>>> in
>>>>>>> a half baked position and the featureful part of cxf is kind of faked.
>>>>>>> Is the work that hard? Sime interceptors already play with the chain
>>> so
>>>>>>> should be really doable and it matches the way register was designed
>>>>> too.
>>>>>>> Le 26 avr. 2018 00:52, "Andriy Redko" <dr...@gmail.com> a écrit :
>>>>>>>> Hi Mark,
>>>>>>>> I would agree with Andy here, the CXF interceptors / features have
>>>>> existed
>>>>>>>> way before the JAX-RS spec. Alhough it is possible to support
>>>>> additional
>>>>>>>> provider contracts in DynamicFeature, it is difficult to match it
>>>>> exactly
>>>>>>>> to the JAX-RS lifecycle. As an option, you may consider converting
>>> the
>>>>>>>> LoggingInterceptor into full-feldged JAX-RS provider (if it makes
>>> sense
>>>>>>>> for sure).
>>>>>>>> Best Regards,
>>>>>>>> Andriy Redko
>>>>>>>> AM> Hi Mark,
>>>>>>>> AM> For #1 - I'll take a look - I've been meaning to ever since I saw
>>>>> the
>>>>>>>> JIRA,
>>>>>>>> AM> but I've been swamped lately. My bad.
>>>>>>>> AM> For #2 - I'd like others to weigh in, but I do think that this is
>>>>> the
>>>>>>>> AM> intended behavior. IIUC, org.apache.cxf.feature.Feature existed
>>>>>>>> before the
>>>>>>>> AM> JAX-RS spec and is used in a variety of non-JAX-RS scenarios
>>>>> (JAX-WS,
>>>>>>>> AM> etc.). The LoggingInterceptor is not actually a JAX-RS provider
>>> -
>>>>>>>> rather
>>>>>>>> AM> it is an interceptor used on the CXF chain. JAX-RS Providers are
>>>>>>>> typically
>>>>>>>> AM> invoked from the JAXRSInInterceptor and JAXRSOutInterceptor on
>>> the
>>>>>>>> chain.
>>>>>>>> AM> It may be possible to add a LoggingInterceptor to the chain at
>>> that
>>>>>>>> point,
>>>>>>>> AM> but it doesn't seem advisable - I haven't done much with chain
>>>>>>>> AM> manipulation, so would definitely recommend a second opinion
>>> here.
>>>>>>>> AM> Thanks for the patch,
>>>>>>>> AM> Andy
>>>>>>>> AM> On Wed, Apr 25, 2018 at 3:26 PM, Mark Struberg
>>>>>>>> <st...@yahoo.de.invalid>
>>>>>>>> AM> wrote:
>>>>>>>>>> hi folks!
>>>>>>>>>> I have two questions:
>>>>>>>>>> 1.) Could anybody plz take a quick look at CXF-7713 and review the
>>>>>>>> patch?
>>>>>>>>>> 2.) I've created a DynamicFeature @Provider and tried to register a
>>>>> CXF
>>>>>>>>>> LoggingInterceptor.
>>>>>>>>>> And this doesn't work since it seems to only pick up
>>>>>>>>>> javax.ws.rs.core.Feature instances, but not
>>>>>>>>>> org.apache.cxf.feature.Feature
>>>>>>>>>> Is this observation correct?
>>>>>>>>>> Is this behaviour intended?
>>>>>>>>>> I know I can register it via Bus#setFeatures, but that is not as
>>>>>>>> modular
>>>>>>>>>> in comparison to the @Provider.
>>>>>>>>>> txs and LieGrue,
>>>>>>>>>> strub
>>>> --
>>>> --
>>>> Christian Schneider
>>>> http://www.liquid-reality.de
>>>> Computer Scientist
>>>> http://www.adobe.com
>> --
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>> Computer Scientist
>> http://www.adobe.com
Re: A few 'Feature' questions
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
Well, we tried that via the @Feature annotation but then it was enabled for very endpoint.
And the config switch to disable logging didn't work somehow.
The solution with the Bus works great in my setup. But I'd love to find a more portable solution.
LieGrue,
strub
> Am 29.04.2018 um 14:27 schrieb Christian Schneider <ch...@die-schneider.net>:
>
> It does not work automagically. You still have to add the logging feature
> to your service.
>
> Christan
>
> 2018-04-28 21:39 GMT+02:00 Mark Struberg <st...@yahoo.de.invalid>:
>
>> Hi Christian!
>>
>>> ( I hope you are talking about the new logging feature described here:
>>> http://cxf.apache.org/docs/message-logging.html).
>>
>> Yes. I actually tried that but failed. Probably I missed something.
>>
>> Should this work like a plugin? Means, should it simply work out of the
>> box if I just drop it into the classpath?
>> Because I tried that and it didn't work...
>>
>> Note that I'm using CXF as part of Apache Meecrowave. So not with Spring
>> but with Apache OpenWebBeans as CDI container.
>>
>> txs and LieGrue,
>> strub
>>
>>> Am 27.04.2018 um 09:10 schrieb Christian Schneider <
>> chris@die-schneider.net>:
>>>
>>> I think your case is valid in general.
>>>
>>> What I do not understand is why you do not install the logging feature in
>>> production
>>> ( I hope you are talking about the new logging feature described here:
>>> http://cxf.apache.org/docs/message-logging.html).
>>>
>>> The feature is designed to be added to all services and then be enabled /
>>> disabled via the logging configuration. So it should have almost no
>>> performance impact
>>> when switched off). I think it is very important to be able to enable
>>> logging while in production if it is needed and you typically do not know
>>> if it is needed at build time.
>>>
>>> Christian
>>>
>>>
>>> 2018-04-27 8:36 GMT+02:00 Mark Struberg <st...@yahoo.de.invalid>:
>>>
>>>> Sure, here is my use case:
>>>>
>>>> We want to make use of the LoggingFeature, but would love to completely
>>>> disable it in production. So we don't even want to enable the Feature
>>>> depending on a configuration setting.
>>>> That means we also cannot use the @Feature annotation but need to apply
>> it
>>>> programmatically.
>>>>
>>>> I know that I can enable a Feature programmatically via the Bus. But
>>>> setFeatures() has to be done at exactly the right point in time. This
>> is a
>>>> bit tricky as it depends on the integration scenario.
>>>>
>>>> In my case (Apache Meecrowave) I went the way of doing this in my
>>>> Application.
>>>>
>>>>> @ApplicationScoped
>>>>> @ApplicationPath("/api")
>>>>> public class MyApp extends Application {
>>>>> // configuration is done via Apache DeltaSpike
>>>>> private static ConfigResolver.TypedResolver<Boolean> logEnabled
>>>>> = ConfigResolver.resolve("myapp.cxf.logging.enabled")
>>>>> .as(Boolean.class)
>>>>> .evaluateVariables(true)
>>>>> .withDefault(Boolean.FALSE)
>>>>> .cacheFor(TimeUnit.MINUTES, 30);
>>>>>
>>>>> private @Inject Bus bus;
>>>>>
>>>>> @PostConstruct
>>>>> public void initKonnektorApp() {
>>>>> if (Boolean.TRUE == logEnabled.getValue()) {
>>>>> log.info("CXF LogInterceptors enabled");
>>>>> Collection<Feature> features = new ArrayList<>();
>>>>> features.add(new LoggingFeature());
>>>>> bus.setFeatures(features);
>>>>> }
>>>>> }
>>>>> }
>>>>
>>>> This works great in Meecrowave since the Application is picked up as CDI
>>>> bean and the Bus is also available via CDI.
>>>> But this is actually not guaranteed, so it's not really portable. It
>> isn't
>>>> guaranteed to work that way in say IBM Liberty or Apache TomEE.
>>>>
>>>>
>>>> That's the reason why I'd love to see a more portable version.
>>>> Which brought me to using @DynamicFeature to register that Feature.
>>>> But as already noted: cxf.Feature != javax rs.Feature
>>>>
>>>> Makes sense?
>>>> Is there another way to enable that feature in a programmatic way which
>>>> I've simply missed?
>>>>
>>>> txs and LieGrue,
>>>> strub
>>>>
>>>>
>>>>
>>>>
>>>>> Am 26.04.2018 um 22:22 schrieb Andrey Redko <dr...@gmail.com>:
>>>>>
>>>>> Yeah, certainly, would be good to get a bit more details or small code
>>>>> snippets to understand the problem. Mark, is it possible? Thanks.
>>>>>
>>>>> Best Regards,
>>>>> Andriy Redko
>>>>>
>>>>> On Thu, Apr 26, 2018, 12:40 AM Romain Manni-Bucau <
>> rmannibucau@gmail.com
>>>>>
>>>>> wrote:
>>>>>
>>>>>> Hi guys
>>>>>>
>>>>>> Think CXF should support that case or support its own features (for
>> cdi
>>>>>> integ it is easy since we have the bus ;)). Otherwise as a user you
>> are
>>>> in
>>>>>> a half baked position and the featureful part of cxf is kind of faked.
>>>>>>
>>>>>> Is the work that hard? Sime interceptors already play with the chain
>> so
>>>>>> should be really doable and it matches the way register was designed
>>>> too.
>>>>>>
>>>>>> Le 26 avr. 2018 00:52, "Andriy Redko" <dr...@gmail.com> a écrit :
>>>>>>
>>>>>>> Hi Mark,
>>>>>>>
>>>>>>> I would agree with Andy here, the CXF interceptors / features have
>>>> existed
>>>>>>> way before the JAX-RS spec. Alhough it is possible to support
>>>> additional
>>>>>>> provider contracts in DynamicFeature, it is difficult to match it
>>>> exactly
>>>>>>> to the JAX-RS lifecycle. As an option, you may consider converting
>> the
>>>>>>> LoggingInterceptor into full-feldged JAX-RS provider (if it makes
>> sense
>>>>>>> for sure).
>>>>>>>
>>>>>>> Best Regards,
>>>>>>> Andriy Redko
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> AM> Hi Mark,
>>>>>>>
>>>>>>> AM> For #1 - I'll take a look - I've been meaning to ever since I saw
>>>> the
>>>>>>> JIRA,
>>>>>>> AM> but I've been swamped lately. My bad.
>>>>>>>
>>>>>>> AM> For #2 - I'd like others to weigh in, but I do think that this is
>>>> the
>>>>>>> AM> intended behavior. IIUC, org.apache.cxf.feature.Feature existed
>>>>>>> before the
>>>>>>> AM> JAX-RS spec and is used in a variety of non-JAX-RS scenarios
>>>> (JAX-WS,
>>>>>>> AM> etc.). The LoggingInterceptor is not actually a JAX-RS provider
>> -
>>>>>>> rather
>>>>>>> AM> it is an interceptor used on the CXF chain. JAX-RS Providers are
>>>>>>> typically
>>>>>>> AM> invoked from the JAXRSInInterceptor and JAXRSOutInterceptor on
>> the
>>>>>>> chain.
>>>>>>> AM> It may be possible to add a LoggingInterceptor to the chain at
>> that
>>>>>>> point,
>>>>>>> AM> but it doesn't seem advisable - I haven't done much with chain
>>>>>>> AM> manipulation, so would definitely recommend a second opinion
>> here.
>>>>>>>
>>>>>>> AM> Thanks for the patch,
>>>>>>>
>>>>>>> AM> Andy
>>>>>>>
>>>>>>> AM> On Wed, Apr 25, 2018 at 3:26 PM, Mark Struberg
>>>>>>> <st...@yahoo.de.invalid>
>>>>>>> AM> wrote:
>>>>>>>
>>>>>>>>> hi folks!
>>>>>>>
>>>>>>>>> I have two questions:
>>>>>>>
>>>>>>>>> 1.) Could anybody plz take a quick look at CXF-7713 and review the
>>>>>>> patch?
>>>>>>>
>>>>>>>>> 2.) I've created a DynamicFeature @Provider and tried to register a
>>>> CXF
>>>>>>>>> LoggingInterceptor.
>>>>>>>>> And this doesn't work since it seems to only pick up
>>>>>>>>> javax.ws.rs.core.Feature instances, but not
>>>>>>>>> org.apache.cxf.feature.Feature
>>>>>>>
>>>>>>>>> Is this observation correct?
>>>>>>>>> Is this behaviour intended?
>>>>>>>
>>>>>>>>> I know I can register it via Bus#setFeatures, but that is not as
>>>>>>> modular
>>>>>>>>> in comparison to the @Provider.
>>>>>>>
>>>>>>>>> txs and LieGrue,
>>>>>>>>> strub
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Computer Scientist
>>> http://www.adobe.com
>>
>>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Computer Scientist
> http://www.adobe.com
Re: A few 'Feature' questions
Posted by Christian Schneider <ch...@die-schneider.net>.
It does not work automagically. You still have to add the logging feature
to your service.
Christan
2018-04-28 21:39 GMT+02:00 Mark Struberg <st...@yahoo.de.invalid>:
> Hi Christian!
>
> > ( I hope you are talking about the new logging feature described here:
> > http://cxf.apache.org/docs/message-logging.html).
>
> Yes. I actually tried that but failed. Probably I missed something.
>
> Should this work like a plugin? Means, should it simply work out of the
> box if I just drop it into the classpath?
> Because I tried that and it didn't work...
>
> Note that I'm using CXF as part of Apache Meecrowave. So not with Spring
> but with Apache OpenWebBeans as CDI container.
>
> txs and LieGrue,
> strub
>
> > Am 27.04.2018 um 09:10 schrieb Christian Schneider <
> chris@die-schneider.net>:
> >
> > I think your case is valid in general.
> >
> > What I do not understand is why you do not install the logging feature in
> > production
> > ( I hope you are talking about the new logging feature described here:
> > http://cxf.apache.org/docs/message-logging.html).
> >
> > The feature is designed to be added to all services and then be enabled /
> > disabled via the logging configuration. So it should have almost no
> > performance impact
> > when switched off). I think it is very important to be able to enable
> > logging while in production if it is needed and you typically do not know
> > if it is needed at build time.
> >
> > Christian
> >
> >
> > 2018-04-27 8:36 GMT+02:00 Mark Struberg <st...@yahoo.de.invalid>:
> >
> >> Sure, here is my use case:
> >>
> >> We want to make use of the LoggingFeature, but would love to completely
> >> disable it in production. So we don't even want to enable the Feature
> >> depending on a configuration setting.
> >> That means we also cannot use the @Feature annotation but need to apply
> it
> >> programmatically.
> >>
> >> I know that I can enable a Feature programmatically via the Bus. But
> >> setFeatures() has to be done at exactly the right point in time. This
> is a
> >> bit tricky as it depends on the integration scenario.
> >>
> >> In my case (Apache Meecrowave) I went the way of doing this in my
> >> Application.
> >>
> >>> @ApplicationScoped
> >>> @ApplicationPath("/api")
> >>> public class MyApp extends Application {
> >>> // configuration is done via Apache DeltaSpike
> >>> private static ConfigResolver.TypedResolver<Boolean> logEnabled
> >>> = ConfigResolver.resolve("myapp.cxf.logging.enabled")
> >>> .as(Boolean.class)
> >>> .evaluateVariables(true)
> >>> .withDefault(Boolean.FALSE)
> >>> .cacheFor(TimeUnit.MINUTES, 30);
> >>>
> >>> private @Inject Bus bus;
> >>>
> >>> @PostConstruct
> >>> public void initKonnektorApp() {
> >>> if (Boolean.TRUE == logEnabled.getValue()) {
> >>> log.info("CXF LogInterceptors enabled");
> >>> Collection<Feature> features = new ArrayList<>();
> >>> features.add(new LoggingFeature());
> >>> bus.setFeatures(features);
> >>> }
> >>> }
> >>> }
> >>
> >> This works great in Meecrowave since the Application is picked up as CDI
> >> bean and the Bus is also available via CDI.
> >> But this is actually not guaranteed, so it's not really portable. It
> isn't
> >> guaranteed to work that way in say IBM Liberty or Apache TomEE.
> >>
> >>
> >> That's the reason why I'd love to see a more portable version.
> >> Which brought me to using @DynamicFeature to register that Feature.
> >> But as already noted: cxf.Feature != javax rs.Feature
> >>
> >> Makes sense?
> >> Is there another way to enable that feature in a programmatic way which
> >> I've simply missed?
> >>
> >> txs and LieGrue,
> >> strub
> >>
> >>
> >>
> >>
> >>> Am 26.04.2018 um 22:22 schrieb Andrey Redko <dr...@gmail.com>:
> >>>
> >>> Yeah, certainly, would be good to get a bit more details or small code
> >>> snippets to understand the problem. Mark, is it possible? Thanks.
> >>>
> >>> Best Regards,
> >>> Andriy Redko
> >>>
> >>> On Thu, Apr 26, 2018, 12:40 AM Romain Manni-Bucau <
> rmannibucau@gmail.com
> >>>
> >>> wrote:
> >>>
> >>>> Hi guys
> >>>>
> >>>> Think CXF should support that case or support its own features (for
> cdi
> >>>> integ it is easy since we have the bus ;)). Otherwise as a user you
> are
> >> in
> >>>> a half baked position and the featureful part of cxf is kind of faked.
> >>>>
> >>>> Is the work that hard? Sime interceptors already play with the chain
> so
> >>>> should be really doable and it matches the way register was designed
> >> too.
> >>>>
> >>>> Le 26 avr. 2018 00:52, "Andriy Redko" <dr...@gmail.com> a écrit :
> >>>>
> >>>>> Hi Mark,
> >>>>>
> >>>>> I would agree with Andy here, the CXF interceptors / features have
> >> existed
> >>>>> way before the JAX-RS spec. Alhough it is possible to support
> >> additional
> >>>>> provider contracts in DynamicFeature, it is difficult to match it
> >> exactly
> >>>>> to the JAX-RS lifecycle. As an option, you may consider converting
> the
> >>>>> LoggingInterceptor into full-feldged JAX-RS provider (if it makes
> sense
> >>>>> for sure).
> >>>>>
> >>>>> Best Regards,
> >>>>> Andriy Redko
> >>>>>
> >>>>>
> >>>>>
> >>>>> AM> Hi Mark,
> >>>>>
> >>>>> AM> For #1 - I'll take a look - I've been meaning to ever since I saw
> >> the
> >>>>> JIRA,
> >>>>> AM> but I've been swamped lately. My bad.
> >>>>>
> >>>>> AM> For #2 - I'd like others to weigh in, but I do think that this is
> >> the
> >>>>> AM> intended behavior. IIUC, org.apache.cxf.feature.Feature existed
> >>>>> before the
> >>>>> AM> JAX-RS spec and is used in a variety of non-JAX-RS scenarios
> >> (JAX-WS,
> >>>>> AM> etc.). The LoggingInterceptor is not actually a JAX-RS provider
> -
> >>>>> rather
> >>>>> AM> it is an interceptor used on the CXF chain. JAX-RS Providers are
> >>>>> typically
> >>>>> AM> invoked from the JAXRSInInterceptor and JAXRSOutInterceptor on
> the
> >>>>> chain.
> >>>>> AM> It may be possible to add a LoggingInterceptor to the chain at
> that
> >>>>> point,
> >>>>> AM> but it doesn't seem advisable - I haven't done much with chain
> >>>>> AM> manipulation, so would definitely recommend a second opinion
> here.
> >>>>>
> >>>>> AM> Thanks for the patch,
> >>>>>
> >>>>> AM> Andy
> >>>>>
> >>>>> AM> On Wed, Apr 25, 2018 at 3:26 PM, Mark Struberg
> >>>>> <st...@yahoo.de.invalid>
> >>>>> AM> wrote:
> >>>>>
> >>>>>>> hi folks!
> >>>>>
> >>>>>>> I have two questions:
> >>>>>
> >>>>>>> 1.) Could anybody plz take a quick look at CXF-7713 and review the
> >>>>> patch?
> >>>>>
> >>>>>>> 2.) I've created a DynamicFeature @Provider and tried to register a
> >> CXF
> >>>>>>> LoggingInterceptor.
> >>>>>>> And this doesn't work since it seems to only pick up
> >>>>>>> javax.ws.rs.core.Feature instances, but not
> >>>>>>> org.apache.cxf.feature.Feature
> >>>>>
> >>>>>>> Is this observation correct?
> >>>>>>> Is this behaviour intended?
> >>>>>
> >>>>>>> I know I can register it via Bus#setFeatures, but that is not as
> >>>>> modular
> >>>>>>> in comparison to the @Provider.
> >>>>>
> >>>>>>> txs and LieGrue,
> >>>>>>> strub
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>
> >>
> >
> >
> > --
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Computer Scientist
> > http://www.adobe.com
>
>
--
--
Christian Schneider
http://www.liquid-reality.de
Computer Scientist
http://www.adobe.com
Re: A few 'Feature' questions
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
Hi Christian!
> ( I hope you are talking about the new logging feature described here:
> http://cxf.apache.org/docs/message-logging.html).
Yes. I actually tried that but failed. Probably I missed something.
Should this work like a plugin? Means, should it simply work out of the box if I just drop it into the classpath?
Because I tried that and it didn't work...
Note that I'm using CXF as part of Apache Meecrowave. So not with Spring but with Apache OpenWebBeans as CDI container.
txs and LieGrue,
strub
> Am 27.04.2018 um 09:10 schrieb Christian Schneider <ch...@die-schneider.net>:
>
> I think your case is valid in general.
>
> What I do not understand is why you do not install the logging feature in
> production
> ( I hope you are talking about the new logging feature described here:
> http://cxf.apache.org/docs/message-logging.html).
>
> The feature is designed to be added to all services and then be enabled /
> disabled via the logging configuration. So it should have almost no
> performance impact
> when switched off). I think it is very important to be able to enable
> logging while in production if it is needed and you typically do not know
> if it is needed at build time.
>
> Christian
>
>
> 2018-04-27 8:36 GMT+02:00 Mark Struberg <st...@yahoo.de.invalid>:
>
>> Sure, here is my use case:
>>
>> We want to make use of the LoggingFeature, but would love to completely
>> disable it in production. So we don't even want to enable the Feature
>> depending on a configuration setting.
>> That means we also cannot use the @Feature annotation but need to apply it
>> programmatically.
>>
>> I know that I can enable a Feature programmatically via the Bus. But
>> setFeatures() has to be done at exactly the right point in time. This is a
>> bit tricky as it depends on the integration scenario.
>>
>> In my case (Apache Meecrowave) I went the way of doing this in my
>> Application.
>>
>>> @ApplicationScoped
>>> @ApplicationPath("/api")
>>> public class MyApp extends Application {
>>> // configuration is done via Apache DeltaSpike
>>> private static ConfigResolver.TypedResolver<Boolean> logEnabled
>>> = ConfigResolver.resolve("myapp.cxf.logging.enabled")
>>> .as(Boolean.class)
>>> .evaluateVariables(true)
>>> .withDefault(Boolean.FALSE)
>>> .cacheFor(TimeUnit.MINUTES, 30);
>>>
>>> private @Inject Bus bus;
>>>
>>> @PostConstruct
>>> public void initKonnektorApp() {
>>> if (Boolean.TRUE == logEnabled.getValue()) {
>>> log.info("CXF LogInterceptors enabled");
>>> Collection<Feature> features = new ArrayList<>();
>>> features.add(new LoggingFeature());
>>> bus.setFeatures(features);
>>> }
>>> }
>>> }
>>
>> This works great in Meecrowave since the Application is picked up as CDI
>> bean and the Bus is also available via CDI.
>> But this is actually not guaranteed, so it's not really portable. It isn't
>> guaranteed to work that way in say IBM Liberty or Apache TomEE.
>>
>>
>> That's the reason why I'd love to see a more portable version.
>> Which brought me to using @DynamicFeature to register that Feature.
>> But as already noted: cxf.Feature != javax rs.Feature
>>
>> Makes sense?
>> Is there another way to enable that feature in a programmatic way which
>> I've simply missed?
>>
>> txs and LieGrue,
>> strub
>>
>>
>>
>>
>>> Am 26.04.2018 um 22:22 schrieb Andrey Redko <dr...@gmail.com>:
>>>
>>> Yeah, certainly, would be good to get a bit more details or small code
>>> snippets to understand the problem. Mark, is it possible? Thanks.
>>>
>>> Best Regards,
>>> Andriy Redko
>>>
>>> On Thu, Apr 26, 2018, 12:40 AM Romain Manni-Bucau <rmannibucau@gmail.com
>>>
>>> wrote:
>>>
>>>> Hi guys
>>>>
>>>> Think CXF should support that case or support its own features (for cdi
>>>> integ it is easy since we have the bus ;)). Otherwise as a user you are
>> in
>>>> a half baked position and the featureful part of cxf is kind of faked.
>>>>
>>>> Is the work that hard? Sime interceptors already play with the chain so
>>>> should be really doable and it matches the way register was designed
>> too.
>>>>
>>>> Le 26 avr. 2018 00:52, "Andriy Redko" <dr...@gmail.com> a écrit :
>>>>
>>>>> Hi Mark,
>>>>>
>>>>> I would agree with Andy here, the CXF interceptors / features have
>> existed
>>>>> way before the JAX-RS spec. Alhough it is possible to support
>> additional
>>>>> provider contracts in DynamicFeature, it is difficult to match it
>> exactly
>>>>> to the JAX-RS lifecycle. As an option, you may consider converting the
>>>>> LoggingInterceptor into full-feldged JAX-RS provider (if it makes sense
>>>>> for sure).
>>>>>
>>>>> Best Regards,
>>>>> Andriy Redko
>>>>>
>>>>>
>>>>>
>>>>> AM> Hi Mark,
>>>>>
>>>>> AM> For #1 - I'll take a look - I've been meaning to ever since I saw
>> the
>>>>> JIRA,
>>>>> AM> but I've been swamped lately. My bad.
>>>>>
>>>>> AM> For #2 - I'd like others to weigh in, but I do think that this is
>> the
>>>>> AM> intended behavior. IIUC, org.apache.cxf.feature.Feature existed
>>>>> before the
>>>>> AM> JAX-RS spec and is used in a variety of non-JAX-RS scenarios
>> (JAX-WS,
>>>>> AM> etc.). The LoggingInterceptor is not actually a JAX-RS provider -
>>>>> rather
>>>>> AM> it is an interceptor used on the CXF chain. JAX-RS Providers are
>>>>> typically
>>>>> AM> invoked from the JAXRSInInterceptor and JAXRSOutInterceptor on the
>>>>> chain.
>>>>> AM> It may be possible to add a LoggingInterceptor to the chain at that
>>>>> point,
>>>>> AM> but it doesn't seem advisable - I haven't done much with chain
>>>>> AM> manipulation, so would definitely recommend a second opinion here.
>>>>>
>>>>> AM> Thanks for the patch,
>>>>>
>>>>> AM> Andy
>>>>>
>>>>> AM> On Wed, Apr 25, 2018 at 3:26 PM, Mark Struberg
>>>>> <st...@yahoo.de.invalid>
>>>>> AM> wrote:
>>>>>
>>>>>>> hi folks!
>>>>>
>>>>>>> I have two questions:
>>>>>
>>>>>>> 1.) Could anybody plz take a quick look at CXF-7713 and review the
>>>>> patch?
>>>>>
>>>>>>> 2.) I've created a DynamicFeature @Provider and tried to register a
>> CXF
>>>>>>> LoggingInterceptor.
>>>>>>> And this doesn't work since it seems to only pick up
>>>>>>> javax.ws.rs.core.Feature instances, but not
>>>>>>> org.apache.cxf.feature.Feature
>>>>>
>>>>>>> Is this observation correct?
>>>>>>> Is this behaviour intended?
>>>>>
>>>>>>> I know I can register it via Bus#setFeatures, but that is not as
>>>>> modular
>>>>>>> in comparison to the @Provider.
>>>>>
>>>>>>> txs and LieGrue,
>>>>>>> strub
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>
>>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Computer Scientist
> http://www.adobe.com
Re: A few 'Feature' questions
Posted by Christian Schneider <ch...@die-schneider.net>.
I think your case is valid in general.
What I do not understand is why you do not install the logging feature in
production
( I hope you are talking about the new logging feature described here:
http://cxf.apache.org/docs/message-logging.html).
The feature is designed to be added to all services and then be enabled /
disabled via the logging configuration. So it should have almost no
performance impact
when switched off). I think it is very important to be able to enable
logging while in production if it is needed and you typically do not know
if it is needed at build time.
Christian
2018-04-27 8:36 GMT+02:00 Mark Struberg <st...@yahoo.de.invalid>:
> Sure, here is my use case:
>
> We want to make use of the LoggingFeature, but would love to completely
> disable it in production. So we don't even want to enable the Feature
> depending on a configuration setting.
> That means we also cannot use the @Feature annotation but need to apply it
> programmatically.
>
> I know that I can enable a Feature programmatically via the Bus. But
> setFeatures() has to be done at exactly the right point in time. This is a
> bit tricky as it depends on the integration scenario.
>
> In my case (Apache Meecrowave) I went the way of doing this in my
> Application.
>
> > @ApplicationScoped
> > @ApplicationPath("/api")
> > public class MyApp extends Application {
> > // configuration is done via Apache DeltaSpike
> > private static ConfigResolver.TypedResolver<Boolean> logEnabled
> > = ConfigResolver.resolve("myapp.cxf.logging.enabled")
> > .as(Boolean.class)
> > .evaluateVariables(true)
> > .withDefault(Boolean.FALSE)
> > .cacheFor(TimeUnit.MINUTES, 30);
> >
> > private @Inject Bus bus;
> >
> > @PostConstruct
> > public void initKonnektorApp() {
> > if (Boolean.TRUE == logEnabled.getValue()) {
> > log.info("CXF LogInterceptors enabled");
> > Collection<Feature> features = new ArrayList<>();
> > features.add(new LoggingFeature());
> > bus.setFeatures(features);
> > }
> > }
> > }
>
> This works great in Meecrowave since the Application is picked up as CDI
> bean and the Bus is also available via CDI.
> But this is actually not guaranteed, so it's not really portable. It isn't
> guaranteed to work that way in say IBM Liberty or Apache TomEE.
>
>
> That's the reason why I'd love to see a more portable version.
> Which brought me to using @DynamicFeature to register that Feature.
> But as already noted: cxf.Feature != javax rs.Feature
>
> Makes sense?
> Is there another way to enable that feature in a programmatic way which
> I've simply missed?
>
> txs and LieGrue,
> strub
>
>
>
>
> > Am 26.04.2018 um 22:22 schrieb Andrey Redko <dr...@gmail.com>:
> >
> > Yeah, certainly, would be good to get a bit more details or small code
> > snippets to understand the problem. Mark, is it possible? Thanks.
> >
> > Best Regards,
> > Andriy Redko
> >
> > On Thu, Apr 26, 2018, 12:40 AM Romain Manni-Bucau <rmannibucau@gmail.com
> >
> > wrote:
> >
> >> Hi guys
> >>
> >> Think CXF should support that case or support its own features (for cdi
> >> integ it is easy since we have the bus ;)). Otherwise as a user you are
> in
> >> a half baked position and the featureful part of cxf is kind of faked.
> >>
> >> Is the work that hard? Sime interceptors already play with the chain so
> >> should be really doable and it matches the way register was designed
> too.
> >>
> >> Le 26 avr. 2018 00:52, "Andriy Redko" <dr...@gmail.com> a écrit :
> >>
> >>> Hi Mark,
> >>>
> >>> I would agree with Andy here, the CXF interceptors / features have
> existed
> >>> way before the JAX-RS spec. Alhough it is possible to support
> additional
> >>> provider contracts in DynamicFeature, it is difficult to match it
> exactly
> >>> to the JAX-RS lifecycle. As an option, you may consider converting the
> >>> LoggingInterceptor into full-feldged JAX-RS provider (if it makes sense
> >>> for sure).
> >>>
> >>> Best Regards,
> >>> Andriy Redko
> >>>
> >>>
> >>>
> >>> AM> Hi Mark,
> >>>
> >>> AM> For #1 - I'll take a look - I've been meaning to ever since I saw
> the
> >>> JIRA,
> >>> AM> but I've been swamped lately. My bad.
> >>>
> >>> AM> For #2 - I'd like others to weigh in, but I do think that this is
> the
> >>> AM> intended behavior. IIUC, org.apache.cxf.feature.Feature existed
> >>> before the
> >>> AM> JAX-RS spec and is used in a variety of non-JAX-RS scenarios
> (JAX-WS,
> >>> AM> etc.). The LoggingInterceptor is not actually a JAX-RS provider -
> >>> rather
> >>> AM> it is an interceptor used on the CXF chain. JAX-RS Providers are
> >>> typically
> >>> AM> invoked from the JAXRSInInterceptor and JAXRSOutInterceptor on the
> >>> chain.
> >>> AM> It may be possible to add a LoggingInterceptor to the chain at that
> >>> point,
> >>> AM> but it doesn't seem advisable - I haven't done much with chain
> >>> AM> manipulation, so would definitely recommend a second opinion here.
> >>>
> >>> AM> Thanks for the patch,
> >>>
> >>> AM> Andy
> >>>
> >>> AM> On Wed, Apr 25, 2018 at 3:26 PM, Mark Struberg
> >>> <st...@yahoo.de.invalid>
> >>> AM> wrote:
> >>>
> >>>>> hi folks!
> >>>
> >>>>> I have two questions:
> >>>
> >>>>> 1.) Could anybody plz take a quick look at CXF-7713 and review the
> >>> patch?
> >>>
> >>>>> 2.) I've created a DynamicFeature @Provider and tried to register a
> CXF
> >>>>> LoggingInterceptor.
> >>>>> And this doesn't work since it seems to only pick up
> >>>>> javax.ws.rs.core.Feature instances, but not
> >>>>> org.apache.cxf.feature.Feature
> >>>
> >>>>> Is this observation correct?
> >>>>> Is this behaviour intended?
> >>>
> >>>>> I know I can register it via Bus#setFeatures, but that is not as
> >>> modular
> >>>>> in comparison to the @Provider.
> >>>
> >>>>> txs and LieGrue,
> >>>>> strub
> >>>
> >>>
> >>>
> >>>
> >>>
>
>
--
--
Christian Schneider
http://www.liquid-reality.de
Computer Scientist
http://www.adobe.com
Re: A few 'Feature' questions
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
Sure, here is my use case:
We want to make use of the LoggingFeature, but would love to completely disable it in production. So we don't even want to enable the Feature depending on a configuration setting.
That means we also cannot use the @Feature annotation but need to apply it programmatically.
I know that I can enable a Feature programmatically via the Bus. But setFeatures() has to be done at exactly the right point in time. This is a bit tricky as it depends on the integration scenario.
In my case (Apache Meecrowave) I went the way of doing this in my Application.
> @ApplicationScoped
> @ApplicationPath("/api")
> public class MyApp extends Application {
> // configuration is done via Apache DeltaSpike
> private static ConfigResolver.TypedResolver<Boolean> logEnabled
> = ConfigResolver.resolve("myapp.cxf.logging.enabled")
> .as(Boolean.class)
> .evaluateVariables(true)
> .withDefault(Boolean.FALSE)
> .cacheFor(TimeUnit.MINUTES, 30);
>
> private @Inject Bus bus;
>
> @PostConstruct
> public void initKonnektorApp() {
> if (Boolean.TRUE == logEnabled.getValue()) {
> log.info("CXF LogInterceptors enabled");
> Collection<Feature> features = new ArrayList<>();
> features.add(new LoggingFeature());
> bus.setFeatures(features);
> }
> }
> }
This works great in Meecrowave since the Application is picked up as CDI bean and the Bus is also available via CDI.
But this is actually not guaranteed, so it's not really portable. It isn't guaranteed to work that way in say IBM Liberty or Apache TomEE.
That's the reason why I'd love to see a more portable version.
Which brought me to using @DynamicFeature to register that Feature.
But as already noted: cxf.Feature != javax rs.Feature
Makes sense?
Is there another way to enable that feature in a programmatic way which I've simply missed?
txs and LieGrue,
strub
> Am 26.04.2018 um 22:22 schrieb Andrey Redko <dr...@gmail.com>:
>
> Yeah, certainly, would be good to get a bit more details or small code
> snippets to understand the problem. Mark, is it possible? Thanks.
>
> Best Regards,
> Andriy Redko
>
> On Thu, Apr 26, 2018, 12:40 AM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
>> Hi guys
>>
>> Think CXF should support that case or support its own features (for cdi
>> integ it is easy since we have the bus ;)). Otherwise as a user you are in
>> a half baked position and the featureful part of cxf is kind of faked.
>>
>> Is the work that hard? Sime interceptors already play with the chain so
>> should be really doable and it matches the way register was designed too.
>>
>> Le 26 avr. 2018 00:52, "Andriy Redko" <dr...@gmail.com> a écrit :
>>
>>> Hi Mark,
>>>
>>> I would agree with Andy here, the CXF interceptors / features have existed
>>> way before the JAX-RS spec. Alhough it is possible to support additional
>>> provider contracts in DynamicFeature, it is difficult to match it exactly
>>> to the JAX-RS lifecycle. As an option, you may consider converting the
>>> LoggingInterceptor into full-feldged JAX-RS provider (if it makes sense
>>> for sure).
>>>
>>> Best Regards,
>>> Andriy Redko
>>>
>>>
>>>
>>> AM> Hi Mark,
>>>
>>> AM> For #1 - I'll take a look - I've been meaning to ever since I saw the
>>> JIRA,
>>> AM> but I've been swamped lately. My bad.
>>>
>>> AM> For #2 - I'd like others to weigh in, but I do think that this is the
>>> AM> intended behavior. IIUC, org.apache.cxf.feature.Feature existed
>>> before the
>>> AM> JAX-RS spec and is used in a variety of non-JAX-RS scenarios (JAX-WS,
>>> AM> etc.). The LoggingInterceptor is not actually a JAX-RS provider -
>>> rather
>>> AM> it is an interceptor used on the CXF chain. JAX-RS Providers are
>>> typically
>>> AM> invoked from the JAXRSInInterceptor and JAXRSOutInterceptor on the
>>> chain.
>>> AM> It may be possible to add a LoggingInterceptor to the chain at that
>>> point,
>>> AM> but it doesn't seem advisable - I haven't done much with chain
>>> AM> manipulation, so would definitely recommend a second opinion here.
>>>
>>> AM> Thanks for the patch,
>>>
>>> AM> Andy
>>>
>>> AM> On Wed, Apr 25, 2018 at 3:26 PM, Mark Struberg
>>> <st...@yahoo.de.invalid>
>>> AM> wrote:
>>>
>>>>> hi folks!
>>>
>>>>> I have two questions:
>>>
>>>>> 1.) Could anybody plz take a quick look at CXF-7713 and review the
>>> patch?
>>>
>>>>> 2.) I've created a DynamicFeature @Provider and tried to register a CXF
>>>>> LoggingInterceptor.
>>>>> And this doesn't work since it seems to only pick up
>>>>> javax.ws.rs.core.Feature instances, but not
>>>>> org.apache.cxf.feature.Feature
>>>
>>>>> Is this observation correct?
>>>>> Is this behaviour intended?
>>>
>>>>> I know I can register it via Bus#setFeatures, but that is not as
>>> modular
>>>>> in comparison to the @Provider.
>>>
>>>>> txs and LieGrue,
>>>>> strub
>>>
>>>
>>>
>>>
>>>
Re: A few 'Feature' questions
Posted by Andrey Redko <dr...@gmail.com>.
Yeah, certainly, would be good to get a bit more details or small code
snippets to understand the problem. Mark, is it possible? Thanks.
Best Regards,
Andriy Redko
On Thu, Apr 26, 2018, 12:40 AM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Hi guys
>
> Think CXF should support that case or support its own features (for cdi
> integ it is easy since we have the bus ;)). Otherwise as a user you are in
> a half baked position and the featureful part of cxf is kind of faked.
>
> Is the work that hard? Sime interceptors already play with the chain so
> should be really doable and it matches the way register was designed too.
>
> Le 26 avr. 2018 00:52, "Andriy Redko" <dr...@gmail.com> a écrit :
>
>> Hi Mark,
>>
>> I would agree with Andy here, the CXF interceptors / features have existed
>> way before the JAX-RS spec. Alhough it is possible to support additional
>> provider contracts in DynamicFeature, it is difficult to match it exactly
>> to the JAX-RS lifecycle. As an option, you may consider converting the
>> LoggingInterceptor into full-feldged JAX-RS provider (if it makes sense
>> for sure).
>>
>> Best Regards,
>> Andriy Redko
>>
>>
>>
>> AM> Hi Mark,
>>
>> AM> For #1 - I'll take a look - I've been meaning to ever since I saw the
>> JIRA,
>> AM> but I've been swamped lately. My bad.
>>
>> AM> For #2 - I'd like others to weigh in, but I do think that this is the
>> AM> intended behavior. IIUC, org.apache.cxf.feature.Feature existed
>> before the
>> AM> JAX-RS spec and is used in a variety of non-JAX-RS scenarios (JAX-WS,
>> AM> etc.). The LoggingInterceptor is not actually a JAX-RS provider -
>> rather
>> AM> it is an interceptor used on the CXF chain. JAX-RS Providers are
>> typically
>> AM> invoked from the JAXRSInInterceptor and JAXRSOutInterceptor on the
>> chain.
>> AM> It may be possible to add a LoggingInterceptor to the chain at that
>> point,
>> AM> but it doesn't seem advisable - I haven't done much with chain
>> AM> manipulation, so would definitely recommend a second opinion here.
>>
>> AM> Thanks for the patch,
>>
>> AM> Andy
>>
>> AM> On Wed, Apr 25, 2018 at 3:26 PM, Mark Struberg
>> <st...@yahoo.de.invalid>
>> AM> wrote:
>>
>> >> hi folks!
>>
>> >> I have two questions:
>>
>> >> 1.) Could anybody plz take a quick look at CXF-7713 and review the
>> patch?
>>
>> >> 2.) I've created a DynamicFeature @Provider and tried to register a CXF
>> >> LoggingInterceptor.
>> >> And this doesn't work since it seems to only pick up
>> >> javax.ws.rs.core.Feature instances, but not
>> >> org.apache.cxf.feature.Feature
>>
>> >> Is this observation correct?
>> >> Is this behaviour intended?
>>
>> >> I know I can register it via Bus#setFeatures, but that is not as
>> modular
>> >> in comparison to the @Provider.
>>
>> >> txs and LieGrue,
>> >> strub
>>
>>
>>
>>
>>
Re: A few 'Feature' questions
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi guys
Think CXF should support that case or support its own features (for cdi
integ it is easy since we have the bus ;)). Otherwise as a user you are in
a half baked position and the featureful part of cxf is kind of faked.
Is the work that hard? Sime interceptors already play with the chain so
should be really doable and it matches the way register was designed too.
Le 26 avr. 2018 00:52, "Andriy Redko" <dr...@gmail.com> a écrit :
> Hi Mark,
>
> I would agree with Andy here, the CXF interceptors / features have existed
> way before the JAX-RS spec. Alhough it is possible to support additional
> provider contracts in DynamicFeature, it is difficult to match it exactly
> to the JAX-RS lifecycle. As an option, you may consider converting the
> LoggingInterceptor into full-feldged JAX-RS provider (if it makes sense
> for sure).
>
> Best Regards,
> Andriy Redko
>
>
>
> AM> Hi Mark,
>
> AM> For #1 - I'll take a look - I've been meaning to ever since I saw the
> JIRA,
> AM> but I've been swamped lately. My bad.
>
> AM> For #2 - I'd like others to weigh in, but I do think that this is the
> AM> intended behavior. IIUC, org.apache.cxf.feature.Feature existed
> before the
> AM> JAX-RS spec and is used in a variety of non-JAX-RS scenarios (JAX-WS,
> AM> etc.). The LoggingInterceptor is not actually a JAX-RS provider -
> rather
> AM> it is an interceptor used on the CXF chain. JAX-RS Providers are
> typically
> AM> invoked from the JAXRSInInterceptor and JAXRSOutInterceptor on the
> chain.
> AM> It may be possible to add a LoggingInterceptor to the chain at that
> point,
> AM> but it doesn't seem advisable - I haven't done much with chain
> AM> manipulation, so would definitely recommend a second opinion here.
>
> AM> Thanks for the patch,
>
> AM> Andy
>
> AM> On Wed, Apr 25, 2018 at 3:26 PM, Mark Struberg
> <st...@yahoo.de.invalid>
> AM> wrote:
>
> >> hi folks!
>
> >> I have two questions:
>
> >> 1.) Could anybody plz take a quick look at CXF-7713 and review the
> patch?
>
> >> 2.) I've created a DynamicFeature @Provider and tried to register a CXF
> >> LoggingInterceptor.
> >> And this doesn't work since it seems to only pick up
> >> javax.ws.rs.core.Feature instances, but not
> >> org.apache.cxf.feature.Feature
>
> >> Is this observation correct?
> >> Is this behaviour intended?
>
> >> I know I can register it via Bus#setFeatures, but that is not as modular
> >> in comparison to the @Provider.
>
> >> txs and LieGrue,
> >> strub
>
>
>
>
>
Re: A few 'Feature' questions
Posted by Andriy Redko <dr...@gmail.com>.
Hi Mark,
I would agree with Andy here, the CXF interceptors / features have existed
way before the JAX-RS spec. Alhough it is possible to support additional
provider contracts in DynamicFeature, it is difficult to match it exactly
to the JAX-RS lifecycle. As an option, you may consider converting the
LoggingInterceptor into full-feldged JAX-RS provider (if it makes sense
for sure).
Best Regards,
Andriy Redko
AM> Hi Mark,
AM> For #1 - I'll take a look - I've been meaning to ever since I saw the JIRA,
AM> but I've been swamped lately. My bad.
AM> For #2 - I'd like others to weigh in, but I do think that this is the
AM> intended behavior. IIUC, org.apache.cxf.feature.Feature existed before the
AM> JAX-RS spec and is used in a variety of non-JAX-RS scenarios (JAX-WS,
AM> etc.). The LoggingInterceptor is not actually a JAX-RS provider - rather
AM> it is an interceptor used on the CXF chain. JAX-RS Providers are typically
AM> invoked from the JAXRSInInterceptor and JAXRSOutInterceptor on the chain.
AM> It may be possible to add a LoggingInterceptor to the chain at that point,
AM> but it doesn't seem advisable - I haven't done much with chain
AM> manipulation, so would definitely recommend a second opinion here.
AM> Thanks for the patch,
AM> Andy
AM> On Wed, Apr 25, 2018 at 3:26 PM, Mark Struberg <st...@yahoo.de.invalid>
AM> wrote:
>> hi folks!
>> I have two questions:
>> 1.) Could anybody plz take a quick look at CXF-7713 and review the patch?
>> 2.) I've created a DynamicFeature @Provider and tried to register a CXF
>> LoggingInterceptor.
>> And this doesn't work since it seems to only pick up
>> javax.ws.rs.core.Feature instances, but not
>> org.apache.cxf.feature.Feature
>> Is this observation correct?
>> Is this behaviour intended?
>> I know I can register it via Bus#setFeatures, but that is not as modular
>> in comparison to the @Provider.
>> txs and LieGrue,
>> strub
Re: A few 'Feature' questions
Posted by Andy McCright <j....@gmail.com>.
Hi Mark,
For #1 - I'll take a look - I've been meaning to ever since I saw the JIRA,
but I've been swamped lately. My bad.
For #2 - I'd like others to weigh in, but I do think that this is the
intended behavior. IIUC, org.apache.cxf.feature.Feature existed before the
JAX-RS spec and is used in a variety of non-JAX-RS scenarios (JAX-WS,
etc.). The LoggingInterceptor is not actually a JAX-RS provider - rather
it is an interceptor used on the CXF chain. JAX-RS Providers are typically
invoked from the JAXRSInInterceptor and JAXRSOutInterceptor on the chain.
It may be possible to add a LoggingInterceptor to the chain at that point,
but it doesn't seem advisable - I haven't done much with chain
manipulation, so would definitely recommend a second opinion here.
Thanks for the patch,
Andy
On Wed, Apr 25, 2018 at 3:26 PM, Mark Struberg <st...@yahoo.de.invalid>
wrote:
> hi folks!
>
> I have two questions:
>
> 1.) Could anybody plz take a quick look at CXF-7713 and review the patch?
>
> 2.) I've created a DynamicFeature @Provider and tried to register a CXF
> LoggingInterceptor.
> And this doesn't work since it seems to only pick up
> javax.ws.rs.core.Feature instances, but not
> org.apache.cxf.feature.Feature
>
> Is this observation correct?
> Is this behaviour intended?
>
> I know I can register it via Bus#setFeatures, but that is not as modular
> in comparison to the @Provider.
>
> txs and LieGrue,
> strub
>
>
>