JBoss Community

Marius Bogoevici wrote:

 

Restarting the discussion. In summary, what Weld/CDI needs is:

 

1) EJB defers instance creation to an external component

    - Weld deployer sets the instantiator components that will:

             a) invoke the applicable CDI constructor of the EJB class

             b) apply decorators on the EJB

             c) *not* apply interceptors on the EJB - for now, this remains a responsibility of the EJB container

I believe I've now released something which accounts for this.

http://github.com/jbossejb3/jboss-ejb3-bean-instantiator

The above has been released as 1.0.0-alpha-1 and integrated into ejb3-core (ie. we now use the abstraction for EJB bean instance creation).  This has not yet been integrated into AS yet (as that relies upon a release of core, which is a formal release chain).

The general idea is that you create an implementation of the SPI, and create an MC bean called NAME_BEAN_INSTANCE_INSTANTIATOR from

http://github.com/jbossejb3/jboss-ejb3-bean-instantiator/blob/master/spi/src/main/java/org/jboss/ejb3/instantiator/spi/AttachmentNames.java

Once you do this, the deployer impl will pick it up and wire things along such that the EJBContainer uses it.  So make one artifact which implements jboss-ejb3-instantiator-spi, and inside it put the impl class and a META-INF/weld-bean-instantiator-jboss-beans.xml which may look like:

<?xml version="1.0" encoding="UTF-8"?>
 
  <!--
    Declares a EJB3 Bean Instantiator
-->
<deployment xmlns="urn:jboss:bean-deployer:2.0">
 
  <bean name="org.jboss.ejb3.bean.BeanInstantiator"
    class="org.jboss.ejb3.instantiator.impl.Ejb31SpecBeanInstantiator" />
 
</deployment>

Check out the layout of the jboss-ejb3-instantiator-impl module for our current legacy impl.  Basically you'll be writing the same thing. :)

Also note that we currently don't support any construction parameters.  ejb3-core doesn't have any available to pass along.  So even though the contract accepts construction params, I'm passing in Object[]{}.  If that needs to be addressed...let me know and we'll figure something.

Marius Bogoevici wrote:

 

2) EJB container provides a hook for preprocessing interceptors after instantiation. The main reason is that EJB interceptors may be CDI-injected

(note: could we reuse the same mechanism as for EJB instantiation, since it boils down to producing an instance of the class? )

I'm pretty sure we could do this too.  We have this bit of code, though I haven't verified if it's currently used or cruft:

public Object createInterceptor(Class<?> interceptorClass) throws InstantiationException, IllegalAccessException
   {
      Object instance = interceptorClass.newInstance();
      InterceptorInjector interceptorInjector = interceptorInjectors.get(interceptorClass);
      assert interceptorInjector != null : "interceptorInjector not found for " + interceptorClass;
      interceptorInjector.inject(null, instance);
      return instance;
   }

Plenty of room in there to both abstract away the instantiation or give some post-instantiation callback before the instance is returned.

S,

ALR