3 Replies Latest reply on Apr 4, 2007 12:58 PM by dimitris

    Nested deployments, duplicate names and jsr77

    dimitris
    dimitris Apr 27, 2006 1:20 PM

      I'm looking into http://jira.jboss.com/jira/browse/JBAS-1305
      (see also the discussion at http://www.jboss.com/index.html?module=bb&op=viewtopic&t=58955)

      I undestand there are 2 notions that currently don't map well to jsr77.

      One is 'location'. The following deployments collide and only one gets registered in the jsr77 tree because we don't consider the path to a deployment having an impact on the ServiceModule ObjectName, at all.

      deploy/test-service.xml
      deploy/management/test-service.xml
      or
      file:/..../conf/jboss-service.xml
      http://bla/bla/jboss-service.xml
      or
      deploy/a.sar/another.sar
      deploy/a.sar/somedir/another.sar

      My initial idea to solve this is having the deployment url, part of the ObjectName:
      jboss.management.local:J2EEServer=Local,j2eeType=ServiceModule,name=iiop-service.xml,url=file:/X:/cvs/jboss-public/jboss-4.0/build/output/jboss-4.0.4.GA/server/all/deploy/iiop-service.xml

      or subtract the path to the config dir and use this as the 'name':
      jboss.management.local:J2EEServer=Local,j2eeType=ServiceModule,name=deploy/iiop-service.xml

      (this will probably look better like conf/jboss-service.xml, farm/xxx.sar)

      • 19883 Views
      • Tags:
        • 1. Re: Nested deployments, duplicate names and jsr77
          dimitris
          dimitris Apr 27, 2006 1:43 PM (in response to dimitris)

          The other notion is 'nesting'. I understand jsr77 indicates a single level of nesting of .war,.jar,.rar inside an .ear and that's all (or the modules can appear outside of an .ear but still we mark this with J2EEApplication=null)

          In jboss we have almost arbitrary nesting, and I find it very hard to express this with jsr77.

          We do allow a module inside a .sar, declaring the .sar as the enclosing J2EEApplication, but I'm not sure if this is a bug or a feature. (In this case I would still assume J2EEApplication should be null).

          Any idea how to deal with this?




            • Actions
          • 2. Re: Nested deployments, duplicate names and jsr77
            mclaugs
            mclaugs Jul 13, 2006 3:47 PM (in response to dimitris)

            The Nesting feature of JBoss has always made the jsr77 expression of some deployment very hard to think about. Since we have defined a j2eeType of ServiceModule and Looking at the spec I would suggest this as a possible approach.

            Lets assume you have this deployment.
            fooSar.sar containing a fooEar.ear containing a fooWar.war

            jboss.management.local:J2EEServer=Local,j2eeType=ServiceModule,Name=fooSar.sar
            for the SAR

            jboss.management.local:J2EEServer=Local,j2eeType=J2EEApplication,Name=fooEar.ear
            for the EAR

            jboss.management.local:J2EEServer=Local,J2EEApplication=fooEar.ear,j2eeType=WebApplication,ServiceModule=fooSar.sar,Name=fooWar.war
            for the WAR

            What I am thinking is that we do not treat a SAR like an application because a SAR archive can contain an application but it might also contain just a web archive or the other types as well, so I think having the J2EEApplication= key for the SAR can lead to a lot of confusion.

              • Actions
            • 3. Re: Nested deployments, duplicate names and jsr77
              dimitris
              dimitris Apr 4, 2007 12:58 PM (in response to dimitris)

              I came to the conclusion that using J2EEApplication for wrapping non-ear modules is a bug. E.g. a war inside a sar that describes the parent .sar as being a J2EEApplication is not correct.

              So I've removed this wrapping here: http://jira.jboss.com/jira/browse/JBAS-2026

              A J2EEApplication with a non-null value really refers to an .ear. The TCK tests seem to agree with that.

              Based on this, the org.jboss.test.jmx.test.JarInSarJSR77UnitTestCase doesn't make sense, so I'll disable it. This is in Branch_4_2 and HEAD.

              We need to rethink our jsr77 view of location and scoping and the discussion in this thread is a good start.

                • Actions