-
1. Re: AbstractJarHandler.isFile/isDirectory and isArchive
adrian.brock Sep 11, 2006 7:45 AM (in response to starksm64)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
starksm64 Sep 11, 2006 11:47 AM (in response to 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.
-
3. Re: AbstractJarHandler.isFile/isDirectory and isArchive
starksm64 Sep 13, 2006 11:07 PM (in response to 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. -
4. Re: AbstractJarHandler.isFile/isDirectory and isArchive
adrian.brock Sep 14, 2006 6:11 AM (in response to starksm64)"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
starksm64 Sep 14, 2006 12:37 PM (in response to 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. -
6. Re: AbstractJarHandler.isFile/isDirectory and isArchive
adrian.brock Sep 16, 2006 9:27 AM (in response to starksm64)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