Classloading and multiple non-isolated EARs

[lhoriman]

I just read the (great!) article http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossClassLoadingUseCases and wanted to verify that I understand a few things correctly.

My goal is to have two EARs which invoke each other and share many classes. In one deployment scenario, both EARs will be deployed into a single JBoss instance. In another deployment scenario, they will be located on different instances within a cluster.

The logical thing to do, it would seem, would be to package complete EARs, each of which contain full copies of all the "shared" classes and libraries. If I have read the JBossClassLoadingUseCases article correctly, the existance of these duplicate classes within a single JBoss instance will not be an issue - the class repository will contain only one instance of each loaded class, and as long as the duplicate classes are identical my applications will never be the wiser. It will all magically just work as long as both applications have the same versions of every library and class.

True?

Next question: Since remoteness is one of the deployment scenarios, application A will have to be written to use application B's remote interface. When both applications are deployed within the same JBoss instance, will JBoss optimize the remote invocation to a local by-reference invocation and skip the expensive marshalling? Or do I need to have the code perform some sort of detection to determine which interface to use? If so, how do I detect that?

Thanks in advance!

Jeff Schnitzer

[starksm64]

True.

Its automatic.

[lhoriman]

That's great... I tried it, and the classloading worked as advertised :-)

However, it seems to break EJB injection. Both of my application EARs contain a common ejb-jar withs some basic tools (my DAO ejb and my entities). Trying to inject the DAOEJB results in this:

Caused by: java.lang.RuntimeException: For EJB ReceptionistEJB could not find jn
di binding based on interface only for @EJB(com.blorn.entity.dao.DAO) duplicated
 in entity.jar and entity.jar
 at org.jboss.ejb3.injection.EJBHandler.getJndiName(EJBHandler.java:216)
 at org.jboss.ejb3.injection.EJBHandler.loadFieldInjectors(EJBHandler.jav
a:326)
 at org.jboss.ejb3.injection.EJBHandler.loadInjectors(EJBHandler.java:78)

 at org.jboss.ejb3.injection.EJBHandler.loadInjectors(EJBHandler.java:57)

 at org.jboss.ejb3.EJBContainer.resolveInjectors(EJBContainer.java:651)
 at org.jboss.ejb3.EJBContainer.initializePool(EJBContainer.java:586)
 at org.jboss.ejb3.EJBContainer.start(EJBContainer.java:518)
 at org.jboss.ejb3.SessionContainer.start(SessionContainer.java:82)
 at org.jboss.ejb3.stateless.StatelessContainer.start(StatelessContainer.
java:80)
 ... 124 more

This makes some amount of sense because there are two JNDI entries, appA/DAOEJB/local and appB/DAOEJB/local. However, shouldn't the reference within an application's EAR be found first?

Looking at the code for Ejb3Deployment.getEjbJndiName(), it would seem that this should be the case. First the jar of the EJB requesting injection is checked, then all deployments within the EAR containing the requesting EJB, then the global Ejb3Registry. However, when I walk through with a debugger, I find that the second part is not working. The local DAOEJB is not found in the EAR search, but both DAOEJBs are found in the Ejb3Registry. I've checked and rechecked my packaging, but it looks correct.

Is this a bug?

Thanks,
Jeff Schnitzer

[starksm64]

Undoubtedly. Create a bug report and if you have an example that can be made into a unit test attach that. Thanks.
http://jira.jboss.com/jira/browse/EJBTHREE

[lhoriman]

Done:

http://jira.jboss.com/jira/browse/EJBTHREE-454

Thanks,
Jeff

[fcorneli]

Hi,

I just stumbled on the same issue within the application I'm developing. When will this bug be solved? It's really a show stopper for us...

Regards,
Frank.

[starksm64]

Read the issue and the fix for version roadmap.