Yes, but you need something to add plain jars and directories to the classpath.
I believe it should be a policy decision whether it just does it or whether it
looks
for specifc pattern (like does it end with .zip or .jar, etc.)
In the current implementation it just does it (with some file
But that something should be the configuration of another service like the
bootstrap service, or even the URLDeploymentScanner.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3864401#3864401
Reply to the post :
I don't see that the JARDeployer has any reason for existence. If there is
referenced content that has no associated deployer it should not just be added
to some classpath. The configuration of the class and resource paths is an
aspect of some deployment.
View the original post :
I didn't know what was the issue before with .jar vs. .war (I'd think since the
extension is different, there would be no mixup). Can wars come with a .jar
extension??
I had in mind the case of having an ejb-jar, but the ejb deployer is missing,
so jar deployer picks it up...
View the
One thing we really need to be careful with is what happens when JARS are
analyzed.
For instance, EJB3 requires a .ejb3 filename extension because it has to
iterate the entire archive and look at every single class in that archive for
annotations that may be EJB3 annotations. If .jar files
There should be no need for such hardcoding.
The problem with the old jar deployer was
1) There was no ordering of deployers when it did accepts()
2) It was first to recognise it wins
3) The deployers were loaded in an adhoc fashion
With the new deployers, the structural component that analyses
