No API sounds good. Just to clarify the second part. "By reflection" you mean just go with classpath scan?
RMB> No hard dep on any api would be nice but a chain can work even if by reflection no? Kind of test them all. Then RMB> put the active ones in the server map to be able to reuse it later no? RMB> Le 24 déc. 2017 19:07, "Andriy Redko" <[email protected]> a écrit : RMB> Hey guys, RMB> So I have been looking around to understand how the activation around CDI is worked out by others, RMB> including ConfigResolver and Jersey. Here is what I have discovered so far. RMB> #1. Deltaspike. Uses own ConfigResolver approach: among other things, allows to deactivate beans / extensions RMB> using a list of config sources. Because Deltaspike is pure CDI, all extensions are automatically discovered but RMB> could be deactivated by means of ConfigResolver. In case of CXF, we could take a similar approach by activating RMB> the necessary beans (as most of our components are non-beans archives and as such, won't be discovered by CDI), RMB> f.e.: RMB> <full.class.name>.active = true RMB> <full.class.name>.active = true RMB> <full.class.name>.active = true RMB> Once the JAXRS extension is picked up by CDI runtime, it would add annotated types during the discovery phase for RMB> activated providers / features. In the future, this could be done using beans.xml (https://issues.jboss.org/browse/CDI-526), RMB> hopefully, but as Romain pointed out, it is problematic at the moment. RMB> We could make it per-module (so each component would provide such configuration) or bundle as a single module RMB> (f.e. cxf-cdi-discovery, or cxf-cdi-beans, ...). Surely, each application would be able to override any of the RMB> activations and/or provide its own if necessary. RMB> #2. Jersey. Uses own mechanism to autodiscover and register features and providers. Essentially, in a simplified form, it could RMB> be summarized like this. Each module (component) provides binding (in a form contract -> class -> scope) which it thinks should be RMB> autodiscovered by the runtime (in this case, CDI). The bindings are brought into context using service loader. In this case, every RMB> component has a compile-time dependency on CDI API. RMB> No doubts, there are more options available. Picking between the ones above, could/should we implement #1? If yes, should we build it RMB> on top of Microprofile Config API (https://github.com/eclipse/microprofile-config)? Or just keep it as simple as RMB> possible (around new/use existing property file)? What do you think guys? RMB> Thanks. RMB> Best Regards, RMB> 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" <[email protected]> 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 <[email protected]> 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 <[email protected]> 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" <[email protected]> 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>> [email protected]> 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>> [email protected]> 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>> [email protected]> 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>> [email protected]> 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>> >>> >>
