Making JARDeployer accepting explicit suffixes

[dimitris]

Currently the JARDeployer is a bit "liberal" on what it accepts:

non .xml or .bsh deployments
non WEB-INF/ or META-INF/ with *.xml content

So it accepts, for example:

- foo.txt, leading to a .Zip open error
- foo.txt/, deploying whatever under that directory

(you can replace .txt with any unknown extension).

Wouldn't be preferable to make this more explicit?

i.e. accept only .jar, .zip, .last deployments, and names without a "dot" (packed/unpacked). The last one to cater for, e.g., deploy-hasingleton/.

(plus the usual WEB-INF, META-INF content checks)

[starksm64]

Really, I view the JARDeployer as a mistake. Its just a mechanism to include content into a classpath dynamically. The problem with this is, its very difficult to control how/in what order that content is included.

In terms of the existing problems you cite, yes, I think we need to add an explicit jar suffix notion of deployments it accepts. I would really like to get rid of the hacky META-INF/*.xml searching currently used to try to determine if a jar is a j2ee jar as well. Without resorting to non-standard jar suffixes (like .classes), I don't see how we can do this though.

Don't we already have the ability to restrict to .jar/.zip based on the last subdeployer suffix handling changes?

[dimitris]

The subdeployer suffix changes affected (a) sorting of suffixes (b) SubDeployerSupport.isDeployable() used when looking for subdeployments.

The default implementation of SubDeployer.accepts() will make a decision based on those suffixes, however, some subdeployers just implement their own accepts (JARDeployer one of them).

I'll try to clean this up a bit.

[dimitris]

Related JIRA issue: http://jira.jboss.com/jira/browse/JBAS-1023