The beans.xml (application side) is the way to disable it (aka veto). But as John recommended, I removed it. It would be good to come up with a standard, CDI friendly, way to make components discoverable.
RMB> How can i disable it now? Tink that cxf feature - even if in separate modules - shouldnt be auto registered until RMB> it has a deactivable flag - classpath properties + overridable through system prop. RMB> Wdyt? RMB> Le 22 déc. 2017 18:38, "Andriy Redko" <drr...@gmail.com> a écrit : RMB> Hi Sergey, RMB> It wasn't (for CDI only), but it could have been always included manually. RMB> Thanks. RMB> Best Regards, RMB> 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 >>> >>> >>>>>> >>> >>> >>>>> >>> >>> >>>> >>> >>> >>
