The issue with 589808 is that MainDeployer.parseManifestLibraries treats the jars in the manifest as arbitrary deployment candidates. These should only be treated as jars to be handled by the JarDeployer. This is the only change required to fix this issue.
Blanket removal of isDeployable() makes no sense as the deployment architecture is extensible. Be more specific in the changes you are looking to make. Ears need to deploy modules referenced by the application.xml and jboss-app.xml descriptor as we allow sars to be deployed inside of an ear. Since support for arbitrary deployment can be added, there needs to be justification as to why only module referenced by the application.xml and jboss-app.xml should be deployed. If you don't want it deployed don't stick in the ear is another valid point of view. xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx ----- Original Message ----- From: "Matt Goodall" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, October 05, 2002 5:42 PM Subject: [JBoss-dev] Over zealous deployers > Hi, > > I'm new (about 1.5 hours altogether) to the JBoss source code so forgive > me, and correct me, if I've got some of this wrong ... > > When I deploy an EAR the deployer deploys that EAR and *all* files > contained inside if they are one of the types listed in > SubDeployerSupport.isDeployable(). It actually calls isDeployable() for > *every* file in the EAR including files like META-INF/MANIFEST.MF and > META-INF/application.xml! I've also seen isDeployable() get called for > every .class in a JAR. > > I found this problem on 3.0.2 but it still seems to be there in the > latest CVS code. I'm pretty sure this is bug #589808; it's also been > discussed in the web forums. > > I'm not sure why the deployer(s) work like this. Can someone explain it? > Is there a good reason for it that I have not seen yet? > > (Another related issue is that EARDeployer behaves differently depending > on whether the EAR is an archive or an unpacked directory.) > > My understanding is that only modules, i.e. the EAR and the modules > listed in application.xml in this case, should be deployed and only > dependent JARs listed in the manifest classpath should be loaded at all. > > I would like to fix this as it's stopping me moving up to 3.x. I think > the following is necessary: > > 1. Look at the other deployers to see what they're doing. > 2. Remove isDeployable() and any uses of it. > 3. Fix any of the standard SAR/RAR/etc that haven't got a correct > manifest classpath. > 4. Fix the EARDeployer to deploy just the application.xml modules. > > I suspect that this change will improve deployment and startup time > slightly (no directory scans and string comparisons) but, more > importantly, it will make JBoss behave correctly. > > One of the big problems with fixing this is that it will break > applications in 3.x that have not been packaged correctly. For that > reason, it may be best to introduce the fix based on some configuration > property and leave the current behaviour as default. > > Any comments before I start on this would be most welcome. > > Cheers, Matt > > -- > Matt Goodall > Pollenation Internet Ltd, http://www.pollenation.net > e: [EMAIL PROTECTED] ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
