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?
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.