Unexpected NoClassDefFoundError when an MBean depends on an

[forkbomb]

I have an MBean contained in a SAR that depends on a session bean in a separate EJB jar file, and I have included the appropriate depends element in jboss-service.xml. I would like my SAR file to contain ONLY the MBean, but I get a NoClassDefFoundError for my session bean's local interface from ServiceConfigurator.install. This is surprising to me, since I would assume that the class wouldn't need to be loaded until the start method on my MBean is called, presumably after my EJB jar file has been deployed, as there is no static initialization that requires the session bean in the MBean. The MBean also uses a lot of other utility classes (which are also contained in the EJB jar file that it depends on), but I don't have to include those in the SAR file in order to get it to deploy properly. After I include the EJB local interface, I can see that all the proper dependency checking is happening in the JBoss debug output on startup and the deployment succeeds. Why do I need to include the EJB's local interface? This is all on 4.0.2.

--Steven

[starksm64]

Dependency is not down to the level of class loading. If you read the service mbean behavior in chapter 2 of the server guide it will be clear that the service lifecycle notion applies well have the service is created in the jvm.

The jboss5 microcontainer will support class loader level dependencies.

[forkbomb]

Scott,
Thanks for the quick reply, but I'm not quite sure I understand your answer. Perhaps this isn't the proper board for this question, because this is really a classloading question; I just happened to run into the problem when deploying an MBean.

My goal is to have only one copy of every class anywhere in the server because we are using the Unified ClassLoader with class sharing among all applications. Having 2 copies of a class has caused problems in the past. For example,

Class A in package com.example has protected method callMe().
Class B, also in package com.example tries to call A's callMe().
The WEB-INF/lib directory of a war file contains a jar that contains both A and B, and a utility jar contained in a separate ear also contain A and B.
Class A and class B happen to be loaded by different classloaders (one for the ear, one for the war).
Result is an IllegalAccessError.

Our solution is to use the following rules for deployment:

• 
  
• Only one deployment unit should contain any class.
  
• All classes in a particular package should always be included in the same deployment unit.
  
  
  Now, I have an MBean that depends on an EJB. The EJB's local interface is already being deployed in a separate deployment unit. Since the SAR that contains the MBean will not always be deployed with the application, I don't want to include the local interface ONLY in the SAR.
  
  Are you saying it's impossible to make the MBean depend on the EJB without including the classes in the SAR? What is the recommended approach for deployment in this situation, given that we are sharing classes across applications? Putting the classes in the lib directory for my configuration is not an option, since I would like hoy deployment to work. Thanks,
  
  --Steven

[dimitris]

One solution would be to package all the shared classes in a .jar, and use e.g. the PrefixDeploymentSorter in the DeploymentScanner to deploy this .jar before the .sar & ejbs