I am not positive, but I think this might be part of the deployable directories support.
--jason On 6 Oct 2002, Matt Goodall wrote: > 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 > > ------------------------------------------------------- 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
