Pluggable @EJB Resolvers

[alrubinger]

This is something I've had in mind for a couple weeks now.

We presently do our resolving based on mappedName, interface type, etc in the AS server module's MappedReferenceMetaDataResolverDeployer.

For Integration/Injection into MC Beans, this needs to be extracted into A more Pluggable resolver (as I think Carlo's already done similarly w/ JPA).

Carlo mentioned we need to get something like this done for WS Support anyway, so that'll be the perfect opportunity for me to piggyback on this for MC Integration. :)

Would like to use this Thread to discuss what the design will look like.

S,
ALR

[wolfc]

I'm contemplating whether to change the supply/demand chain as well. It can work with only JNDI names. In which case we would get:

interface EJBDependencyResolver {
 /** @return JNDI name */
 String resolveEJBReference(DeploymentUnit deploymentUnit, String beanName, Class<?> beanInterface, String mappedName);
}

At least 1 argument must be specified. mappedName is for unforeseens, because now it's the JNDI name.

For WS it's a bit different, because they can invoke any public method on a bean. So they can't invoke through the current proxies.

[alrubinger]

What do we need the deployment unit for? A ClassLoader and JBoss50MetaData could suffice?

S,
ALR

[wolfc]

Deployment unit is the deployment containing the reference. Despite previous statement, it must be specified.

For example suppose A.jar has BeanA with @EJB BeanB b; then the deployment unit will point to A.jar. If that doesn't contain BeanB, then we go to the top level deployment unit (hopefully X.ear) and start looking there. For each deployment unit the JBossMetaData attachment is queried.

I don't see how a class loader works into play here.

[alrubinger]

I hadn't considered nested deployments, which is why we need DeploymentUnit. If JBossMetaData had a parent reference this might be a different story, but the reason I asked was to avoid the dependency on the Deployers SPI.

I mentioned ClassLoader for the case that we'd need to construct Class objects from metadata in order to check assignability/equality of bean interfaces.

S,
ALR

[wolfc]

You don't want to go into class loader details. The beanInterface name is used for comparisons. It's actually a view identifier and not a Java interface as such.

[alrubinger]

https://jira.jboss.org/jira/browse/EJBTHREE-1616.

I've committed a jumping-off point in r82106.

The idea is that a EJB Reference resolver adheres to the SPI, and its implementation is defined by an MC deployment:

<!-- EJB Reference Resolver -->
 <bean name="org.jboss.ejb3.EjbReferenceResolver" class="org.jboss.ejb3.common.resolvers.spi.EjbReferenceResolver">
 <constructor factoryClass="org.jboss.ejb3.common.resolvers.spi.EjbReferenceResolverFactory"
 factoryMethod="newInstance">
 <parameter>org.jboss.ejb3.common.resolvers.plugins.FirstMatchEjbReferenceResolver</parameter>
 </constructor>
 </bean>

Other components (ie. WebBeans integration layer) would then consult this MC Bean.

S,
ALR

[alrubinger]

"wolfc" wrote:
You don't want to go into class loader details. The beanInterface name is used for comparisons. It's actually a view identifier and not a Java interface as such.

Then how do you resolve:

@Local
interface MyBusinessLocal extends MyCommon

@EJB
MyCommon myBean;

For this you need to load the class in order to get all superclasses as well.

S,
ALR

[wolfc]

That does not resolve.

@Remote interface MyBusinessRemote extends MyCommon

Now what? You've undefined semantics.

[alrubinger]

"wolfc" wrote:
That does not resolve.

@Remote interface MyBusinessRemote extends MyCommon

Now what? You've undefined semantics.

In that case you've got to override @EJB(beanInterface) to something worthwhile, else you get NonDeterministicInterfaceException

S,
ALR