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" <[email protected]> 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 <[email protected]>
> 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 <[email protected]>
> 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 <[email protected]>
> 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"<[email protected]>
> 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 <[email protected]>
> 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
> >>   >>> >>>>>>
> >>   >>> >>>>>
> >>   >>> >>>>
> >>   >>> >>
>
>
>
>
>
>

Reply via email to