@Sergey, thanks for clarification. @Romain Deltaspike is worth looking I think (as to validate the approach), thanks for pointing it out. The only concern I have about it is the fact it is 100% CDI-only library while for CXF CDI is just one of the options. Anyway, something to learn here.
RMB> Something like deltaspike where it is on by default and deactivable by config is not bad for such modules. Issue RMB> is: what is config? For spring it is obvious but for cdi it must be the 2 mentionned solution and maybe a 3rd fallback with a cxf specific solution - or system props. RMB> An alternate more advanced option can be a cxf-autoload module which would read some classpath file like a spi RMB> where cxf modules could register such feature but would be on only when this module is in the cp. Maybe something RMB> to study but to be honest i believe more in the previous integrations (as a user). RMB> Le 23 déc. 2017 20:29, "Sergey Beryozkin" <[email protected]> a écrit : RMB> Well, was not clear what you meant, the whole conversation was about optionally choosing whether to auto-load a RMB> given provider or not with CDI and you referred to SpringBoot which could do some magic and CXF having the related RMB> module and possibly getting some ideas from there and I thought I'd clarify that there was no magic there in the RMB> Spring-Boot starters/auto-configuration, nothing SpringBoot or Spring specific (well we do refer to Spring to scan RMB> but CDI can scan too) about optionally loading specific providers from the specific packages. RMB> CXF itself ships many providers in different modules and packages and it is hard to see how one can let users RMB> control auto-loading them (which is) without letting users choose at the config time... RMB> Cheers, Sergey RMB> On 22/12/17 23:15, Andriy Redko wrote: 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: RMB> Documenting make sense. To project it to Spring-based runtime, fe, without RMB> Spring-specific annotations + configuration the discovery won't happen ... RMB> But there is Spring Boot which could do magic here, and CXF does have a RMB> module for it. Same, in theory, could be possible with CXF+CDI (let say by RMB> adding `cxf-cdi` module where we could supply the limited, handcrafted RMB> set of CDI beans available for discovery in the beans.xml). Do you think it RMB> is worth exploring the idea? RMB> Best Regards, RMB> 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: RMB> Sure, removed/reverted. So here are the general thoughts. Yes, most (if RMB> not all) of the providers/features/... are not CDI RMB> specific and as such, they are not bean archives (and it make sense). Now, RMB> how could we make the CXF more CDIish? There RMB> are a couple of option we could explore, but what would be the idiomatic RMB> CDI way? RMB> Best Regards, RMB> Andriy Redko JDA>> Personally, I would actually recommend removing the beans.xml from RMB> open tracing (and really any module that isn't JDA>> a cdi specific module). While it does allow for a bit more automatic RMB> binding, my question was more around what is JDA>> missing. I missed the fact that there is no build in automatic RMB> 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 RMB> integration, I can replicate it with other JDA>> providers. Its just a matter of documenting and knowing what to RMB> setup. JDA>> So if you don't mind, I'd like to revert that commit; and add some RMB> docs around how to create an automatically registered provider. JDA>> John JDA>> On 2017-12-22 15:24, Romain Manni-Bucau <[email protected]> RMB> wrote: RMB> How can i disable it now? Tink that cxf feature - even if in separate RMB> modules - shouldnt be auto registered until it has a deactivable flag - RMB> classpath properties + overridable through system prop. RMB> Wdyt? RMB> Le 22 déc. 2017 18:38, "Andriy Redko" <[email protected]> a écrit : RMB> Hi Sergey, RMB> It wasn't (for CDI only), but it could have been always included RMB> manually. RMB> Thanks. RMB> Best Regards, RMB> Andriy Redko SB>> Hi Andriy SB>> So how was a JAX-RS (OpenTracing) Feature discovered without RMB> beans.xml RMB> ? SB>> Cheers, Sergey SB>> On 22/12/17 17:24, Andriy Redko wrote: RMB> The beans.xml was missed indeed, I added it and OpenTracingFeature RMB> has RMB> been discovered right away. RMB> The commit is on its way. Thanks! RMB> Best Regards, RMB> Andriy Redko JDA>> I'm holding off on doing anything to fix it. For one, a user RMB> may RMB> not want to use the global tracer so making it JDA>> so that they register it makes more sense. Ultimately to RMB> solve RMB> it, I think we should be moving server JDA>> customizations outside of CDI to ensure that it can be auto RMB> registered. JDA>> John JDA>> On Fri, Dec 22, 2017 at 11:12 AM Andriy Redko < RMB> wrote: JDA>> Hey John, JDA>> The OpenTracingFeature RMB> (org.apache.cxf.tracing.opentracing.jaxrs RMB> package) is JAX-RS feature, JDA>> which JAXRS CDI extension should recognize out of the box. RMB> There RMB> is also CXF feature ( JDA>> in org.apache.cxf.tracing.opentracing package) to be used for RMB> JAX-WS services. The only explanation JDA>> I have why it is not being picked up it the absense of RMB> bean.xml RMB> so we could fix that. I will JDA>> take a look shorly (if you haven't figured this one out RMB> already). RMB> Thanks. JDA>> Best Regards, JDA>> Andriy Redko RMB> JDA>> I'm not sure either, this is the behavior I see in the RMB> code: RMB> JDA>> - Register JAX-RS resources (with @ApplicationPath) RMB> JDA>> - Register JAX-RS resources (with @Path) RMB> JDA>> - Register JAX-RS providers (with JAX-RS @Provider) RMB> JDA>> - Register JAX-RS features (with JAX-RS @Feature) RMB> JDA>> - Register CXF features (doesn't care if it has a CXF RMB> @Provider RMB> annotation but I see the OpenTracing one does have it) RMB> JDA>> - Otherwise we assume its the CXF Bus object RMB> JDA>> There's not much happening with a CXF @Provider RMB> declaration in RMB> the extension. But at the end of the day, I'm only RMB> JDA>> dealing with a JAX-RS @Provider and that doesn't get RMB> registered RMB> since it's not a CDI bean. I don't see any issue RMB> JDA>> registering CXF @Provider this way as well, but its RMB> possible RMB> it's not a CDI bean still, but that's ultimately what the customizer RMB> was RMB> put in for. RMB> JDA>> John RMB> JDA>> On 2017-12-22 09:56, Sergey Beryozkin < RMB> [email protected]> RMB> wrote: RMB> >>> Sure, I just don't understand what is the difference between RMB> a RMB> JAX-RS RMB> >>> feature and CXF feature, as far as the CXF CDI code is RMB> concerned. RMB> If it RMB> >>> can load the JAX-RS features which have not been written RMB> with CDI RMB> in RMB> >>> mind, why can't it load CXF features without some extra work RMB> going into RMB> >>> these features... RMB> >>> Thanks, Sergey RMB> >>> On 22/12/17 14:50, John D. Ament wrote: RMB> >>> > That's not really the issue though. The extension will RMB> only RMB> receive CDI managed beans. Take a look at my pull to see what I had RMB> to do RMB> to get it to register automatically. If nothing else, this is an RMB> argument RMB> for moving JAXRSServer Customization into core and using service RMB> loader RMB> :-) Perhaps after the new year. RMB> >>> > RMB> >>> > On 2017-12-22 09:23, Sergey Beryozkin < RMB> [email protected]> RMB> wrote: RMB> >>> >> I was not referring the OpenTracing module offering a CDI RMB> extension, but RMB> >>> >> to the work Andriy did in the CXF CDI integration where RMB> the RMB> providers RMB> >>> >> and feature are picked up. Thought, when we were RMB> discussing RMB> the SSE RMB> >>> >> feature I thought Andriy said it was looking at the CXF RMB> @Provider as RMB> >>> >> well, may be I misunderstood. RMB> >>> >> Updating the CDI code to check CXF @Provider, if it is not RMB> already RMB> >>> >> checked, makes sense IMHO RMB> >>> >> RMB> >>> >> Sergey RMB> >>> >> On 22/12/17 14:08, John D. Ament wrote: RMB> >>> >>> Actually one more thing. The CDI extension only looks RMB> for RMB> JAX-RS @Provider not CXF @Provider. RMB> >>> >>> RMB> >>> >>> On 2017-12-22 09:06, "John D. Ament"< RMB> [email protected]> RMB> wrote: RMB> >>> >>>> I'm not sure what the CDI extension has to do with RMB> this. It RMB> has no bean defining annotations, and there is no beans.xml in the RMB> JAR that RMB> it ships with so I'm not sure it would be picked up by the extension. RMB> >>> >>>> RMB> >>> >>>> There's nothing special done for TomcatwarTest to make RMB> more RMB> JARs available, right? RMB> >>> >>>> RMB> >>> >>>> On 2017-12-22 08:15, Sergey Beryozkin < RMB> [email protected]> RMB> wrote: RMB> >>> >>>>> It is annotated with CXF @Provider annotation - should RMB> be RMB> picked up by RMB> >>> >>>>> the CXF CDI extension RMB> >>> >>>>> RMB> >>> >>>>> Sergey RMB> >>> >>>>> On 22/12/17 13:07, John D. Ament wrote: RMB> >>> >>>>>> I'm trying to finish up testing CDI injection of RMB> Context RMB> objects. The one RMB> >>> >>>>>> area I'm struggling with is the automatic RMB> registration of RMB> this feature. I RMB> >>> >>>>>> added a dependency on OpenTracing, just to confirm RMB> that RMB> injection via CDI RMB> >>> >>>>>> works (and to be honest, this is one of my use cases, RMB> working with RMB> >>> >>>>>> tracing). However, it seems that this feature isn't RMB> automatically RMB> >>> >>>>>> registered via CDI. Is there something I have to do RMB> to RMB> make it work? RMB> >>> >>>>>> RMB> >>> >>>>>> John RMB> >>> >>>>>> RMB> >>> >>>>> RMB> >>> >>>> RMB> >>> >>
