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 put the active ones in the server map to be able to reuse it later no?
Le 24 déc. 2017 19:07, "Andriy Redko" <[email protected]> a écrit : > 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" <[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> >>> >> > > > > > > > > > > > > > > > > > > > > > > >
