[marius.bogoevici]

Andrew,

You're right about the creation of the instantiatior instance, but it's still a globally-defined bean and the problem, the way I see it, is that you can't have every single deployment replace the global "org.jboss.ejb3.BeanInstantiator" bean for two reasons: a) not every EJB3 deployment is a CDI deployment

and b) Weld bean instantiators need to be created per-deployment unit (as the info they need for instantiating

a particular EJB is specific to the deployment archive that the EJB is defined in).

But now that I'm looking at this again, I have trouble finding an easy way of having a deployment-specific BeanInstantiator being created by the MC and passed onto the EJB3Deployment, since the latter is not an MC bean itself. So I'll try to solve this from within weld-int, but I'm a bit wary of deployer ordering issues.

[jaikiran]

Slightly related to this is the way the BeanInstantiator needs to be passed through the EJB3Deployment to the container constructor. The Singleton container doesn't rely upon EJB3Deployment for being constructed. Effectively, the singleton container will need a different means to @Inject or set the BeanInstantiator during the lifecylce of the container creation (and not during the constructor call). The EJB container itself is a MC bean, so we could probably inject this per container instantiator through MC.

That's something that I was planning to discuss with ALR, but got sidetracked by a different issue.

[marius.bogoevici]

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.

This looks good, and I see that is currently being used for @Resource injection in the least. The main challenge seems to be that interceptorInjectors is encapsulated and initialized inside org.jboss.ejb3.EJBContainer.

I am wondering if we could provide a mechanism similar to the instantiator for passing a custom interceptor injector at deployment time.

[marius.bogoevici]

Also, I am wondering if the instantiator interface can be extended to pass on some information about the EJB that is being instantiated - e.g. the bean name. There can be multiple EJBs with the same bean class, and we need to identify the actual CDI bean.

[marius.bogoevici]

I tried to play a bit with the deployment of Instantiators, so that each JBossEnterpriseBeanMetadata gets one. A first result is in http://github.com/mbogoevici/jboss-ejb3-bean-instantiator

There are some unwieldy bits in there, but overall i cannot see how this can be done fundamentally better, since EjbContainer is not MC-managed, so the injection of instantiators cannot be deferred to the MC.