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