6 Replies Latest reply on Jan 31, 2005 11:36 AM by Scott Stark


    Dimitris Andreadis Master

      I'm trying to re-write the JARDeployer to the new framework, where AspectDeployers will be first asked to "analyze" a deployment, i.e. do the structure analysis.

      This somewhat resembles the old "accepts" functionality, so I'm wondering if I should try to replicate the old behaviour, which is to make sure there is no WEB-INF, or a META-INF which contains any .xml files.

      I guess this still need to be done, since the ejb-jar deployer may not be registered.

        • 1. Re: JARDeployer
          Bill Burke Master

          One thing we really need to be careful with is what happens when JARS are analyzed.

          For instance, EJB3 requires a ".ejb3" filename extension because it has to iterate the entire archive and look at every single class in that archive for annotations that may be EJB3 annotations. If ".jar" files were accepted as well, it would have slowed down the deploy process significantly.

          • 2. Re: JARDeployer
            Adrian Brock Master

            There should be no need for such hardcoding.

            The problem with the old jar deployer was
            1) There was no ordering of deployers when it did accepts()
            2) It was first to recognise it wins
            3) The deployers were loaded in an adhoc fashion

            With the new deployers, the structural component that analyses the structure
            will be ordered (still with first to recognise it wins).
            Also, the structural deployers will be amongst the first things to be deployed.

            i.e. we don't have to worry about the jar deployer stealing a war deployment
            inside a sar because its sar was processed before the tomcat sar.

            The only way it is not going to work is if you don't have a war deployer.
            In that case, the jar deployer will be the only one that recognises the deployment.

            • 3. Re: JARDeployer
              Dimitris Andreadis Master

              I didn't know what was the issue before with .jar vs. .war (I'd think since the extension is different, there would be no mixup). Can wars come with a .jar extension??

              I had in mind the case of having an ejb-jar, but the ejb deployer is missing, so jar deployer picks it up...

              • 4. Re: JARDeployer
                Scott Stark Master

                I don't see that the JARDeployer has any reason for existence. If there is referenced content that has no associated deployer it should not just be added to some classpath. The configuration of the class and resource paths is an aspect of some deployment.

                • 5. Re: JARDeployer
                  Adrian Brock Master

                  Yes, but you need something to add plain jars and directories to the classpath.

                  I believe it should be a policy decision whether it just does it or whether it looks
                  for specifc pattern (like does it end with .zip or .jar, etc.)

                  In the current implementation it just does it (with some file patterns excluded by
                  the deployment scanner not the deployer framework).

                  • 6. Re: JARDeployer
                    Scott Stark Master

                    But that something should be the configuration of another service like the bootstrap service, or even the URLDeploymentScanner.