Re: How to automatically register OpenTracingFeature?

Thinking out loud: did we check we can use @CxfXXX on application class? Do we respect it for properties? Le 24 déc. 2017 22:22, "Andriy Redko" a écrit : > Oh you mean, the configuration implementation. Sure, I think if the > general approach make sense, starting > from cxf

Re: How to automatically register OpenTracingFeature?

Le 24 déc. 2017 21:40, "Andriy Redko" a écrit : No API sounds good. Just to clarify the second part. "By reflection" you mean just go with classpath scan? No, CXF must never scan anything, it is already done and would defeat any integration and user experience to redo it.

Re: How to automatically register OpenTracingFeature?

No API sounds good. Just to clarify the second part. "By reflection" you mean just go with classpath scan? RMB> No hard dep on any api would be nice but a chain can work even if by reflection no? Kind of test them all. Then RMB> put the active ones in the server map to be able to reuse it

Re: How to automatically register OpenTracingFeature?

No hard dep on any api would be nice but a chain can work even if by reflection no? Kind of test them all. Then put the active ones in the server map to be able to reuse it later no? Le 24 déc. 2017 19:07, "Andriy Redko" a écrit : > Hey guys, > > So I have been looking around

Re: How to automatically register OpenTracingFeature?

@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.

Re: How to automatically register OpenTracingFeature?

Something like deltaspike where it is on by default and deactivable by config is not bad for such modules. Issue 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. An alternate more

Re: How to automatically register OpenTracingFeature?

Well, was not clear what you meant, the whole conversation was about optionally choosing whether to auto-load a given provider or not with CDI and you referred to SpringBoot which could do some magic and CXF having the related module and possibly getting some ideas from there and I thought I'd

Re: How to automatically register OpenTracingFeature?

Le 23 déc. 2017 18:15, "Andriy Redko" a écrit : 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. Can

Re: How to automatically register OpenTracingFeature?

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" a écrit

Re: How to automatically register OpenTracingFeature?

Le 23 déc. 2017 16:15, "Andriy Redko" a écrit : I have kind of disagree here, beans.xml has a dedicated section for discovery (, 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

Re: How to automatically register OpenTracingFeature?

I have kind of disagree here, beans.xml has a dedicated section for discovery (, 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

Re: How to automatically register OpenTracingFeature?

Scanning us unrelated to issue guys. Issue is: how to auto configure activation or not for not app code. A 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). Le 23 déc. 2017 00:15, "Andriy Redko"

Re: How to automatically register OpenTracingFeature?

That is right, I was not refering to autodiscovery but Spring Boot module we have. As per my understading, CDI has different means for achieving the desired 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>

Re: How to automatically register OpenTracingFeature?

Yeah, I know this project, but I think this is would be too much. All DI frameworks already do classpath scanning, in some form or another. I think we should just play by CDI rules :), as we do with Spring + Spring Boot integration by following the conventions. Best Regards, Andriy Redko

Re: How to automatically register OpenTracingFeature?

Ah ha, I see it now. We just need a better implementation of ClasspathScanner. Have you looked at https://github.com/ronmamo/reflections by any chance? John On Fri, Dec 22, 2017 at 5:40 PM Andriy Redko wrote: > Documenting make sense. To project it to Spring-based runtime,

Re: How to automatically register OpenTracingFeature?

CXF SpringBoot module does not do any auto-discovery. The code is in the rt/frontend/jaxrs/.../spring which can be loaded by the spring boot module, and it does what I said in the prev email, scans for the classes annotated as providers in the user-requested packages... Cheers, Sergey On

Re: How to automatically register OpenTracingFeature?

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

Re: How to automatically register OpenTracingFeature?

In the spring boot demo the class-scanning is enabled first and then the packages to scan are checked, having the module on the classpath does not auto-load - so I reckon the CXF CDI code should follow the same pattern. The users will only need to set the properties in order to get some

Re: How to automatically register OpenTracingFeature?

I would do nothing but document a strategy that users can implement. The biggest question I have is whether a provider like this should be registered automatically? Does that happen with spring based runtimes? What about when there is no DI framework present? Is it clear enough that user would

Re: How to automatically register OpenTracingFeature?

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 -

Re: How to automatically register OpenTracingFeature?

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

Re: How to automatically register OpenTracingFeature?

Personally, I would actually recommend removing the beans.xml from open tracing (and really any module that isn't a cdi specific module). While it does allow for a bit more automatic binding, my question was more around what is missing. I missed the fact that there is no build in automatic

Re: How to automatically register OpenTracingFeature?

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" a écrit : > Hi Sergey, > > It

Re: How to automatically register OpenTracingFeature?

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

Re: How to automatically register OpenTracingFeature?

Hi Andriy So how was a JAX-RS (OpenTracing) Feature discovered without beans.xml ? Cheers, Sergey 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,

Re: How to automatically register OpenTracingFeature?

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

Re: How to automatically register OpenTracingFeature?

I am not sure since there is the application-specific configuration (like f.e. which tracer(s) to use). So the problem is not really specific to CDI, in any case there are easy solutions (f.e. providing application class, subclassing the feature, etc). The service loader approach may also work

Re: How to automatically register OpenTracingFeature?

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 so that they register it makes more sense. Ultimately to solve it, I think we should be moving server customizations outside of CDI to ensure that it can be auto registered. John On

Re: How to automatically register OpenTracingFeature?

Hey John, The OpenTracingFeature (org.apache.cxf.tracing.opentracing.jaxrs package) is JAX-RS feature, which JAXRS CDI extension should recognize out of the box. There is also CXF feature ( in org.apache.cxf.tracing.opentracing package) to be used for JAX-WS services. The only explanation I

Re: How to automatically register OpenTracingFeature?

Custom empty application class but provider subclass to force the registration Le 22 déc. 2017 15:08, "John D. Ament" a écrit : > What does your Application class look like, or are you using no > application class? > > On 2017-12-22 08:35, Romain Manni-Bucau

Re: How to automatically register OpenTracingFeature?

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

Re: How to automatically register OpenTracingFeature?

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

Re: How to automatically register OpenTracingFeature?

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

Re: How to automatically register OpenTracingFeature?

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

Re: How to automatically register OpenTracingFeature?

What does your Application class look like, or are you using no application class? On 2017-12-22 08:35, Romain Manni-Bucau wrote: > In meecrowave im using it and it works while the jar name is not excluded > of the scanning > > Le 22 déc. 2017 14:16, "Sergey Beryozkin"

Re: How to automatically register OpenTracingFeature?

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" 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

Re: How to automatically register OpenTracingFeature?

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

Re: How to automatically register OpenTracingFeature?

In meecrowave im using it and it works while the jar name is not excluded of the scanning Le 22 déc. 2017 14:16, "Sergey Beryozkin" a écrit : > It is annotated with CXF @Provider annotation - should be picked up by the > CXF CDI extension > > Sergey > On 22/12/17 13:07,

Re: How to automatically register OpenTracingFeature?

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

How to automatically register OpenTracingFeature?

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