1 Reply Latest reply on Feb 19, 2004 11:19 PM by null null

    issues about deploy ear file with two war files inside

    mike Newbie

      We're experiencing a headache of deploying one ear file with two war files inside. The difference between two war files are just jsp files(two different versions), but each war file need to communicate with same ejb jar file packaged in the ear file, we got deployment errors for this.

      Could anyone kind enough to give some suggestion about how to solve this problem?

        • 1. Re: issues about deploy ear file with two war files inside
          null null Newbie

          it is the exact way in jboss3x cos of the jboss3' new cloass loader arch.
          if one ear include the same class of different versions,the classloader always load the first one.

          for that you should pack the different version of war fils in different ear files

          from jboss doc:
          If you need to deploy multiple versions of an application the default 3.x class loading model would require that each application be deployed in a separate JBoss server. Sometimes this is desirable as you have more control over security and resource monitoring, but it can be difficult to manage multi-ple server instances. An alternative mechanism exists that allows multiple versions of an application to be deployed using EAR based scoping.
          Such an ear creates its own class loader repository that looks first to .the deployment units included in the ear before delegating to the default class loader repository. To enable an ear specific loader repos-itory create a META-INF/jboss-app.xml descriptor as shown in Listing 2-1LISTING 2-1. An example jboss-app.xml descriptor for enabled scoped class loading at the ear level.<jboss-app>
          <loader-repository>some.dot.com:loader=webtest.ear</loader-repository>
          </jboss-app>
          where the value of the loader-repository element is the JMX ObjectName to assign to the repository created for the ear. This must be unique and be a valid JMX ObjectName.