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 <[email protected]>:
> 
> 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 <[email protected]>
> 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" <[email protected]> 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
>>> <[email protected]>
>>> 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
>>> 
>>> 
>>> 
>>> 
>>> 

Reply via email to