6 Replies Latest reply on Sep 16, 2006 9:27 AM by Adrian Brock

    AbstractJarHandler.isFile/isDirectory and isArchive

    Scott Stark Master

      I don't agree with the current implementation of the AbstractJarHandler.isFile/isDirectory. Jars are currently marked as always directories and not files. For me the status of of being a directory or file should reflect the underlying vfs context behavior. If a vf is a directory, its not meaningful to obtain its input stream. If its a file it is.

      The notion of a file being a container for other files should either be reflected via another attribute such as hasChildren or implicit with a non-container simply returning an empty child list.

      Also, the isArchive attribute is of little value and certainly not sufficiently general as we also look to the JarUtils.isArchive. A more general contentType attribute and registry for suffix to content types would be more useful.

        • 1. Re: AbstractJarHandler.isFile/isDirectory and isArchive
          Adrian Brock Master

          I'm only interested in the deployer behaviour at the moment
          where an isArchive() or isDirectory() == true
          means it is potentially a subdeployment.

          So they do have some meaning. :-)

          I can see that adding an hasChildren() could be more performant
          in some cases than doing getChildren().isEmpty().

          • 2. Re: AbstractJarHandler.isFile/isDirectory and isArchive
            Scott Stark Master

            Ok, let me review the current usage in the updated deployers. My main concern is that the semantics of the attributes are not clear/consistent and that attributes like isArchive are not meaningful in general and need to be replaced with something.

            • 3. Re: AbstractJarHandler.isFile/isDirectory and isArchive
              Scott Stark Master

              isArchive uses:

              - JARStructure,
              + expects jars to be directories (isDirectory == true).
              + expects directories that are not also archives (unpacked jars) to have a META-INF to be recognized.

              - WebInfLibFilter,
              + accepts isArchive == true as a lib jar
              + file.isDirectory() == true && JarUtils.isArchive(file.getName()) as a lib jar.

              These are too lax and violate the servlet spec as only .jar archives are to be accepted to strictly conform to the spec (JBAS-2538).

              - AbstractDeploymentContext,
              + A non-archive, non-directory root is defaulted to the metadata location if one has not been set.

              other isDirectory uses:
              - WARStructure,
              + expects jars to be directories (isDirectory == true) and further filers on .war or WEB-INF existence.

              The general features we need are:
              - does a file have children
              - does a file have an input stream, and what is its encoding

              Marking a file as a directory via isDirectory could achieve the first. I would like to drop the isArchive attribute and add a contentType instead. A null contentType implies there is no meaningful input stream and one would expect null or an error if it was requested.

              • 4. Re: AbstractJarHandler.isFile/isDirectory and isArchive
                Adrian Brock Master

                 

                "scott.stark@jboss.org" wrote:

                These are too lax and violate the servlet spec as only .jar archives are to be accepted to strictly conform to the spec (JBAS-2538).


                1) It is a prototype for testing, I expect the real structure deployer
                to be provided by JBossWEB
                2) I don't see anything in the servlet spec (SRV.9.5) that excludes
                other sources of classloading.
                3) It would be easily fixed by changing the filter to use the SuffixMatchFilter
                on .jar
                4) Reading the stream to get MIME TYPE for every file is going to slow.

                • 5. Re: AbstractJarHandler.isFile/isDirectory and isArchive
                  Scott Stark Master

                  2) 9.5 only lists jars as the pattern for input. It does not say to explicitly exlude archives of other names but it showed up in support cases as inconsistent behavior with the base tomcat and other containers when we relaxed it.

                  ? The /WEB-INF/lib/*.jar area for Java ARchive files. These files contain servlets,
                  beans, and other utility classes useful to the Web application. The Web application
                  class loader must be able to load classes from any of these archive
                  files.

                  3) This should be something we should externalize to control alternate structure related behaviors.

                  4) It should be an extension of the current JarUtils suffix mapping behavior into a full file type attribute registry. Content type and other attributes like isSar, isLink, etc. could be managed from there.

                  • 6. Re: AbstractJarHandler.isFile/isDirectory and isArchive
                    Adrian Brock Master

                    I found another example where this is creating a problem.

                    When looking at jars, I don't want to deploy their directories.
                    e.g.
                    my.jar/org

                    But I do want to deploy
                    my.jar/my-nested.jar

                    which is also a directory.

                    See CandidateStructureVisitor