Thinking out loud: did we check we can use @CxfXXX on application class? Do
we respect it for properties?
Le 24 déc. 2017 22:22, "Andriy Redko" a écrit :
> Oh you mean, the configuration implementation. Sure, I think if the
> general approach make sense, starting
> from cxf properties would be a
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" a écrit :
RMB> No API sounds good. Jus
Le 24 déc. 2017 21:40, "Andriy Redko" a écrit :
No API sounds good. Just to clarify the second part. "By reflection" you
mean just go with classpath scan?
No, CXF must never scan anything, it is already done and would defeat any
integration and user experience to redo it. Just meant test deltas
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 hard dep on any api would be nice but a chain can work even if by
reflection no? Kind of test them all. Then put the active ones in the
server map to be able to reuse it later no?
Le 24 déc. 2017 19:07, "Andriy Redko" a écrit :
> Hey guys,
>
> So I have been looking around to understand how t
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
@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 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
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
Le 23 déc. 2017 18:15, "Andriy Redko" a écrit :
Aha moment, so there are limitations, that's why I was unsure about that.
Regarding deltaspike / microprofile
config, we can look it up, if you have some examples / snippets to point
out right away, would be great. Thanks.
Can help middle of next
Aha moment, so there are limitations, that's why I was unsure about that.
Regarding deltaspike / microprofile
config, we can look it up, if you have some examples / snippets to point out
right away, would be great. Thanks.
RMB> Le 23 déc. 2017 16:15, "Andriy Redko" a écrit :
RMB> I have kind
Le 23 déc. 2017 16:15, "Andriy Redko" a écrit :
I have kind of disagree here, beans.xml has a dedicated section for
discovery (, spec section 12.4. Type and Bean
discovery). I am trying not to (re)invent our own activation / discovery
mechanisms but find the right way to deligate that to
the fram
I have kind of disagree here, beans.xml has a dedicated section for discovery
(, spec section 12.4. Type and Bean
discovery). I am trying not to (re)invent our own activation / discovery
mechanisms but find the right way to deligate that to
the framework in question. Not only CXF would benefit fr
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"
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/fr
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
Ah ha, I see it now. We just need a better implementation of
ClasspathScanner. Have you looked at https://github.com/ronmamo/reflections by
any chance?
John
On Fri, Dec 22, 2017 at 5:40 PM Andriy Redko wrote:
> Documenting make sense. To project it to Spring-based runtime, fe, without
> Sprin
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
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
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 provide
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 n
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 - sho
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 woul
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 dis
How can i disable it now? Tink that cxf feature - even if in separate
modules - shouldnt be auto registered until it has a deactivable flag -
classpath properties + overridable through system prop.
Wdyt?
Le 22 déc. 2017 18:38, "Andriy Redko" a écrit :
> Hi Sergey,
>
> It wasn't (for CDI only),
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
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,
Andr
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
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 (a
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 F
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 hav
Custom empty application class but provider subclass to force the
registration
Le 22 déc. 2017 15:08, "John D. Ament" a écrit :
> What does your Application class look like, or are you using no
> application class?
>
> On 2017-12-22 08:35, Romain Manni-Bucau wrote:
> > In meecrowave im using it
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 i
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 featur
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
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
What does your Application class look like, or are you using no application
class?
On 2017-12-22 08:35, Romain Manni-Bucau wrote:
> In meecrowave im using it and it works while the jar name is not excluded
> of the scanning
>
> Le 22 déc. 2017 14:16, "Sergey Beryozkin" a écrit :
>
> > It i
Actually one more thing. The CDI extension only looks for JAX-RS @Provider not
CXF @Provider.
On 2017-12-22 09:06, "John D. Ament" wrote:
> I'm not sure what the CDI extension has to do with this. It has no bean
> defining annotations, and there is no beans.xml in the JAR that it ships with
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 2
In meecrowave im using it and it works while the jar name is not excluded
of the scanning
Le 22 déc. 2017 14:16, "Sergey Beryozkin" a écrit :
> It is annotated with CXF @Provider annotation - should be picked up by the
> CXF CDI extension
>
> Sergey
> On 22/12/17 13:07, John D. Ament 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
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)
42 matches
Mail list logo