Something like deltaspike where it is on by default and deactivable by config is not bad for such modules. Issue 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.
An alternate more advanced option can be a cxf-autoload module which would read some classpath file like a spi where cxf modules could register such feature but would be on only when this module is in the cp. Maybe something to study but to be honest i believe more in the previous integrations (as a user). Le 23 déc. 2017 20:29, "Sergey Beryozkin" <[email protected]> a écrit : > Well, was not clear what you meant, the whole conversation was about > optionally choosing whether to auto-load a given provider or not with CDI > and you referred to SpringBoot which could do some magic and CXF having the > related module and possibly getting some ideas from there and I thought I'd > clarify that there was no magic there in the Spring-Boot > starters/auto-configuration, nothing SpringBoot or Spring specific (well we > do refer to Spring to scan but CDI can scan too) about optionally loading > specific providers from the specific packages. > > CXF itself ships many providers in different modules and packages and it > is hard to see how one can let users control auto-loading them (which is) > without letting users choose at the config time... > > Cheers, Sergey > > > On 22/12/17 23:15, Andriy Redko wrote: > >> That is right, I was not refering to autodiscovery but Spring Boot module >> we >> have. As per my understading, CDI has different means for achieving the >> desired >> 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: >> >>> Documenting make sense. To project it to Spring-based runtime, fe, >>>> without >>>> Spring-specific annotations + configuration the discovery won't happen >>>> ... >>>> But there is Spring Boot which could do magic here, and CXF does have a >>>> module for it. Same, in theory, could be possible with CXF+CDI (let say >>>> by >>>> adding `cxf-cdi` module where we could supply the limited, handcrafted >>>> set of CDI beans available for discovery in the beans.xml). Do you >>>> think it >>>> is worth exploring the idea? >>>> >>> >> Best Regards, >>>> 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: >>>> >>> >> Sure, removed/reverted. So here are the general thoughts. Yes, most (if >>>>>> not all) of the providers/features/... are not CDI >>>>>> specific and as such, they are not bean archives (and it make sense). >>>>>> Now, >>>>>> how could we make the CXF more CDIish? There >>>>>> are a couple of option we could explore, but what would be the >>>>>> idiomatic >>>>>> CDI way? >>>>>> >>>>> >> Best Regards, >>>>>> Andriy Redko >>>>>> >>>>> >> JDA> Personally, I would actually recommend removing the beans.xml from >>>>>> open tracing (and really any module that isn't >>>>>> JDA> a cdi specific module). While it does allow for a bit more >>>>>> automatic >>>>>> binding, my question was more around what is >>>>>> JDA> missing. I missed the fact that there is no build in automatic >>>>>> 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 >>>>>> integration, I can replicate it with other >>>>>> JDA> providers. Its just a matter of documenting and knowing what to >>>>>> setup. >>>>>> >>>>> >> JDA> So if you don't mind, I'd like to revert that commit; and add some >>>>>> docs around how to create an automatically registered provider. >>>>>> >>>>> >> JDA> John >>>>>> >>>>> >> JDA> On 2017-12-22 15:24, Romain Manni-Bucau <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> How can i disable it now? Tink that cxf feature - even if in separate >>>>>>>> modules - shouldnt be auto registered until it has a deactivable >>>>>>>> flag - >>>>>>>> classpath properties + overridable through system prop. >>>>>>>> >>>>>>> >> Wdyt? >>>>>>>> >>>>>>> >> Le 22 déc. 2017 18:38, "Andriy Redko" <[email protected]> a écrit : >>>>>>>> >>>>>>> >> Hi Sergey, >>>>>>>>> >>>>>>>> >> It wasn't (for CDI only), but it could have been always included >>>>>>>>> >>>>>>>> manually. >>>>>> >>>>>>> Thanks. >>>>>>>>> >>>>>>>> >> Best Regards, >>>>>>>>> Andriy Redko >>>>>>>>> >>>>>>>> >> SB> Hi Andriy >>>>>>>>> >>>>>>>> >> SB> So how was a JAX-RS (OpenTracing) Feature discovered without >>>>>>>>> >>>>>>>> beans.xml >>>>>> >>>>>>> ? >>>>>>>>> >>>>>>>> >> SB> Cheers, Sergey >>>>>>>>> SB> On 22/12/17 17:24, Andriy Redko wrote: >>>>>>>>> >>>>>>>>>> The beans.xml was missed indeed, I added it and OpenTracingFeature >>>>>>>>>>> >>>>>>>>>> has >>>>>> >>>>>>> been discovered right away. >>>>>>>>> >>>>>>>>>> The commit is on its way. Thanks! >>>>>>>>>>> >>>>>>>>>> >> Best Regards, >>>>>>>>>>> Andriy Redko >>>>>>>>>>> >>>>>>>>>> >> JDA> I'm holding off on doing anything to fix it. For one, a user >>>>>>>>>>> >>>>>>>>>> may >>>>>> >>>>>>> not want to use the global tracer so making it >>>>>>>>> >>>>>>>>>> JDA> so that they register it makes more sense. Ultimately to >>>>>>>>>>> >>>>>>>>>> solve >>>>>> >>>>>>> it, I think we should be moving server >>>>>>>>> >>>>>>>>>> JDA> customizations outside of CDI to ensure that it can be auto >>>>>>>>>>> >>>>>>>>>> registered. >>>>>>>>> >>>>>>>> >> >> JDA> John >>>>>>>>>>> >>>>>>>>>> >> >> JDA> On Fri, Dec 22, 2017 at 11:12 AM Andriy Redko < >>>>>>>>>>> >>>>>>>>>> [email protected]> >>>>>> >>>>>>> wrote: >>>>>>>>> >>>>>>>> >> JDA> Hey John, >>>>>>>>>>> >>>>>>>>>> >> JDA> The OpenTracingFeature >>>>>>>>>>> >>>>>>>>>> (org.apache.cxf.tracing.opentracing.jaxrs >>>>>> >>>>>>> package) is JAX-RS feature, >>>>>>>>> >>>>>>>>>> JDA> which JAXRS CDI extension should recognize out of the box. >>>>>>>>>>> >>>>>>>>>> There >>>>>> >>>>>>> is also CXF feature ( >>>>>>>>> >>>>>>>>>> JDA> in org.apache.cxf.tracing.opentracing package) to be used >>>>>>>>>>> for >>>>>>>>>>> >>>>>>>>>> JAX-WS services. The only explanation >>>>>>>>> >>>>>>>>>> JDA> I have why it is not being picked up it the absense of >>>>>>>>>>> >>>>>>>>>> bean.xml >>>>>> >>>>>>> so we could fix that. I will >>>>>>>>> >>>>>>>>>> JDA> take a look shorly (if you haven't figured this one out >>>>>>>>>>> >>>>>>>>>> already). >>>>>> >>>>>>> Thanks. >>>>>>>>> >>>>>>>> >> JDA> Best Regards, >>>>>>>>>>> JDA> Andriy Redko >>>>>>>>>>> >>>>>>>>>> >> >> JDA>> I'm not sure either, this is the behavior I see in the >>>>>>>>>>> >>>>>>>>>> code: >>>>>> >>>>> >> JDA>> - Register JAX-RS resources (with @ApplicationPath) >>>>>>>>>>> JDA>> - Register JAX-RS resources (with @Path) >>>>>>>>>>> JDA>> - Register JAX-RS providers (with JAX-RS @Provider) >>>>>>>>>>> JDA>> - Register JAX-RS features (with JAX-RS @Feature) >>>>>>>>>>> JDA>> - Register CXF features (doesn't care if it has a CXF >>>>>>>>>>> >>>>>>>>>> @Provider >>>>>> >>>>>>> annotation but I see the OpenTracing one does have it) >>>>>>>>> >>>>>>>>>> JDA>> - Otherwise we assume its the CXF Bus object >>>>>>>>>>> >>>>>>>>>> >> JDA>> There's not much happening with a CXF @Provider >>>>>>>>>>> >>>>>>>>>> declaration in >>>>>> >>>>>>> the extension. But at the end of the day, I'm only >>>>>>>>> >>>>>>>>>> JDA>> dealing with a JAX-RS @Provider and that doesn't get >>>>>>>>>>> >>>>>>>>>> registered >>>>>> >>>>>>> since it's not a CDI bean. I don't see any issue >>>>>>>>> >>>>>>>>>> JDA>> registering CXF @Provider this way as well, but its >>>>>>>>>>> >>>>>>>>>> possible >>>>>> >>>>>>> it's not a CDI bean still, but that's ultimately what the customizer >>>>>>>>> >>>>>>>> was >>>>>> >>>>>>> put in for. >>>>>>>>> >>>>>>>> >> JDA>> John >>>>>>>>>>> >>>>>>>>>> >> JDA>> On 2017-12-22 09:56, Sergey Beryozkin < >>>>>>>>>>> >>>>>>>>>> [email protected]> >>>>>> >>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>> Sure, I just don't understand what is the difference >>>>>>>>>>> between >>>>>>>>>>> >>>>>>>>>> a >>>>>> >>>>>>> JAX-RS >>>>>>>>> >>>>>>>>>> >>> feature and CXF feature, as far as the CXF CDI code is >>>>>>>>>>> >>>>>>>>>> concerned. >>>>>> >>>>>>> If it >>>>>>>>> >>>>>>>>>> >>> can load the JAX-RS features which have not been written >>>>>>>>>>> >>>>>>>>>> with CDI >>>>>> >>>>>>> in >>>>>>>>> >>>>>>>>>> >>> mind, why can't it load CXF features without some extra >>>>>>>>>>> work >>>>>>>>>>> >>>>>>>>>> going into >>>>>>>>> >>>>>>>>>> >>> these features... >>>>>>>>>>> >>>>>>>>>> >> >>> Thanks, Sergey >>>>>>>>>>> >>> On 22/12/17 14:50, John D. Ament wrote: >>>>>>>>>>> >>> > That's not really the issue though. The extension will >>>>>>>>>>> >>>>>>>>>> only >>>>>> >>>>>>> receive CDI managed beans. Take a look at my pull to see what I had >>>>>>>>> >>>>>>>> to do >>>>>> >>>>>>> to get it to register automatically. If nothing else, this is an >>>>>>>>> >>>>>>>> argument >>>>>> >>>>>>> for moving JAXRSServer Customization into core and using service >>>>>>>>> >>>>>>>> loader >>>>>> >>>>>>> :-) Perhaps after the new year. >>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>> >>> > On 2017-12-22 09:23, Sergey Beryozkin < >>>>>>>>>>> >>>>>>>>>> [email protected]> >>>>>> >>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>> >> I was not referring the OpenTracing module offering a >>>>>>>>>>> CDI >>>>>>>>>>> >>>>>>>>>> extension, but >>>>>>>>> >>>>>>>>>> >>> >> to the work Andriy did in the CXF CDI integration where >>>>>>>>>>> >>>>>>>>>> the >>>>>> >>>>>>> providers >>>>>>>>> >>>>>>>>>> >>> >> and feature are picked up. Thought, when we were >>>>>>>>>>> >>>>>>>>>> discussing >>>>>> >>>>>>> the SSE >>>>>>>>> >>>>>>>>>> >>> >> feature I thought Andriy said it was looking at the CXF >>>>>>>>>>> >>>>>>>>>> @Provider as >>>>>>>>> >>>>>>>>>> >>> >> well, may be I misunderstood. >>>>>>>>>>> >>> >> Updating the CDI code to check CXF @Provider, if it >>>>>>>>>>> is not >>>>>>>>>>> >>>>>>>>>> already >>>>>>>>> >>>>>>>>>> >>> >> checked, makes sense IMHO >>>>>>>>>>> >>> >> >>>>>>>>>>> >>> >> Sergey >>>>>>>>>>> >>> >> On 22/12/17 14:08, John D. Ament wrote: >>>>>>>>>>> >>> >>> Actually one more thing. The CDI extension only >>>>>>>>>>> looks >>>>>>>>>>> >>>>>>>>>> for >>>>>> >>>>>>> JAX-RS @Provider not CXF @Provider. >>>>>>>>> >>>>>>>>>> >>> >>> >>>>>>>>>>> >>> >>> On 2017-12-22 09:06, "John D. Ament"< >>>>>>>>>>> >>>>>>>>>> [email protected]> >>>>>> >>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>> >>>> I'm not sure what the CDI extension has to do with >>>>>>>>>>> >>>>>>>>>> this. It >>>>>> >>>>>>> has no bean defining annotations, and there is no beans.xml in the >>>>>>>>> >>>>>>>> JAR that >>>>>> >>>>>>> it ships with so I'm not sure it would be picked up by the extension. >>>>>>>>> >>>>>>>>>> >>> >>>> >>>>>>>>>>> >>> >>>> There's nothing special done for TomcatwarTest to >>>>>>>>>>> make >>>>>>>>>>> >>>>>>>>>> more >>>>>> >>>>>>> JARs available, right? >>>>>>>>> >>>>>>>>>> >>> >>>> >>>>>>>>>>> >>> >>>> On 2017-12-22 08:15, Sergey Beryozkin < >>>>>>>>>>> >>>>>>>>>> [email protected]> >>>>>> >>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>> >>>>> It is annotated with CXF @Provider annotation - >>>>>>>>>>> should >>>>>>>>>>> >>>>>>>>>> be >>>>>> >>>>>>> picked up by >>>>>>>>> >>>>>>>>>> >>> >>>>> the CXF CDI extension >>>>>>>>>>> >>> >>>>> >>>>>>>>>>> >>> >>>>> Sergey >>>>>>>>>>> >>> >>>>> On 22/12/17 13:07, John D. Ament wrote: >>>>>>>>>>> >>> >>>>>> I'm trying to finish up testing CDI injection of >>>>>>>>>>> >>>>>>>>>> Context >>>>>> >>>>>>> objects. The one >>>>>>>>> >>>>>>>>>> >>> >>>>>> area I'm struggling with is the automatic >>>>>>>>>>> >>>>>>>>>> registration of >>>>>> >>>>>>> this feature. I >>>>>>>>> >>>>>>>>>> >>> >>>>>> added a dependency on OpenTracing, just to confirm >>>>>>>>>>> >>>>>>>>>> that >>>>>> >>>>>>> injection via CDI >>>>>>>>> >>>>>>>>>> >>> >>>>>> works (and to be honest, this is one of my use >>>>>>>>>>> cases, >>>>>>>>>>> >>>>>>>>>> working with >>>>>>>>> >>>>>>>>>> >>> >>>>>> tracing). However, it seems that this feature >>>>>>>>>>> isn't >>>>>>>>>>> >>>>>>>>>> automatically >>>>>>>>> >>>>>>>>>> >>> >>>>>> registered via CDI. Is there something I have to >>>>>>>>>>> do >>>>>>>>>>> >>>>>>>>>> to >>>>>> >>>>>>> make it work? >>>>>>>>> >>>>>>>>>> >>> >>>>>> >>>>>>>>>>> >>> >>>>>> John >>>>>>>>>>> >>> >>>>>> >>>>>>>>>>> >>> >>>>> >>>>>>>>>>> >>> >>>> >>>>>>>>>>> >>> >> >>>>>>>>>>> >>>>>>>>>> >> >> >> >> >> >> >> >> >> >>
