Hey guys, So I have been looking around to understand how the activation around CDI is worked out by others, including ConfigResolver and Jersey. Here is what I have discovered so far.
#1. Deltaspike. Uses own ConfigResolver approach: among other things, allows to deactivate beans / extensions using a list of config sources. Because Deltaspike is pure CDI, all extensions are automatically discovered but could be deactivated by means of ConfigResolver. In case of CXF, we could take a similar approach by activating the necessary beans (as most of our components are non-beans archives and as such, won't be discovered by CDI), f.e.: <full.class.name>.active = true <full.class.name>.active = true <full.class.name>.active = true Once the JAXRS extension is picked up by CDI runtime, it would add annotated types during the discovery phase for activated providers / features. In the future, this could be done using beans.xml (https://issues.jboss.org/browse/CDI-526), hopefully, but as Romain pointed out, it is problematic at the moment. We could make it per-module (so each component would provide such configuration) or bundle as a single module (f.e. cxf-cdi-discovery, or cxf-cdi-beans, ...). Surely, each application would be able to override any of the activations and/or provide its own if necessary. #2. Jersey. Uses own mechanism to autodiscover and register features and providers. Essentially, in a simplified form, it could be summarized like this. Each module (component) provides binding (in a form contract -> class -> scope) which it thinks should be autodiscovered by the runtime (in this case, CDI). The bindings are brought into context using service loader. In this case, every component has a compile-time dependency on CDI API. No doubts, there are more options available. Picking between the ones above, could/should we implement #1? If yes, should we build it on top of Microprofile Config API (https://github.com/eclipse/microprofile-config)? Or just keep it as simple as possible (around new/use existing property file)? What do you think guys? Thanks. Best Regards, Andriy Redko RMB> Something like deltaspike where it is on by default and deactivable by config is not bad for such modules. Issue RMB> is: what is config? For spring it is obvious but for cdi it must be the 2 mentionned solution and maybe a 3rd fallback with a cxf specific solution - or system props. RMB> An alternate more advanced option can be a cxf-autoload module which would read some classpath file like a spi RMB> where cxf modules could register such feature but would be on only when this module is in the cp. Maybe something RMB> to study but to be honest i believe more in the previous integrations (as a user). RMB> Le 23 déc. 2017 20:29, "Sergey Beryozkin" <sberyoz...@gmail.com> a écrit : RMB> Well, was not clear what you meant, the whole conversation was about optionally choosing whether to auto-load a RMB> given provider or not with CDI and you referred to SpringBoot which could do some magic and CXF having the related RMB> module and possibly getting some ideas from there and I thought I'd clarify that there was no magic there in the RMB> Spring-Boot starters/auto-configuration, nothing SpringBoot or Spring specific (well we do refer to Spring to scan RMB> but CDI can scan too) about optionally loading specific providers from the specific packages. RMB> CXF itself ships many providers in different modules and packages and it is hard to see how one can let users RMB> control auto-loading them (which is) without letting users choose at the config time... RMB> Cheers, Sergey RMB> On 22/12/17 23:15, Andriy Redko wrote: RMB> That is right, I was not refering to autodiscovery but Spring Boot module we RMB> have. As per my understading, CDI has different means for achieving the desired RMB> outcomes but Spring is more flexible in this regard. SB>> CXF SpringBoot module does not do any auto-discovery. The code is in the SB>> rt/frontend/jaxrs/.../spring which can be loaded by the spring boot SB>> module, and it does what I said in the prev email, scans for the classes SB>> annotated as providers in the user-requested packages... SB>> Cheers, Sergey SB>> On 22/12/17 22:40, Andriy Redko wrote: RMB> Documenting make sense. To project it to Spring-based runtime, fe, without RMB> Spring-specific annotations + configuration the discovery won't happen ... RMB> But there is Spring Boot which could do magic here, and CXF does have a RMB> module for it. Same, in theory, could be possible with CXF+CDI (let say by RMB> adding `cxf-cdi` module where we could supply the limited, handcrafted RMB> set of CDI beans available for discovery in the beans.xml). Do you think it RMB> is worth exploring the idea? RMB> Best Regards, RMB> Andriy Redko JDA>> I would do nothing but document a strategy that users can implement. The JDA>> biggest question I have is whether a provider like this should be JDA>> registered automatically? Does that happen with spring based runtimes? JDA>> What about when there is no DI framework present? Is it clear enough that JDA>> user would need to list it in their Application class as a singleton/class? JDA>> John JDA>> On Fri, Dec 22, 2017 at 5:08 PM Andriy Redko <drr...@gmail.com> wrote: RMB> Sure, removed/reverted. So here are the general thoughts. Yes, most (if RMB> not all) of the providers/features/... are not CDI RMB> specific and as such, they are not bean archives (and it make sense). Now, RMB> how could we make the CXF more CDIish? There RMB> are a couple of option we could explore, but what would be the idiomatic RMB> CDI way? RMB> Best Regards, RMB> Andriy Redko JDA>> Personally, I would actually recommend removing the beans.xml from RMB> open tracing (and really any module that isn't JDA>> a cdi specific module). While it does allow for a bit more automatic RMB> binding, my question was more around what is JDA>> missing. I missed the fact that there is no build in automatic RMB> discovery of providers in CDI if they're not CDI JDA>> managed - which is OK and the answer I was working through. JDA>> And realistically, this issue is not specific to the open tracing RMB> integration, I can replicate it with other JDA>> providers. Its just a matter of documenting and knowing what to RMB> setup. JDA>> So if you don't mind, I'd like to revert that commit; and add some RMB> docs around how to create an automatically registered provider. JDA>> John JDA>> On 2017-12-22 15:24, Romain Manni-Bucau <rmannibu...@gmail.com> RMB> wrote: RMB> How can i disable it now? Tink that cxf feature - even if in separate RMB> modules - shouldnt be auto registered until it has a deactivable flag - RMB> classpath properties + overridable through system prop. RMB> Wdyt? RMB> Le 22 déc. 2017 18:38, "Andriy Redko" <drr...@gmail.com> a écrit : RMB> Hi Sergey, RMB> It wasn't (for CDI only), but it could have been always included RMB> manually. RMB> Thanks. RMB> Best Regards, RMB> Andriy Redko SB>> Hi Andriy SB>> So how was a JAX-RS (OpenTracing) Feature discovered without RMB> beans.xml RMB> ? SB>> Cheers, Sergey SB>> On 22/12/17 17:24, Andriy Redko wrote: RMB> The beans.xml was missed indeed, I added it and OpenTracingFeature RMB> has RMB> been discovered right away. RMB> The commit is on its way. Thanks! RMB> Best Regards, RMB> Andriy Redko JDA>> I'm holding off on doing anything to fix it. For one, a user RMB> may RMB> not want to use the global tracer so making it JDA>> so that they register it makes more sense. Ultimately to RMB> solve RMB> it, I think we should be moving server JDA>> customizations outside of CDI to ensure that it can be auto RMB> registered. JDA>> John JDA>> On Fri, Dec 22, 2017 at 11:12 AM Andriy Redko < RMB> wrote: JDA>> Hey John, JDA>> The OpenTracingFeature RMB> (org.apache.cxf.tracing.opentracing.jaxrs RMB> package) is JAX-RS feature, JDA>> which JAXRS CDI extension should recognize out of the box. RMB> There RMB> is also CXF feature ( JDA>> in org.apache.cxf.tracing.opentracing package) to be used for RMB> JAX-WS services. The only explanation JDA>> I have why it is not being picked up it the absense of RMB> bean.xml RMB> so we could fix that. I will JDA>> take a look shorly (if you haven't figured this one out RMB> already). RMB> Thanks. JDA>> Best Regards, JDA>> Andriy Redko RMB> JDA>> I'm not sure either, this is the behavior I see in the RMB> code: RMB> JDA>> - Register JAX-RS resources (with @ApplicationPath) RMB> JDA>> - Register JAX-RS resources (with @Path) RMB> JDA>> - Register JAX-RS providers (with JAX-RS @Provider) RMB> JDA>> - Register JAX-RS features (with JAX-RS @Feature) RMB> JDA>> - Register CXF features (doesn't care if it has a CXF RMB> @Provider RMB> annotation but I see the OpenTracing one does have it) RMB> JDA>> - Otherwise we assume its the CXF Bus object RMB> JDA>> There's not much happening with a CXF @Provider RMB> declaration in RMB> the extension. But at the end of the day, I'm only RMB> JDA>> dealing with a JAX-RS @Provider and that doesn't get RMB> registered RMB> since it's not a CDI bean. I don't see any issue RMB> JDA>> registering CXF @Provider this way as well, but its RMB> possible RMB> it's not a CDI bean still, but that's ultimately what the customizer RMB> was RMB> put in for. RMB> JDA>> John RMB> JDA>> On 2017-12-22 09:56, Sergey Beryozkin < RMB> sberyoz...@gmail.com> RMB> wrote: RMB> >>> Sure, I just don't understand what is the difference between RMB> a RMB> JAX-RS RMB> >>> feature and CXF feature, as far as the CXF CDI code is RMB> concerned. RMB> If it RMB> >>> can load the JAX-RS features which have not been written RMB> with CDI RMB> in RMB> >>> mind, why can't it load CXF features without some extra work RMB> going into RMB> >>> these features... RMB> >>> Thanks, Sergey RMB> >>> On 22/12/17 14:50, John D. Ament wrote: RMB> >>> > That's not really the issue though. The extension will RMB> only RMB> receive CDI managed beans. Take a look at my pull to see what I had RMB> to do RMB> to get it to register automatically. If nothing else, this is an RMB> argument RMB> for moving JAXRSServer Customization into core and using service RMB> loader RMB> :-) Perhaps after the new year. RMB> >>> > RMB> >>> > On 2017-12-22 09:23, Sergey Beryozkin < RMB> sberyoz...@gmail.com> RMB> wrote: RMB> >>> >> I was not referring the OpenTracing module offering a CDI RMB> extension, but RMB> >>> >> to the work Andriy did in the CXF CDI integration where RMB> the RMB> providers RMB> >>> >> and feature are picked up. Thought, when we were RMB> discussing RMB> the SSE RMB> >>> >> feature I thought Andriy said it was looking at the CXF RMB> @Provider as RMB> >>> >> well, may be I misunderstood. RMB> >>> >> Updating the CDI code to check CXF @Provider, if it is not RMB> already RMB> >>> >> checked, makes sense IMHO RMB> >>> >> RMB> >>> >> Sergey RMB> >>> >> On 22/12/17 14:08, John D. Ament wrote: RMB> >>> >>> Actually one more thing. The CDI extension only looks RMB> for RMB> JAX-RS @Provider not CXF @Provider. RMB> >>> >>> RMB> >>> >>> On 2017-12-22 09:06, "John D. Ament"< RMB> johndam...@apache.org> RMB> wrote: RMB> >>> >>>> I'm not sure what the CDI extension has to do with RMB> this. It RMB> has no bean defining annotations, and there is no beans.xml in the RMB> JAR that RMB> it ships with so I'm not sure it would be picked up by the extension. RMB> >>> >>>> RMB> >>> >>>> There's nothing special done for TomcatwarTest to make RMB> more RMB> JARs available, right? RMB> >>> >>>> RMB> >>> >>>> On 2017-12-22 08:15, Sergey Beryozkin < RMB> sberyoz...@gmail.com> RMB> wrote: RMB> >>> >>>>> It is annotated with CXF @Provider annotation - should RMB> be RMB> picked up by RMB> >>> >>>>> the CXF CDI extension RMB> >>> >>>>> RMB> >>> >>>>> Sergey RMB> >>> >>>>> On 22/12/17 13:07, John D. Ament wrote: RMB> >>> >>>>>> I'm trying to finish up testing CDI injection of RMB> Context RMB> objects. The one RMB> >>> >>>>>> area I'm struggling with is the automatic RMB> registration of RMB> this feature. I RMB> >>> >>>>>> added a dependency on OpenTracing, just to confirm RMB> that RMB> injection via CDI RMB> >>> >>>>>> works (and to be honest, this is one of my use cases, RMB> working with RMB> >>> >>>>>> tracing). However, it seems that this feature isn't RMB> automatically RMB> >>> >>>>>> registered via CDI. Is there something I have to do RMB> to RMB> make it work? RMB> >>> >>>>>> RMB> >>> >>>>>> John RMB> >>> >>>>>> RMB> >>> >>>>> RMB> >>> >>>> RMB> >>> >>
