You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by "John D. Ament" <jo...@apache.org> on 2017/12/22 13:07:39 UTC
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
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
Re: How to automatically register OpenTracingFeature?
Posted by Andriy Redko <dr...@gmail.com>.
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 (and is supported for providers fe). Anyway, I will take a look
while it is not discovered by CDI extension right now. 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 <dr...@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 <sb...@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 <sb...@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"<jo...@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 <sb...@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
>>> >>>>>>
>>> >>>>>
>>> >>>>
>>> >>
Re: How to automatically register OpenTracingFeature?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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" <dr...@gmail.com> a écrit :
> Oh you mean, the configuration implementation. Sure, I think if the
> general approach make sense, starting
> from cxf properties would be as simple as it can get. We just need to plug
> it with CDI extension part.
>
>
> RMB> Le 24 déc. 2017 21:40, "Andriy Redko" <dr...@gmail.com> a écrit :
>
> RMB> No API sounds good. Just to clarify the second part. "By reflection"
> you mean just go with classpath scan?
>
>
>
>
> RMB> No, CXF must never scan anything, it is already done and would defeat
> any integration and user experience to redo
> RMB> it. Just meant test deltaspike, if no value test microprofile, if no
> value cxf properties and last system
> RMB> properties. The first two needs to be done by reflection to avoid to
> enforce them as dependency. A spi can be
> RMB> tested as well first but not having to impl it would be a big plus
> and is easy technically, no?
>
>
>
> 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 later
> no?
>
> RMB>> Le 24 déc. 2017 19:07, "Andriy Redko" <dr...@gmail.com> a écrit :
>
> RMB>> Hey guys,
>
> RMB>> So I have been looking around to understand how the activation
> around CDI is worked out by others,
> RMB>> including ConfigResolver and Jersey. Here is what I have
> discovered so far.
>
> RMB>> #1. Deltaspike. Uses own ConfigResolver approach: among other
> things, allows to deactivate beans / extensions
> RMB>> using a list of config sources. Because Deltaspike is pure CDI,
> all extensions are automatically discovered but
> RMB>> could be deactivated by means of ConfigResolver. In case of CXF,
> we could take a similar approach by activating
> RMB>> the necessary beans (as most of our components are non-beans
> archives and as such, won't be discovered by CDI),
> RMB>> f.e.:
>
> RMB>> <full.class.name>.active = true
> RMB>> <full.class.name>.active = true
> RMB>> <full.class.name>.active = true
>
> RMB>> Once the JAXRS extension is picked up by CDI runtime, it would add
> annotated types during the discovery phase for
> RMB>> activated providers / features. In the future, this could be done
> using beans.xml (https://issues.jboss.org/browse/CDI-526),
> RMB>> hopefully, but as Romain pointed out, it is problematic at the
> moment.
>
> RMB>> We could make it per-module (so each component would provide such
> configuration) or bundle as a single module
> RMB>> (f.e. cxf-cdi-discovery, or cxf-cdi-beans, ...). Surely, each
> application would be able to override any of the
> RMB>> activations and/or provide its own if necessary.
>
> RMB>> #2. Jersey. Uses own mechanism to autodiscover and register
> features and providers. Essentially, in a simplified form, it could
> RMB>> be summarized like this. Each module (component) provides binding
> (in a form contract -> class -> scope) which it thinks should be
> RMB>> autodiscovered by the runtime (in this case, CDI). The bindings
> are brought into context using service loader. In this case, every
> RMB>> component has a compile-time dependency on CDI API.
>
> RMB>> No doubts, there are more options available. Picking between the
> ones above, could/should we implement #1? If yes, should we build it
> RMB>> on top of Microprofile Config API (https://github.com/eclipse/
> microprofile-config)? Or just keep it as simple as
> RMB>> possible (around new/use existing property file)? What do you
> think guys?
>
>
> RMB>> Thanks.
>
> RMB>> Best Regards,
> RMB>> Andriy Redko
>
> 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" <sb...@gmail.com>
> 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.
>
> RMB> SB>>> CXF SpringBoot module does not do any auto-discovery. The
> code is in the
> RMB> SB>>> rt/frontend/jaxrs/.../spring which can be loaded by the
> spring boot
> RMB> SB>>> module, and it does what I said in the prev email, scans for
> the classes
> RMB> SB>>> annotated as providers in the user-requested packages...
>
> RMB> SB>>> Cheers, Sergey
> RMB> 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
>
>
>
>
> RMB> JDA>>> I would do nothing but document a strategy that users can
> implement. The
> RMB> JDA>>> biggest question I have is whether a provider like this
> should be
> RMB> JDA>>> registered automatically? Does that happen with spring
> based runtimes?
> RMB> JDA>>> What about when there is no DI framework present? Is it
> clear enough that
> RMB> JDA>>> user would need to list it in their Application class as a
> singleton/class?
>
>
>
>
> RMB> JDA>>> John
>
>
>
>
> RMB> JDA>>> On Fri, Dec 22, 2017 at 5:08 PM Andriy Redko <
> drreta@gmail.com> 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
>
>
>
>
>
>
> RMB> JDA>>> Personally, I would actually recommend removing the
> beans.xml from
> RMB>>> open tracing (and really any module that isn't
> RMB> JDA>>> a cdi specific module). While it does allow for a bit more
> automatic
> RMB>>> binding, my question was more around what is
> RMB> JDA>>> missing. I missed the fact that there is no build in
> automatic
> RMB>>> discovery of providers in CDI if they're not CDI
> RMB> JDA>>> managed - which is OK and the answer I was working through.
>
>
>
>
>
>
> RMB> JDA>>> And realistically, this issue is not specific to the open
> tracing
> RMB>>> integration, I can replicate it with other
> RMB> JDA>>> providers. Its just a matter of documenting and knowing
> what to
> RMB>>> setup.
>
>
>
>
>
>
> RMB> 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.
>
>
>
>
>
>
> RMB> JDA>>> John
>
>
>
>
>
>
> RMB> JDA>>> On 2017-12-22 15:24, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> 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" <dr...@gmail.com> 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
>
>
>
>
>
>
>
>
>
> RMB> SB>>> Hi Andriy
>
>
>
>
>
>
>
>
>
> RMB> SB>>> So how was a JAX-RS (OpenTracing) Feature discovered without
>
>
>
> RMB>>> beans.xml
>
> RMB>>> ?
>
>
>
>
>
>
>
>
>
> RMB> SB>>> Cheers, Sergey
> RMB> 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
>
>
>
>
>
>
>
>
>
>
>
> RMB> 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
>
> RMB> JDA>>> so that they register it makes more sense. Ultimately to
>
>
>
>
>
> RMB>>> solve
>
> RMB>>> it, I think we should be moving server
>
> RMB> JDA>>> customizations outside of CDI to ensure that it can be auto
>
>
> RMB>>> registered.
>
>
>
>
>
>
>
>
>
>
> RMB> JDA>>> John
>
>
>
>
>
>
>
>
>
>
>
>
> RMB> JDA>>> On Fri, Dec 22, 2017 at 11:12 AM Andriy Redko <
>
>
>
>
>
>
>
> RMB>>> wrote:
>
>
>
>
>
>
>
>
>
> RMB> JDA>>> Hey John,
>
>
>
>
>
>
>
>
>
>
>
> RMB> JDA>>> The OpenTracingFeature
>
>
>
>
>
> RMB>>> (org.apache.cxf.tracing.opentracing.jaxrs
>
> RMB>>> package) is JAX-RS feature,
>
> RMB> JDA>>> which JAXRS CDI extension should recognize out of the box.
>
>
>
>
>
> RMB>>> There
>
> RMB>>> is also CXF feature (
>
> RMB> JDA>>> in org.apache.cxf.tracing.opentracing package) to be used
> for
>
>
> RMB>>> JAX-WS services. The only explanation
>
> RMB> 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
>
> RMB> JDA>>> take a look shorly (if you haven't figured this one out
>
>
>
>
>
> RMB>>> already).
>
> RMB>>> Thanks.
>
>
>
>
>
>
>
>
>
> RMB> JDA>>> Best Regards,
> RMB> 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>>> sberyozkin@gmail.com>
>
> 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>>> sberyozkin@gmail.com>
>
> 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>>> johndament@apache.org>
>
> 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>>> sberyozkin@gmail.com>
>
> 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>>> >>> >>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
Re: How to automatically register OpenTracingFeature?
Posted by Andriy Redko <dr...@gmail.com>.
Oh you mean, the configuration implementation. Sure, I think if the general approach make sense, starting
from cxf properties would be as simple as it can get. We just need to plug it with CDI extension part.
RMB> Le 24 déc. 2017 21:40, "Andriy Redko" <dr...@gmail.com> a écrit :
RMB> No API sounds good. Just to clarify the second part. "By reflection" you mean just go with classpath scan?
RMB> No, CXF must never scan anything, it is already done and would defeat any integration and user experience to redo
RMB> it. Just meant test deltaspike, if no value test microprofile, if no value cxf properties and last system
RMB> properties. The first two needs to be done by reflection to avoid to enforce them as dependency. A spi can be
RMB> tested as well first but not having to impl it would be a big plus and is easy technically, no?
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 later no?
RMB>> Le 24 déc. 2017 19:07, "Andriy Redko" <dr...@gmail.com> a écrit :
RMB>> Hey guys,
RMB>> So I have been looking around to understand how the activation around CDI is worked out by others,
RMB>> including ConfigResolver and Jersey. Here is what I have discovered so far.
RMB>> #1. Deltaspike. Uses own ConfigResolver approach: among other things, allows to deactivate beans / extensions
RMB>> using a list of config sources. Because Deltaspike is pure CDI, all extensions are automatically discovered but
RMB>> could be deactivated by means of ConfigResolver. In case of CXF, we could take a similar approach by activating
RMB>> the necessary beans (as most of our components are non-beans archives and as such, won't be discovered by CDI),
RMB>> f.e.:
RMB>> <full.class.name>.active = true
RMB>> <full.class.name>.active = true
RMB>> <full.class.name>.active = true
RMB>> Once the JAXRS extension is picked up by CDI runtime, it would add annotated types during the discovery phase for
RMB>> activated providers / features. In the future, this could be done using beans.xml (https://issues.jboss.org/browse/CDI-526),
RMB>> hopefully, but as Romain pointed out, it is problematic at the moment.
RMB>> We could make it per-module (so each component would provide such configuration) or bundle as a single module
RMB>> (f.e. cxf-cdi-discovery, or cxf-cdi-beans, ...). Surely, each application would be able to override any of the
RMB>> activations and/or provide its own if necessary.
RMB>> #2. Jersey. Uses own mechanism to autodiscover and register features and providers. Essentially, in a simplified form, it could
RMB>> be summarized like this. Each module (component) provides binding (in a form contract -> class -> scope) which it thinks should be
RMB>> autodiscovered by the runtime (in this case, CDI). The bindings are brought into context using service loader. In this case, every
RMB>> component has a compile-time dependency on CDI API.
RMB>> No doubts, there are more options available. Picking between the ones above, could/should we implement #1? If yes, should we build it
RMB>> on top of Microprofile Config API (https://github.com/eclipse/microprofile-config)? Or just keep it as simple as
RMB>> possible (around new/use existing property file)? What do you think guys?
RMB>> Thanks.
RMB>> Best Regards,
RMB>> Andriy Redko
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" <sb...@gmail.com> 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.
RMB> SB>>> CXF SpringBoot module does not do any auto-discovery. The code is in the
RMB> SB>>> rt/frontend/jaxrs/.../spring which can be loaded by the spring boot
RMB> SB>>> module, and it does what I said in the prev email, scans for the classes
RMB> SB>>> annotated as providers in the user-requested packages...
RMB> SB>>> Cheers, Sergey
RMB> 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
RMB> JDA>>> I would do nothing but document a strategy that users can implement. The
RMB> JDA>>> biggest question I have is whether a provider like this should be
RMB> JDA>>> registered automatically? Does that happen with spring based runtimes?
RMB> JDA>>> What about when there is no DI framework present? Is it clear enough that
RMB> JDA>>> user would need to list it in their Application class as a singleton/class?
RMB> JDA>>> John
RMB> JDA>>> On Fri, Dec 22, 2017 at 5:08 PM Andriy Redko <dr...@gmail.com> 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
RMB> JDA>>> Personally, I would actually recommend removing the beans.xml from
RMB>>> open tracing (and really any module that isn't
RMB> JDA>>> a cdi specific module). While it does allow for a bit more automatic
RMB>>> binding, my question was more around what is
RMB> JDA>>> missing. I missed the fact that there is no build in automatic
RMB>>> discovery of providers in CDI if they're not CDI
RMB> JDA>>> managed - which is OK and the answer I was working through.
RMB> JDA>>> And realistically, this issue is not specific to the open tracing
RMB>>> integration, I can replicate it with other
RMB> JDA>>> providers. Its just a matter of documenting and knowing what to
RMB>>> setup.
RMB> 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.
RMB> JDA>>> John
RMB> JDA>>> On 2017-12-22 15:24, Romain Manni-Bucau <rm...@gmail.com>
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" <dr...@gmail.com> 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
RMB> SB>>> Hi Andriy
RMB> SB>>> So how was a JAX-RS (OpenTracing) Feature discovered without
RMB>>> beans.xml
RMB>>> ?
RMB> SB>>> Cheers, Sergey
RMB> 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
RMB> 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
RMB> JDA>>> so that they register it makes more sense. Ultimately to
RMB>>> solve
RMB>>> it, I think we should be moving server
RMB> JDA>>> customizations outside of CDI to ensure that it can be auto
RMB>>> registered.
RMB> JDA>>> John
RMB> JDA>>> On Fri, Dec 22, 2017 at 11:12 AM Andriy Redko <
RMB>>> wrote:
RMB> JDA>>> Hey John,
RMB> JDA>>> The OpenTracingFeature
RMB>>> (org.apache.cxf.tracing.opentracing.jaxrs
RMB>>> package) is JAX-RS feature,
RMB> JDA>>> which JAXRS CDI extension should recognize out of the box.
RMB>>> There
RMB>>> is also CXF feature (
RMB> JDA>>> in org.apache.cxf.tracing.opentracing package) to be used for
RMB>>> JAX-WS services. The only explanation
RMB> 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
RMB> JDA>>> take a look shorly (if you haven't figured this one out
RMB>>> already).
RMB>>> Thanks.
RMB> JDA>>> Best Regards,
RMB> 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>>> sberyozkin@gmail.com>
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>>> sberyozkin@gmail.com>
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>>> johndament@apache.org>
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>>> sberyozkin@gmail.com>
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>>> >>> >>
Re: How to automatically register OpenTracingFeature?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le 24 déc. 2017 21:40, "Andriy Redko" <dr...@gmail.com> 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. Just meant test deltaspike, if
no value test microprofile, if no value cxf properties and last system
properties. The first two needs to be done by reflection to avoid to
enforce them as dependency. A spi can be tested as well first but not
having to impl it would be a big plus and is easy technically, no?
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 later no?
RMB> Le 24 déc. 2017 19:07, "Andriy Redko" <dr...@gmail.com> a écrit :
RMB> Hey guys,
RMB> So I have been looking around to understand how the activation around
CDI is worked out by others,
RMB> including ConfigResolver and Jersey. Here is what I have discovered
so far.
RMB> #1. Deltaspike. Uses own ConfigResolver approach: among other things,
allows to deactivate beans / extensions
RMB> using a list of config sources. Because Deltaspike is pure CDI, all
extensions are automatically discovered but
RMB> could be deactivated by means of ConfigResolver. In case of CXF, we
could take a similar approach by activating
RMB> the necessary beans (as most of our components are non-beans archives
and as such, won't be discovered by CDI),
RMB> f.e.:
RMB> <full.class.name>.active = true
RMB> <full.class.name>.active = true
RMB> <full.class.name>.active = true
RMB> Once the JAXRS extension is picked up by CDI runtime, it would add
annotated types during the discovery phase for
RMB> activated providers / features. In the future, this could be done
using beans.xml (https://issues.jboss.org/browse/CDI-526),
RMB> hopefully, but as Romain pointed out, it is problematic at the moment.
RMB> We could make it per-module (so each component would provide such
configuration) or bundle as a single module
RMB> (f.e. cxf-cdi-discovery, or cxf-cdi-beans, ...). Surely, each
application would be able to override any of the
RMB> activations and/or provide its own if necessary.
RMB> #2. Jersey. Uses own mechanism to autodiscover and register features
and providers. Essentially, in a simplified form, it could
RMB> be summarized like this. Each module (component) provides binding (in
a form contract -> class -> scope) which it thinks should be
RMB> autodiscovered by the runtime (in this case, CDI). The bindings are
brought into context using service loader. In this case, every
RMB> component has a compile-time dependency on CDI API.
RMB> No doubts, there are more options available. Picking between the ones
above, could/should we implement #1? If yes, should we build it
RMB> on top of Microprofile Config API (https://github.com/eclipse/
microprofile-config)? Or just keep it as simple as
RMB> possible (around new/use existing property file)? What do you think
guys?
RMB> Thanks.
RMB> Best Regards,
RMB> Andriy Redko
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" <sb...@gmail.com> 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 <dr...@gmail.com>
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 <rm...@gmail.com>
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" <dr...@gmail.com> 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>> sberyozkin@gmail.com>
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>> sberyozkin@gmail.com>
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>> johndament@apache.org>
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>> sberyozkin@gmail.com>
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>> >>> >>
Re: How to automatically register OpenTracingFeature?
Posted by Andriy Redko <dr...@gmail.com>.
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 later no?
RMB> Le 24 déc. 2017 19:07, "Andriy Redko" <dr...@gmail.com> a écrit :
RMB> Hey guys,
RMB> So I have been looking around to understand how the activation around CDI is worked out by others,
RMB> including ConfigResolver and Jersey. Here is what I have discovered so far.
RMB> #1. Deltaspike. Uses own ConfigResolver approach: among other things, allows to deactivate beans / extensions
RMB> using a list of config sources. Because Deltaspike is pure CDI, all extensions are automatically discovered but
RMB> could be deactivated by means of ConfigResolver. In case of CXF, we could take a similar approach by activating
RMB> the necessary beans (as most of our components are non-beans archives and as such, won't be discovered by CDI),
RMB> f.e.:
RMB> <full.class.name>.active = true
RMB> <full.class.name>.active = true
RMB> <full.class.name>.active = true
RMB> Once the JAXRS extension is picked up by CDI runtime, it would add annotated types during the discovery phase for
RMB> activated providers / features. In the future, this could be done using beans.xml (https://issues.jboss.org/browse/CDI-526),
RMB> hopefully, but as Romain pointed out, it is problematic at the moment.
RMB> We could make it per-module (so each component would provide such configuration) or bundle as a single module
RMB> (f.e. cxf-cdi-discovery, or cxf-cdi-beans, ...). Surely, each application would be able to override any of the
RMB> activations and/or provide its own if necessary.
RMB> #2. Jersey. Uses own mechanism to autodiscover and register features and providers. Essentially, in a simplified form, it could
RMB> be summarized like this. Each module (component) provides binding (in a form contract -> class -> scope) which it thinks should be
RMB> autodiscovered by the runtime (in this case, CDI). The bindings are brought into context using service loader. In this case, every
RMB> component has a compile-time dependency on CDI API.
RMB> No doubts, there are more options available. Picking between the ones above, could/should we implement #1? If yes, should we build it
RMB> on top of Microprofile Config API (https://github.com/eclipse/microprofile-config)? Or just keep it as simple as
RMB> possible (around new/use existing property file)? What do you think guys?
RMB> Thanks.
RMB> Best Regards,
RMB> Andriy Redko
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" <sb...@gmail.com> 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 <dr...@gmail.com> 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 <rm...@gmail.com>
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" <dr...@gmail.com> 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>> sberyozkin@gmail.com>
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>> sberyozkin@gmail.com>
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>> johndament@apache.org>
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>> sberyozkin@gmail.com>
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>> >>> >>
Re: How to automatically register OpenTracingFeature?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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" <dr...@gmail.com> a écrit :
> Hey guys,
>
> So I have been looking around to understand how the activation around CDI
> is worked out by others,
> including ConfigResolver and Jersey. Here is what I have discovered so far.
>
> #1. Deltaspike. Uses own ConfigResolver approach: among other things,
> allows to deactivate beans / extensions
> using a list of config sources. Because Deltaspike is pure CDI, all
> extensions are automatically discovered but
> could be deactivated by means of ConfigResolver. In case of CXF, we could
> take a similar approach by activating
> the necessary beans (as most of our components are non-beans archives and
> as such, won't be discovered by CDI),
> f.e.:
>
> <full.class.name>.active = true
> <full.class.name>.active = true
> <full.class.name>.active = true
>
> Once the JAXRS extension is picked up by CDI runtime, it would add
> annotated types during the discovery phase for
> activated providers / features. In the future, this could be done using
> beans.xml (https://issues.jboss.org/browse/CDI-526),
> hopefully, but as Romain pointed out, it is problematic at the moment.
>
> We could make it per-module (so each component would provide such
> configuration) or bundle as a single module
> (f.e. cxf-cdi-discovery, or cxf-cdi-beans, ...). Surely, each application
> would be able to override any of the
> activations and/or provide its own if necessary.
>
> #2. Jersey. Uses own mechanism to autodiscover and register features and
> providers. Essentially, in a simplified form, it could
> be summarized like this. Each module (component) provides binding (in a
> form contract -> class -> scope) which it thinks should be
> autodiscovered by the runtime (in this case, CDI). The bindings are
> brought into context using service loader. In this case, every
> component has a compile-time dependency on CDI API.
>
> No doubts, there are more options available. Picking between the ones
> above, could/should we implement #1? If yes, should we build it
> on top of Microprofile Config API (https://github.com/eclipse/
> microprofile-config)? Or just keep it as simple as
> possible (around new/use existing property file)? What do you think guys?
>
> Thanks.
>
> Best Regards,
> Andriy Redko
>
> 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" <sb...@gmail.com> 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 <dr...@gmail.com>
> 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 <rm...@gmail.com>
> 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" <dr...@gmail.com> 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> sberyozkin@gmail.com>
>
> 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> sberyozkin@gmail.com>
>
> 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> johndament@apache.org>
>
> 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> sberyozkin@gmail.com>
>
> 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> >>> >>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
Re: How to automatically register OpenTracingFeature?
Posted by Andriy Redko <dr...@gmail.com>.
Hey guys,
So I have been looking around to understand how the activation around CDI is worked out by others,
including ConfigResolver and Jersey. Here is what I have discovered so far.
#1. Deltaspike. Uses own ConfigResolver approach: among other things, allows to deactivate beans / extensions
using a list of config sources. Because Deltaspike is pure CDI, all extensions are automatically discovered but
could be deactivated by means of ConfigResolver. In case of CXF, we could take a similar approach by activating
the necessary beans (as most of our components are non-beans archives and as such, won't be discovered by CDI),
f.e.:
<full.class.name>.active = true
<full.class.name>.active = true
<full.class.name>.active = true
Once the JAXRS extension is picked up by CDI runtime, it would add annotated types during the discovery phase for
activated providers / features. In the future, this could be done using beans.xml (https://issues.jboss.org/browse/CDI-526),
hopefully, but as Romain pointed out, it is problematic at the moment.
We could make it per-module (so each component would provide such configuration) or bundle as a single module
(f.e. cxf-cdi-discovery, or cxf-cdi-beans, ...). Surely, each application would be able to override any of the
activations and/or provide its own if necessary.
#2. Jersey. Uses own mechanism to autodiscover and register features and providers. Essentially, in a simplified form, it could
be summarized like this. Each module (component) provides binding (in a form contract -> class -> scope) which it thinks should be
autodiscovered by the runtime (in this case, CDI). The bindings are brought into context using service loader. In this case, every
component has a compile-time dependency on CDI API.
No doubts, there are more options available. Picking between the ones above, could/should we implement #1? If yes, should we build it
on top of Microprofile Config API (https://github.com/eclipse/microprofile-config)? Or just keep it as simple as
possible (around new/use existing property file)? What do you think guys?
Thanks.
Best Regards,
Andriy Redko
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" <sb...@gmail.com> 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 <dr...@gmail.com> 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 <rm...@gmail.com>
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" <dr...@gmail.com> 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> sberyozkin@gmail.com>
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> sberyozkin@gmail.com>
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> johndament@apache.org>
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> sberyozkin@gmail.com>
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> >>> >>
Re: How to automatically register OpenTracingFeature?
Posted by Andriy Redko <dr...@gmail.com>.
@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" <sb...@gmail.com> 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 <dr...@gmail.com> 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 <rm...@gmail.com>
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" <dr...@gmail.com> 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> sberyozkin@gmail.com>
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> sberyozkin@gmail.com>
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> johndament@apache.org>
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> sberyozkin@gmail.com>
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> >>> >>
Re: How to automatically register OpenTracingFeature?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 advanced option can be a cxf-autoload module which would
read some classpath file like a spi where cxf modules could register such
feature but would be on only when this module is in the cp. Maybe something
to study but to be honest i believe more in the previous integrations (as a
user).
Le 23 déc. 2017 20:29, "Sergey Beryozkin" <sb...@gmail.com> a écrit :
> 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
> clarify that there was no magic there in the Spring-Boot
> starters/auto-configuration, nothing SpringBoot or Spring specific (well we
> do refer to Spring to scan but CDI can scan too) about optionally loading
> specific providers from the specific packages.
>
> CXF itself ships many providers in different modules and packages and it
> is hard to see how one can let users control auto-loading them (which is)
> without letting users choose at the config time...
>
> Cheers, Sergey
>
>
> On 22/12/17 23:15, Andriy Redko wrote:
>
>> 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> 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 <dr...@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 <rm...@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" <dr...@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 <
>>>>>>>>>>>
>>>>>>>>>> drreta@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 <
>>>>>>>>>>>
>>>>>>>>>> sberyozkin@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 <
>>>>>>>>>>>
>>>>>>>>>> sberyozkin@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"<
>>>>>>>>>>>
>>>>>>>>>> johndament@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 <
>>>>>>>>>>>
>>>>>>>>>> sberyozkin@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
>>>>>>>>>>> >>> >>>>>>
>>>>>>>>>>> >>> >>>>>
>>>>>>>>>>> >>> >>>>
>>>>>>>>>>> >>> >>
>>>>>>>>>>>
>>>>>>>>>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
Re: How to automatically register OpenTracingFeature?
Posted by Sergey Beryozkin <sb...@gmail.com>.
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 clarify that there was no magic there in the Spring-Boot
starters/auto-configuration, nothing SpringBoot or Spring specific (well
we do refer to Spring to scan but CDI can scan too) about optionally
loading specific providers from the specific packages.
CXF itself ships many providers in different modules and packages and it
is hard to see how one can let users control auto-loading them (which
is) without letting users choose at the config time...
Cheers, Sergey
On 22/12/17 23:15, Andriy Redko wrote:
> 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> 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 <dr...@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 <rm...@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" <dr...@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 <
>>>>> drreta@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 <
>>>>> sberyozkin@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 <
>>>>> sberyozkin@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"<
>>>>> johndament@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 <
>>>>> sberyozkin@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
>>>>>>>>>> >>> >>>>>>
>>>>>>>>>> >>> >>>>>
>>>>>>>>>> >>> >>>>
>>>>>>>>>> >>> >>
>
>
>
>
>
>
>
>
>
>
Re: How to automatically register OpenTracingFeature?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le 23 déc. 2017 18:15, "Andriy Redko" <dr...@gmail.com> 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 help middle of next week but in short we just need to use a Config
lookup for microprofile and ConfigResolver for deltaspike.
RMB> Le 23 déc. 2017 16:15, "Andriy Redko" <dr...@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" <dr...@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 <dr...@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 <rmannibucau@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" <dr...@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 <
>>>>>> drreta@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 <
>>>>>> sberyozkin@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 <
>>>>>> sberyozkin@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"<
>>>>>> johndament@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 <
>>>>>> sberyozkin@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
>>>>>>>>>>> >>> >>>>>>
>>>>>>>>>>> >>> >>>>>
>>>>>>>>>>> >>> >>>>
>>>>>>>>>>> >>> >>
Re: How to automatically register OpenTracingFeature?
Posted by Andriy Redko <dr...@gmail.com>.
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" <dr...@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" <dr...@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 <dr...@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 <rm...@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" <dr...@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 <
>>>>>> drreta@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 <
>>>>>> sberyozkin@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 <
>>>>>> sberyozkin@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"<
>>>>>> johndament@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 <
>>>>>> sberyozkin@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
>>>>>>>>>>> >>> >>>>>>
>>>>>>>>>>> >>> >>>>>
>>>>>>>>>>> >>> >>>>
>>>>>>>>>>> >>> >>
Re: How to automatically register OpenTracingFeature?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le 23 déc. 2017 16:15, "Andriy Redko" <dr...@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" <dr...@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 <dr...@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 <rm...@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" <dr...@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 <
>>>>> drreta@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 <
>>>>> sberyozkin@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 <
>>>>> sberyozkin@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"<
>>>>> johndament@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 <
>>>>> sberyozkin@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
>>>>>>>>>> >>> >>>>>>
>>>>>>>>>> >>> >>>>>
>>>>>>>>>> >>> >>>>
>>>>>>>>>> >>> >>
Re: How to automatically register OpenTracingFeature?
Posted by Andriy Redko <dr...@gmail.com>.
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.
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" <dr...@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 <dr...@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 <rm...@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" <dr...@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 <
>>>>> drreta@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 <
>>>>> sberyozkin@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 <
>>>>> sberyozkin@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"<
>>>>> johndament@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 <
>>>>> sberyozkin@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
>>>>>>>>>> >>> >>>>>>
>>>>>>>>>> >>> >>>>>
>>>>>>>>>> >>> >>>>
>>>>>>>>>> >>> >>
Re: How to automatically register OpenTracingFeature?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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" <dr...@gmail.com> a écrit :
> 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> 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 <dr...@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 <rm...@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" <dr...@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 <
> >>>> drreta@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 <
> >>>> sberyozkin@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 <
> >>>> sberyozkin@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"<
> >>>> johndament@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 <
> >>>> sberyozkin@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
> >>>>>>>>> >>> >>>>>>
> >>>>>>>>> >>> >>>>>
> >>>>>>>>> >>> >>>>
> >>>>>>>>> >>> >>
>
>
>
>
>
>
>
>
>
>
>
Re: How to automatically register OpenTracingFeature?
Posted by Andriy Redko <dr...@gmail.com>.
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> 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 <dr...@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 <rm...@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" <dr...@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 <
>>>> drreta@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 <
>>>> sberyozkin@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 <
>>>> sberyozkin@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"<
>>>> johndament@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 <
>>>> sberyozkin@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
>>>>>>>>> >>> >>>>>>
>>>>>>>>> >>> >>>>>
>>>>>>>>> >>> >>>>
>>>>>>>>> >>> >>
Re: How to automatically register OpenTracingFeature?
Posted by Sergey Beryozkin <sb...@gmail.com>.
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 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 <dr...@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 <rm...@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" <dr...@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 <
>>> drreta@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 <
>>> sberyozkin@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 <
>>> sberyozkin@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"<
>>> johndament@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 <
>>> sberyozkin@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
>>>>>>>> >>> >>>>>>
>>>>>>>> >>> >>>>>
>>>>>>>> >>> >>>>
>>>>>>>> >>> >>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>
>
>
Re: How to automatically register OpenTracingFeature?
Posted by Sergey Beryozkin <sb...@gmail.com>.
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 providers auto-discovered...
Sergey
On 22/12/17 22:27, John D. Ament wrote:
> 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 need to list it in their Application class as a singleton/class?
>
> John
>
> On Fri, Dec 22, 2017 at 5:08 PM Andriy Redko <dr...@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 <rm...@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" <dr...@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 <
>> drreta@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 <
>> sberyozkin@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 <
>> sberyozkin@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"<
>> johndament@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 <
>> sberyozkin@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
>>>>>>> >>> >>>>>>
>>>>>>> >>> >>>>>
>>>>>>> >>> >>>>
>>>>>>> >>> >>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>
>>
>>
>
Re: How to automatically register OpenTracingFeature?
Posted by Andriy Redko <dr...@gmail.com>.
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
JDA> 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?
JDA> John
JDA> On Fri, Dec 22, 2017 at 5:40 PM Andriy Redko <dr...@gmail.com> wrote:
JDA> Documenting make sense. To project it to Spring-based runtime, fe, without
JDA> Spring-specific annotations + configuration the discovery won't happen ...
JDA> But there is Spring Boot which could do magic here, and CXF does have a
JDA> module for it. Same, in theory, could be possible with CXF+CDI (let say by
JDA> adding `cxf-cdi` module where we could supply the limited, handcrafted
JDA> set of CDI beans available for discovery in the beans.xml). Do you think it
JDA> is worth exploring the idea?
JDA> Best Regards,
JDA> 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 <dr...@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 <rm...@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" <dr...@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 <
>>> drreta@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 <
>>> sberyozkin@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 <
>>> sberyozkin@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"<
>>> johndament@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 <
>>> sberyozkin@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
>>> >> > >> >>> >>>>>>
>>> >> > >> >>> >>>>>
>>> >> > >> >>> >>>>
>>> >> > >> >>> >>
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
Re: How to automatically register OpenTracingFeature?
Posted by "John D. Ament" <jo...@apache.org>.
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 <dr...@gmail.com> 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 <dr...@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 <rm...@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" <dr...@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 <
> >> drreta@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 <
> >> sberyozkin@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 <
> >> sberyozkin@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"<
> >> johndament@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 <
> >> sberyozkin@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
> >> >> > >> >>> >>>>>>
> >> >> > >> >>> >>>>>
> >> >> > >> >>> >>>>
> >> >> > >> >>> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
>
>
>
>
Re: How to automatically register OpenTracingFeature?
Posted by Andriy Redko <dr...@gmail.com>.
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 <dr...@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 <rm...@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" <dr...@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 <
>> drreta@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 <
>> sberyozkin@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 <
>> sberyozkin@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"<
>> johndament@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 <
>> sberyozkin@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
>> >> > >> >>> >>>>>>
>> >> > >> >>> >>>>>
>> >> > >> >>> >>>>
>> >> > >> >>> >>
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
Re: How to automatically register OpenTracingFeature?
Posted by "John D. Ament" <jo...@apache.org>.
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 need to list it in their Application class as a singleton/class?
John
On Fri, Dec 22, 2017 at 5:08 PM Andriy Redko <dr...@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 <rm...@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" <dr...@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 <
> drreta@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 <
> sberyozkin@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 <
> sberyozkin@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"<
> johndament@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 <
> sberyozkin@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
> >> > >> >>> >>>>>>
> >> > >> >>> >>>>>
> >> > >> >>> >>>>
> >> > >> >>> >>
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
>
>
>
Re: How to automatically register OpenTracingFeature?
Posted by Andriy Redko <dr...@gmail.com>.
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 <rm...@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" <dr...@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 <dr...@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 <sb...@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 <sb...@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"<jo...@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 <sb...@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
>> > >> >>> >>>>>>
>> > >> >>> >>>>>
>> > >> >>> >>>>
>> > >> >>> >>
>> >
>> >
>> >
>> >
>> >
>> >
Re: How to automatically register OpenTracingFeature?
Posted by "John D. Ament" <jo...@apache.org>.
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 discovery of providers in CDI if they're not CDI managed - which is OK and the answer I was working through.
And realistically, this issue is not specific to the open tracing integration, I can replicate it with other providers. Its just a matter of documenting and knowing what to setup.
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.
John
On 2017-12-22 15:24, Romain Manni-Bucau <rm...@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" <dr...@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 <dr...@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 <sb...@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 <sb...@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"<jo...@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 <sb...@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
> > >> >>> >>>>>>
> > >> >>> >>>>>
> > >> >>> >>>>
> > >> >>> >>
> >
> >
> >
> >
> >
> >
>
Re: How to automatically register OpenTracingFeature?
Posted by Andriy Redko <dr...@gmail.com>.
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" <dr...@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 <dr...@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 <sb...@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 <sb...@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"<jo...@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 <sb...@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
>>> >>> >>>>>>
>>> >>> >>>>>
>>> >>> >>>>
>>> >>> >>
Re: How to automatically register OpenTracingFeature?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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" <dr...@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 <dr...@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 <sb...@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 <sb...@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"<jo...@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 <sb...@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
> >> >>> >>>>>>
> >> >>> >>>>>
> >> >>> >>>>
> >> >>> >>
>
>
>
>
>
>
Re: How to automatically register OpenTracingFeature?
Posted by Andriy Redko <dr...@gmail.com>.
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 <dr...@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 <sb...@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 <sb...@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"<jo...@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 <sb...@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
>> >>> >>>>>>
>> >>> >>>>>
>> >>> >>>>
>> >>> >>
Re: How to automatically register OpenTracingFeature?
Posted by Sergey Beryozkin <sb...@gmail.com>.
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,
> 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 <dr...@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 <sb...@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 <sb...@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"<jo...@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 <sb...@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
> >>> >>>>>>
> >>> >>>>>
> >>> >>>>
> >>> >>
>
>
>
>
Re: How to automatically register OpenTracingFeature?
Posted by Andriy Redko <dr...@gmail.com>.
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 <dr...@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 <sb...@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 <sb...@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"<jo...@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 <sb...@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
>>> >>>>>>
>>> >>>>>
>>> >>>>
>>> >>
Re: How to automatically register OpenTracingFeature?
Posted by "John D. Ament" <jo...@apache.org>.
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 Fri, Dec 22, 2017 at 11:12 AM Andriy Redko <dr...@gmail.com> wrote:
> 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 have why it is not being picked up it the absense of bean.xml so we
> could fix that. I will
> take a look shorly (if you haven't figured this one out already). Thanks.
>
> Best Regards,
> 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 <sb...@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 <sb...@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"<jo...@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 <sb...@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
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>
> >>
>
>
Re: How to automatically register OpenTracingFeature?
Posted by Andriy Redko <dr...@gmail.com>.
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 have why it is not being picked up it the absense of bean.xml so we could fix that. I will
take a look shorly (if you haven't figured this one out already). Thanks.
Best Regards,
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 <sb...@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 <sb...@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"<jo...@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 <sb...@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
>> >>>>>>
>> >>>>>
>> >>>>
>> >>
>>
Re: How to automatically register OpenTracingFeature?
Posted by "John D. Ament" <jo...@apache.org>.
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 it has a CXF @Provider annotation but I see the OpenTracing one does have it)
- Otherwise we assume its the CXF Bus object
There's not much happening with a CXF @Provider declaration in the extension. But at the end of the day, I'm only 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 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.
John
On 2017-12-22 09:56, Sergey Beryozkin <sb...@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 <sb...@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"<jo...@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 <sb...@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
> >>>>>>
> >>>>>
> >>>>
> >>
>
Re: How to automatically register OpenTracingFeature?
Posted by Sergey Beryozkin <sb...@gmail.com>.
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 <sb...@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"<jo...@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 <sb...@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
>>>>>>
>>>>>
>>>>
>>
Re: How to automatically register OpenTracingFeature?
Posted by "John D. Ament" <jo...@apache.org>.
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 <sb...@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"<jo...@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 <sb...@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
> >>>>
> >>>
> >>
>
Re: How to automatically register OpenTracingFeature?
Posted by Sergey Beryozkin <sb...@gmail.com>.
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"<jo...@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 <sb...@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
>>>>
>>>
>>
Re: How to automatically register OpenTracingFeature?
Posted by "John D. Ament" <jo...@apache.org>.
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"<jo...@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 <sb...@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
> > >
> >
>
Re: How to automatically register OpenTracingFeature?
Posted by "John D. Ament" <jo...@apache.org>.
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 <sb...@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
> >
>
Re: How to automatically register OpenTracingFeature?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Custom empty application class but provider subclass to force the
registration
Le 22 déc. 2017 15:08, "John D. Ament" <jo...@apache.org> 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 <rm...@gmail.com> 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" <sb...@gmail.com> 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, 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
> > >>
> > >>
> >
>
Re: How to automatically register OpenTracingFeature?
Posted by "John D. Ament" <jo...@apache.org>.
What does your Application class look like, or are you using no application class?
On 2017-12-22 08:35, Romain Manni-Bucau <rm...@gmail.com> 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" <sb...@gmail.com> 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, 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
> >>
> >>
>
Re: How to automatically register OpenTracingFeature?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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" <sb...@gmail.com> 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, 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
>>
>>
Re: How to automatically register OpenTracingFeature?
Posted by Sergey Beryozkin <sb...@gmail.com>.
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
>