Right now we have a couple of injection frameworks. I have yet to see one that is not flawed when running on top of MC.
There are three layers (for the moment let's ignore javax.interceptor) of injection:
- JSR 250
JSR 250 is the JavaEE standard of injection. The big difference with the other two is that it goes through JNDI.
VDF injection is something that's currently underestimated, more on this later.
MC injection is your basic @Inject of MC beans. The big difference here is that it is unscoped. (The moment somebody besides Adrian understands ScopedKernelController, I'll revise that statement. ;-) )
The most important thing to understand is the difference between installing and starting a component. At any moment a component can be installed, but it's not ready to service any calls at that time. A component is ready to accept calls when all of its dependencies are satisfied. This must include the injections. Unless MC injection is used almost everybody forgets these!
The injection framework must never rely on runtime components to determine dependencies. It leads into problems like https://jira.jboss.org/jira/browse/JBAS-5713 . So the usage of InjectionContainer during that phase is wrong. But EJB3's metadata view is only complete after InjectionContainer is reinitialized ( http://www.jboss.org/index.html?module=bb&op=viewtopic&t=154877 ), because of AOP.
Keeping the EJB3's metadata view out of sight, an alternative is the MappedReferenceMetaDataResolverDeployer. But this thing is too bloated to do fine grained resolving.
So to have fine grained resolving the Resolvers came into being:
(The actual Resolver contract still needs to be ironed out, some of them are returning bean names (not usable by JSR 250), others JNDI names (what about dependencies?).)
This is where VDF comes into play. To do a JSR 250 style injection using MC you need to scope it correctly. VDF is the only one who knows the deployment scope (/ deployment unit). So I would need to pull a stunt as in PersistenceUnitValueMetaData.findBean & getPersistenceUnitBeanName to do the same thing with MC injection.
A component-factory onto MC ( http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/component-factory/trunk ) will not work, because it ignores the scoping rules layout out by JavaEE. It's even unaware of VDF.
So we need a common injection framework that works on MC/VDF (/JBoss Reloaded ;-) ) and is usable somehow by EJB3 containers.
Other JBossWS related issues:
First two issues are fixed in latest JBossWS release. However our "JBossWS Injection Framework" is executed at runtime (usually on first web service request).
This is fundamentally wrong according to the statement above.
The third issue will probably be replaced by RELOADED-8. JBossWS will need to synchronize on that issue as well.
Right now we have a couple of injection frameworks.
Identified JBossWS Project Injection Requirements:
JSR-244 - Java Platform, Enterprise Edition (a.k.a. Java EE 5)
- Chapter 5.2.3 - Annotations and Injection
JSR-224 - The Java API for XML Web Services (a.k.a JAX-WS 2.1)
- Chapter 5.2.1 - Endpoint Usage
- Chapter 5.3 - javax.xml.ws.WebServiceContext
- Chapter 7.9 - javax.xml.ws.WebServiceRef
- Chapter 7.10 - javax.xml.ws.WebServiceRefs
- Chapter 9.3.1 - Handler Lifecycle
- although not explicitly specified in any of the above specs
we implemented the @EJB injection support in JBossWS components.
This feature is required from JSR-244 -> Chapter 5.2.3 -> Table EE.5-1 (IOHO)
EE 6 Injection is one of the goals of the AS 6.0.0.CR1 release. This discussion was recently resurrected and current proposal outlined in the Design of JBoss Injection. One of the outstanding issues that remains is providing an abstraction between MC and Injector for the dependencies to determine readiness and proper ordering. Example of the issue can be seen here