Hrm... so what is it there for I wonder? If you remove it does deployment still function?
--jason On 5 Oct 2002, Larry Sanderson wrote: > No. I noticed this deplyment behaviour when I was working on the > deployable directories, and I wanted to remove it then. > > As I recall, nobody else really thought it was a problem, and it was > left in primarily to deply jar files nested within a sar archive. > (Please, correct me if I am wrong here - it was a long time ago) > > However, I did modify the ear deployer to only deploy those archives > mentioned in application.xml. Unless this has been modified since, ear > files are not searched for deployable entities (although jar, sar, rar, > ... archives are). > > -Larry > > On Sat, 2002-10-05 at 18:05, Jason Dillon wrote: > > 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 > > > > > ------------------------------------------------------- > 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 > ------------------------------------------------------- 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
