Re: A few 'Feature' questions

[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