2 Replies Latest reply on Dec 5, 2007 1:33 PM by alesj

    Packed vs. unpacked deployments

    alesj

      We have different behavior on unknown archives vs. their exploded representation - e.g. the deployers testsuite for Not(Unpacked)ClientDeploymentUnitTestCase.

      NotClientDeploymentUnitTestCase (client1-not.ajar) is only recognized by FileStructure, so no further structure details are known.
      Where the NotUnpackedClientDeploymentUnitTestCase (dir unpacked-client1-not.ajar) is recognized by JARStructure and as such eventually pushed to Ejb3ClientDeployer. But this deployer requires only .jar names:

       private String getDeploymentJndiName(DeploymentUnit unit)
       {
       String jndiName;
       String shortName = unit.getSimpleName();
       if(shortName.endsWith(".jar/"))
       jndiName = shortName.substring(0, shortName.length() - 5);
       else if(shortName.endsWith(".jar"))
       jndiName = shortName.substring(0, shortName.length() - 4);
       else
       throw new IllegalStateException("Expected either '.jar' or '.jar/' at the end of " + shortName);
      
       return jndiName;
       }
      


      So, in the first case we get empty DeploymentUnit - no children, where the second one is treated as client-app, but fails.

      This example (excluding the failure) is a general behavior, and I don't think the user expects its deployments to behave differently, whether they are packed or unpacked.

        • 1. Re: Packed vs. unpacked deployments

          I'll repeat, these tests are bogus they need replacing with something that
          tests the new relaxed rules. There's no point trying to fix them
          since they are testing obsolete rules.

          Having said you've identified two problems.

          1) The jar deployer is inconsistent. It doesn't recognise
          the packed client1-not.ajar even though it is a jar and has a META-INF directory.
          However, it does recognise it if it is an unpacked directory.

          Packed:
          2007-12-05 16:41:12,805 TRACE [org.jboss.deployers.vfs.plugins.structure.jar.JARStructure] ... no - not a directory or an archive.

          Unpacked:
          2007-12-05 16:44:00,573 TRACE [org.jboss.deployers.vfs.plugins.structure.jar.JARStructure] ... ok - doesn't look like a jar but it is a top level directory.

          The reason is because the suffix .ajar is not in the recognised list
          of suffixes.

          This is really just an optimization so we don't have to try to open up
          every file to see if it really is a jar because it has a META-INF
          (and catch all the exceptions when it says you cannot findChild on a normal file :-).

          The user can fix it by adding .ajar to the list of recognised suffixes.
          This seems like a stupid example anyway. ;-)

          2) The EJB3ClientDeployer is wrong. It should be fixed such that if the
          client deployment doesn't end with .jar then we take the whole
          deploymentUnit.getSimpleName() as the jndi name.

          • 2. Re: Packed vs. unpacked deployments
            alesj

             

            "adrian@jboss.org" wrote:
            I'll repeat, these tests are bogus they need replacing with something that
            tests the new relaxed rules. There's no point trying to fix them
            since they are testing obsolete rules.

            I agree, but they still reveal some of the things that are wrong - despite the new relaxed rules.
            Helpful for this late stage of beta3 work.
            But as you can see here:
            - http://www.jboss.org/index.html?module=bb&op=viewtopic&t=125157
            this replacement will be done for CR1. ;-)