Le 23 déc. 2017 16:15, "Andriy Redko" <drr...@gmail.com> a écrit :
I have kind of disagree here, beans.xml has a dedicated section for discovery (<scan>, spec section 12.4. Type and Bean discovery). I am trying not to (re)invent our own activation / discovery mechanisms but find the right way to deligate that to the framework in question. Not only CXF would benefit from that, the user's expectations would be met. Not sure this is possible, but I would be keen to explore this option. Beans.xml defines it from the jar yes, but from the app you are naked so it is not a solution for libs - yet. Having to impl an extension to veto the bean is too much in terms of user experience so you have too reinvent the wheel. Integrating with deltaspike and microprofile config could be a smooth option semi transparent for the user and no creating yet another way. Config spi with just String read(String)? RMB> Scanning us unrelated to issue guys. Issue is: how to auto configure activation or not for not app code. A RMB> 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). RMB> Le 23 déc. 2017 00:15, "Andriy Redko" <drr...@gmail.com> a écrit : RMB> That is right, I was not refering to autodiscovery but Spring Boot module we RMB> have. As per my understading, CDI has different means for achieving the desired RMB> 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 >>>>>>>>>> >>> >>>>>> >>>>>>>>>> >>> >>>>> >>>>>>>>>> >>> >>>> >>>>>>>>>> >>> >>
