On 13 Jun 2010, at 14:47, Bill Burke wrote:
I've run smack into a serious problem in AS6.
JAX-RS has injection annotations and I need to:
1) Inject into a JAX-RS managed POJO
2) Inject into an EJB instance
3) Inject into CDI bean instance
4) Inject into a Managed Bean instance
5) I'd also like to support Java EE annotation injection (like @EJB and
@Resource) into a JAX-RS managed POJO
While the VDF does allow me to find out if which of these components are
deployed within a WAR so that I easily find out which classes have
JAX-RS annotations, I have to have different integration with each layer
for injections.
I am not alone. EJB has EJB specific injection annotations. Java EE
has common injection annotations, JAX-WS has annotations as well.
Servlet? There's also a multitude of component layers that need to
support these annotations: Managed Beans, EJB instances, servlets,
filters, listeners, JMX Beans, JAX-WS pojos, more?
It would be cool if we had some common facility in which I could do:
Object obj = InjectionFacility.createAndInject(Class<?> someClass)
InjectionFacility.inject(someArbitraryInstance)
InjectionFacility.registerInjector(someJAXRSAnnnotationInjector)
CDI manages a lot (all?) of this.
Yes, all of this can be done with the InjectionTarget API.
Unfortunately, I've been told that I
cannot leverage CDI unless it has been enabled for the deployment.
Also, I've been told that CDI needs to do a lot of scanning and metadata
building and it would be counter-productive to do this for each
deployment. So....
You are failing to differentiate between CDI (a Java EE spec) and Weld (our implementation
of CDI). As I outlined to you on the resteasy mailing list, the reason *CDI* is not
enabled for every *Java EE* deployment is because of concerns (e.g. from Roberto Chinnici)
about overhead. In Weld 1.1 (which we are aiming to release for JBoss AS 6), we will
intend to reuse all the scanning/metadata facility of JBoss AS which largely mitigates
this concern IMO.
1) Can we find a way to use CDI as our injection facility? Maybe
turning off CDI scanning, but enabling its plugin and callback APIs and
SPIs?
Probably this is possible. It would need thought into the expected behavior, but I see no
reason not to do this. In this case, I'm not even that concerned about the scanning
overhead, it is trivial to just not enable scanning in this case.
or
2) Can we develop a common facility that all component layers can use
*INCLUDING* CDI so we don't have to re-invent injection for each and
every framework?
At first glance, this seems to be the best approach. A modern injection framework for
JBoss AS that can call back to the various frameworks (e.g. Weld, JBoss EJB, MC) to
perform the necessary injections on instances. I know we have some old stuff around this,
which is tightly coupled to EJB etc. We did look at this, but no-one seemed to be able to
understand it.
I sincerely hope I don't have to escalate this problem to higher
levels.
I would much rather have this be a bottom-up lead effort instead of a
top-down enforced directive.
So do I.
I think the lead on this needs to come from Jason and team - I would love to be able to
register a CDI injector for JBoss AS that would call back to Weld allowing field, method,
and constructor injection to occur for all Java EE components rather than the mismatched
crap we've had to do. If this matches the CDI InjectionTarget API (seems sensible,
reduce API divergence), even better.