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
