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 <drr...@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 <rmannibu...@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" <drr...@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 <
drr...@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 <
sberyoz...@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 <
sberyoz...@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"<
johndam...@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 <
sberyoz...@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
>>> >>>>>>
>>> >>>>>
>>> >>>>
>>> >>
