I'm not sure either, this is the behavior I see in the code: - Register JAX-RS resources (with @ApplicationPath) - Register JAX-RS resources (with @Path) - Register JAX-RS providers (with JAX-RS @Provider) - Register JAX-RS features (with JAX-RS @Feature) - Register CXF features (doesn't care if it has a CXF @Provider annotation but I see the OpenTracing one does have it) - Otherwise we assume its the CXF Bus object
There's not much happening with a CXF @Provider declaration in the extension. But at the end of the day, I'm only 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 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. John 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 > >>>>>> > >>>>> > >>>> > >> >
