AbstractJarHandler.isFile/isDirectory and isArchive

[starksm64]

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.

[adrian.brock]

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().

[starksm64]

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.

[starksm64]

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.

[adrian.brock]

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.

[starksm64]

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.

[adrian.brock]

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