Andriy, Well, I think the difference here is that server customizations are not CDI specific. It looks like they were put there, but I can think of other use cases where an externally managed JAXRSServerFactoryBean is externally managed, and being able to invoke a series of callbacks to further tweak that server would be very useful.
It's just a thought, since I was playing around with how to automate SSE integration when someone else creates the factory, without using CDI; e.g. other cases of CXFNonSpringJaxrsServlet. John On 2017-11-27 21:40, Andriy Redko <[email protected]> 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 > >
