Deployment order for EAR in JBoss 5.1

[getaceres]

Hello, I'm trying to port an application (EAR) which was working with JBoss 4.2.3 to JBoss 5.1.0. I know that the <strict> option has been removed from the jboss-app.xml file so there is no way to specify a strict order of deployment of EJB modules. As I understand, JBoss should try to deploy the included modules in alphabetical order. Correct me if I'm wrong. So I renamed my modules to start with a letter in order to get the deployment sequence that I want. This is my application.xml:

<?xml version="1.0" encoding="UTF-8"?>
<application xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_5.xsd" version="5">
  <display-name>OHA-Core</display-name>
  <module>
    <ejb>a-oha-user-info-beans.jar</ejb>
  </module>
  <module>
    <ejb>b-oha-user-info-services.jar</ejb>
  </module>
  <module>
    <web>
      <web-uri>c-oha-rest-services.war</web-uri>
      <context-root>OHA-RestServices</context-root>
    </web>
  </module>
  <module>
    <ejb>d-oha-local-backend.jar</ejb>
  </module>
  <module>
    <ejb>e-google-health-backend.jar</ejb>
  </module>
  <library-directory>lib</library-directory>
</application>

However, when I deploy my application I get this error:

2011-05-26 13:57:21,708 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (HDScanner) Error installing to PostClassLoader: name=vfszip:/home/jsanchez/apps/jboss/jboss-5.1.0.GA/server/default/deploy/OHA-Core.ear/ state=ClassLoader mode=Manual requiredState=PostClassLoader
org.jboss.deployers.spi.DeploymentException: Error during deploy: vfszip:/home/jsanchez/apps/jboss/jboss-5.1.0.GA/server/default/deploy/OHA-Core.ear/d-oha-local-backend.jar/
    at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
    at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:177)
    at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
    at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
    at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1210)
    at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
    at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
    at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
    at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
    at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
    at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
    at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
    at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
    at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
    at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
    at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
    at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:362)
    at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:255)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
    at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
    at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.NullPointerException
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:247)
    at org.jboss.metadata.process.processor.ejb.jboss.SetDefaultLocalBusinessInterfaceProcessor.process(SetDefaultLocalBusinessInterfaceProcessor.java:114)
    at org.jboss.metadata.process.chain.ejb.jboss.JBossMetaDataProcessorChain.process(JBossMetaDataProcessorChain.java:115)
    at org.jboss.ejb3.deployers.Ejb3MetadataProcessingDeployer.deploy(Ejb3MetadataProcessingDeployer.java:115)
    at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
    ... 25 more
2011-05-26 13:57:21,718 WARN  [org.jboss.system.server.profileservice.hotdeploy.HDScanner] (HDScanner) Failed to process changes
org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):

*** DEPLOYMENTS IN ERROR: Name -> Error

vfszip:/home/jsanchez/apps/jboss/jboss-5.1.0.GA/server/default/deploy/OHA-Core.ear/ -> org.jboss.deployers.spi.DeploymentException: Error during deploy: vfszip:/home/jsanchez/apps/jboss/jboss-5.1.0.GA/server/default/deploy/OHA-Core.ear/d-oha-local-backend.jar/


DEPLOYMENTS IN ERROR:
  Deployment "vfszip:/home/jsanchez/apps/jboss/jboss-5.1.0.GA/server/default/deploy/OHA-Core.ear/" is in error due to the following reason(s): java.lang.NullPointerException

    at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:993)
    at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:939)
    at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:873)
    at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.checkComplete(MainDeployerAdapter.java:128)
    at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:369)
    at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:255)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
    at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
    at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:662)

It seems to be deploying d-oha-local-backend.jar file but alphabetically, the first file to deploy should be a-oha-user-info-beans.jar. As this jar contains some Hibernate entities and the configuration is set to update the database, I was expecting to see some traces of it being deployed, entities being scanned and tables being updated. But instead, I only get the exception shown above, which makes me think that the fourth module is being deployed in first place and, of course, it can't find the required files it needs because they are in the first two modules, which should have been deployed before.

¿Is there any way that I can fix this? ¿Can I force a concrete order for the module loading?

[alesj]

Module / sub-deployment loding inside .ear should not be relevant for classloading.

Since all sub-deployments move past CL stage at the same time,

hence after any proper CL lookup should work between visible sub-deployments.

This looks like a bug in EJB, since any NPE is always a bug.

[getaceres]

Anyway, it's a NPE in a Class.forName lookup, which usually occurs when trying to get a reference to a class which is not in the classpath. Since the application was working in JBoss 4.2.3, I assume that all the dependent classes are in the jars in lib directory and the other modules so it must be referencing a class before it's been loaded. ¿Maybe the content in the lib directory is loaded after this point so it doesn't find a reference to a class included in lib?

[alesj]

Anyway, it's a NPE in a Class.forName lookup, which usually occurs when trying to get a reference to a class which is not in the classpath.

This is definitely not true, that's what ClassNotFoundException is for -- see javadoc. ;-)

I would guess some null className being passed in is what's causing it.

[getaceres]

Yup. I read the source of SetDefaultLocalBusinessInterfaceProcessor.java:114 and it seems to be related with the parsing and configuration of the jboss.xml file in which I declare the local JNDI address for my EJBs. Probably JBoss 4 was less strict with errors in that file. Once I removed it, I passed this point. I'll see what was wrong with the file and if JBoss 5 implements the mappedName part of the Stateless annotation. In which case I don't need a jboss.xml file anymore.