Aha moment, so there are limitations, that's why I was unsure about that. Regarding deltaspike / microprofile config, we can look it up, if you have some examples / snippets to point out right away, would be great. Thanks.
RMB> Le 23 déc. 2017 16:15, "Andriy Redko" <drr...@gmail.com> a écrit : RMB> I have kind of disagree here, beans.xml has a dedicated section for discovery (<scan>, spec section 12.4. Type and Bean RMB> discovery). I am trying not to (re)invent our own activation / discovery mechanisms but find the right way to deligate that to RMB> the framework in question. Not only CXF would benefit from that, the user's expectations would be met. Not sure this is RMB> possible, but I would be keen to explore this option. RMB> Beans.xml defines it from the jar yes, but from the app you are naked so it is not a solution for libs - yet. RMB> Having to impl an extension to veto the bean is too much in terms of user experience so you have too reinvent the RMB> wheel. Integrating with deltaspike and microprofile config could be a smooth option semi transparent for the user RMB> 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 >>>>>>>>>>> >>> >>>>>> >>>>>>>>>>> >>> >>>>> >>>>>>>>>>> >>> >>>> >>>>>>>>>>> >>> >>
