Ah ha, I see it now. We just need a better implementation of ClasspathScanner. Have you looked at https://github.com/ronmamo/reflections by any chance?
John On Fri, Dec 22, 2017 at 5:40 PM Andriy Redko <[email protected]> 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 > >> >> > >> >>> >>>>>> > >> >> > >> >>> >>>>> > >> >> > >> >>> >>>> > >> >> > >> >>> >> > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > > > >
