9 Replies Latest reply on Sep 22, 2010 4:34 PM by shelly.mcgowan

    JSR 250 injection on VDF

    wolfc

      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
      - VDF
      - MC

      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:
      - DataSourceDependencyResolver
      - EjbReferenceResolver
      - PersistenceUnitDependencyResolver

      http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/jpa/trunk/deployers/src/main/java/org/jboss/jpa/resolvers/DataSourceDependencyResolver.java?revision=75431&view=markup
      http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/ejb3/trunk/common/src/main/java/org/jboss/ejb3/common/resolvers/spi/EjbReferenceResolver.java?revision=82106&view=markup
      http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/jpa/trunk/deployers/src/main/java/org/jboss/jpa/resolvers/PersistenceUnitDependencyResolver.java?revision=75553&view=markup

      (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.
      http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/jpa/trunk/mcint/src/main/java/org/jboss/jpa/mcint/beans/metadata/plugins/PersistenceUnitValueMetaData.java?revision=84368&view=markup

      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.