3 Replies Latest reply on Mar 19, 2008 2:02 PM by Scott Stark

    Fixing the WarClassLoaderDeployer

    Adrian Brock Master

      The current way the WarClassLoaderDeployer works is all of the place. :-)

      INCLUDE WEB-INF

      I thought the requirement was to include the root of the war
      since that is what the old UCL did?
      Anyway this should be in the structure deployer not the classloader deployer.
      Same goes for some of the other flags, is "acceptNonWarDirs" still used?

      COPYING TO TEMP

      Again this should be in the structure deployer. The VirtualFiles is adds
      should be the temp ones.

      ALT-DD

      This doesn't look like it is handled properly in the new deployers?
      Shouldn't this be handled in the metadata parsing?

      PLAYING AROUND WITH METADATA

      The merging and altering of metadata shouldn't be left to the "RealDeployer"
      i.e. AbstractWarDeployer. Doing so means it cannot be overridden
      by some other policy.

      What's most annoying is that bad examples like this are being used
      by the other people as the correct way to do things :-)

        • 1. Re: Fixing the WarClassLoaderDeployer
          Carlo de Wolf Master

           

          "adrian@jboss.org" wrote:
          INCLUDE WEB-INF

          I thought the requirement was to include the root of the war
          since that is what the old UCL did?
          Anyway this should be in the structure deployer not the classloader deployer.
          Same goes for some of the other flags, is "acceptNonWarDirs" still used?

          This sounds like something I requested. Any class that is in the root of a war should not be considered as an EJB 3 bean candidate.

          • 2. Re: Fixing the WarClassLoaderDeployer
            Scott Stark Master

            No, that is the Ejb3Deployer.scanWars that controlls that behavior.

            acceptNonWarDirs is obsolete in the new deployers as the war structure is based on the existence of a WEB-INF/web.xml regardless of whether the parent has a .war.

            • 3. Re: Fixing the WarClassLoaderDeployer
              Scott Stark Master

               

              "adrian@jboss.org" wrote:
              The current way the WarClassLoaderDeployer works is all over the place. :-)

              INCLUDE WEB-INF

              I thought the requirement was to include the root of the war
              since that is what the old UCL did?
              Anyway this should be in the structure deployer not the classloader deployer.

              No, this is the workaround for webservices packaging expectations of being able to load resources from the WEB-INF dir. Should be in WARStructure, but its isolated to the jbossas codebase for now.

              "adrian@jboss.org" wrote:

              COPYING TO TEMP

              Again this should be in the structure deployer. The VirtualFiles is adds
              should be the temp ones.

              this should not be needed.

              "adrian@jboss.org" wrote:

              ALT-DD

              This doesn't look like it is handled properly in the new deployers?
              Shouldn't this be handled in the metadata parsing?

              Yes, we are not handling this. Its a bit awkward as you would first have to scan the base descriptor for the alt path and then parse that file. Doesn't neatly fit into the current metadata parsing abstractions.

              These issues are spread across the various war deployers, not just the WarClassLoaderDeployer. You wrote "is all of the place", but meant is all over the place. The war deployers and tomcat embedding code still await a major overhaul.