Scanning us unrelated to issue guys. Issue is: how to auto configure activation or not for not app code. A cdi-cxf.xml can be an easy way and the cdi extension can pick up the new beans no? Beans.xml doesnt handle the scanning at all (bda vs global config).
Le 23 déc. 2017 00:15, "Andriy Redko" <drr...@gmail.com> a écrit : > 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 <drr...@gmail.com> > 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 <rmannibu...@gmail.com> > >>>> 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" <drr...@gmail.com> 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 < > >>>> drr...@gmail.com> > >>>>>>> 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 < > >>>> sberyoz...@gmail.com> > >>>>>>> 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 < > >>>> sberyoz...@gmail.com> > >>>>>>> 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"< > >>>> johndam...@apache.org> > >>>>>>> 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 < > >>>> sberyoz...@gmail.com> > >>>>>>> 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 > >>>>>>>>> >>> >>>>>> > >>>>>>>>> >>> >>>>> > >>>>>>>>> >>> >>>> > >>>>>>>>> >>> >> > > > > > > > > > > >
