5 Replies Latest reply on Mar 3, 2009 1:53 AM by jaikiran pai

    JBOSS 5 Deployment Ordering of EAR Structure

    Raymond Lancaster Newbie

      Sorry for the long posting but I want to provide everything I know at this point.

      Currently my company has an application that we deploy into JBoss 3.2.6. To take advantage of newer technology we have started a spike to to determine what is necessary for us to upgrade to JBoss 5. I downloaded JBoss-5 Beta 2 and started working on changes to our application to get it to deploy. Currently I have noticed that components of the application appear to be deploying in an order different from that which was defined in JBoss 3. Currently everything seems to be deploying in name order and this is conflicting with our dependency order.

      First I noticed that my data-source (mssql-ds.xml) is deploying later than my application (destiny.ear) which is causing issues obtaining pooled connections to the database during startup. This issue can be dealt with by renaming the file to ensure that it is loaded before the application.

      The second issue, the bigger problem for us right now, is that the sub-deployments within the ear are deploying in name order instead of the order specified within application.xml. Our war file is getting deployed first and blowing exceptions as the result of our session and entity components not being deployed first. The problem is that it is trying to deploy the modules in the order destiny.war, entity.jar, session,jar, util.jar.

      Application.xml is as follows...
      <?xml version="1.0" encoding="UTF-8"?>

      <!DOCTYPE application PUBLIC '-//Sun Microsystems, Inc.//DTD J2EE Application 1.2//EN' 'http://java.sun.com/j2ee/dtds/application_1_2.dtd'>

      <display-name>DestinyEJB</display-name>

      util.jar


      entity.jar


      session.jar



      <web-uri>destiny.war</web-uri>
      <context-root>/</context-root>




      After some research into our deployment issue I stumbled into a mention of the issue on jira at http://jira.jboss.com/jira/browse/JBMICROCONT-168. I decided to bring down the trunk and see if this fix corrects our problem. Unfortunately it did not.

      Investigating the code I found the following case seems to be coming into play...

      EarStructure.determineStructure parses application.xml into individual sub-deployments and maps them into ContextInfo instances stored on a list within an instance of StructureMetaDataImpl. The list preserves the order however the relativeOrder field is never set on each ContextInfo.

      AbstractStructureDeployers.determineStructure calls VFSStructureBuilder.populateContext(Deployment, StructureMetadata). This method creates a new DeploymentContext for the ear deployment and then calls populateContext(DeploymentContext, StructureMetaData) to replicate each child ContextInfo into a child DeploymentContext.

      AbstractStructureBuilder.populateContext loops through all the ContextInfo instances created for the subdeployments and invokes createChildDeploymentContext to create each DeploymentContext instance

      VFSStructureBuilder.createChildDeploymentContext and AbstractStructureBuilder.createChildContext both fail to propagate the relativeOrder from ContextInfo to DeploymentContext.

      AbstractStructureBuilder.populateContext is then adding each child DistrictContext to the root context prior to calling applyContextInfo, which fixes up the relativeOrder, for each child resulting in relativeOrder changing on that instance after it is already added to the SortedSet. The results is a very bizarre order when relativeOrder was set to anything but zero in ContextInfo.

      Is there something that I am missing or doing wrong here in regards to allowing JBoss 5 to properly deploy our ear file?

      My plan to move forward with this spike is to fix AbstractStructureBuilder to call applyContextInfo prior to addChild or perhaps fix createchildDeploymentContext to propagate the relativeOrder field as it is defined in the interface. Next I want to modify EarStructure to assign the relativeOrder on each childContext according to the order that they are found in application.xml. This is a temporary workaround for the problem until a fix for this issue can be found or the problem is fixed in the next release or beta cut.