cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andriy Redko <>
Subject Re: Rethinking how JAX-RS customizations are looked up in CDI
Date Sun, 03 Dec 2017 20:48:45 GMT
Hey John,

You have a good point, there is nothing CDI specific about factory bean customization we have
right now,
the only CDI specific thing is that we had a problem with CDI flow and number of ways to solve
it. If
we move such customizations to service loader, we could also move the implementation itself
from CDI
extension to JAXRSServerFactoryBean, so the servlet-based configuration (the transport) becomes
optional/not necessary. It's worth trying out I think.


Best Regards,
    Andriy Redko

JDA> Andriy,

JDA> Well, I think the difference here is that server customizations are not CDI specific.
 It looks like they were put
JDA> there, but I can think of other use cases where an externally managed JAXRSServerFactoryBean
is externally managed,
JDA> and being able to invoke a series of callbacks to further tweak that server would
be very useful.

JDA> It's just a thought, since I was playing around with how to automate SSE integration
when someone else creates the
JDA> factory, without using CDI; e.g. other cases of CXFNonSpringJaxrsServlet.

JDA> John

JDA> On 2017-11-27 21:40, Andriy Redko <> wrote: 
>> Hey John,
>> I think this would be a better alternative, we could use the same mechanism
>> as for external providers (using ServiceLoader, as also you suggested). I am
>> not sure what is the best option, it looks somewhat nature to use CDI capabilities
>> to fullfil CDI-specific cases, but practically speaking, ServiceLoader would be
>> enough in this case.
>> Thanks.
>> Best Regards,
>>     Andriy Redko
>> JDA> I was wondering, does it really make sense
>> JDA> for JAXRSServerFactoryCustomizationExtension implementations to be CDI
>> JDA> beans?  It may sound odd, but typically in CDI that kind of feature is done
>> JDA> as a service loader pattern.  These are classes that should only be used
>> JDA> once, so keeping them in memory is a bit of a waste.  I think recently we
>> JDA> saw some issues with SSE integration, where we had to make the archive a
>> JDA> full bean archive (bean-discovery-mode=all) just to ensure that this bean
>> JDA> was looked up.  It may make more sense if these are ServiceLoader based
>> JDA> classes, this way we just have to register it in META-INF/services without
>> JDA> adding any CDI specific features to the JAR.
>> JDA> At the same time, I also wonder if this causes an issue for Java 9
>> JDA> modules.  Does the dependency have to always be there, or can it be an
>> JDA> optional dependency (my module foo is weak, so I have no idea if that's
>> JDA> even feasible).
>> JDA> John

View raw message