The last time I looked at the .ear deployer I thought it was only deploying modules explictly referenced in application.xml and jboss-app.xml, and packages from manifest classpaths. Anything else is a mistake. Lots of people have messed with this code and it keeps breaking. I suggest if you want to put your $0.02 in the most valuable place to start would be with some unit tests so we can find out when someone breaks it again.
Fixing it once is easy. Noticing when it is broken again is not. The other deployers usually deploy everything in sight, which is usually correct behavior. thanks david jencks On 2002.10.06 05:43:15 -0400 Matt Goodall wrote: > See below ... > > On Sun, 2002-10-06 at 03:14, Jason Dillon wrote: > > Hrm... so what is it there for I wonder? If you remove it does > deployment > > still function? > > When I realised what isDeployable() was for I changed it to > unconditionally return false to see what the effect would be. On > startup, deployment of some of the .rar and .sar files failed. I think > they are fixed by adding the dependent JARs that were automatically > deployed to the manifest classpath. > > EAR files would not deploy since modules are only deployed when the > modules file has passed the isDeployable() test. It *does* work when the > EAR file is unpacked as a directory though. > > > > > --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) > > As mentioned above. I think the SARs can be fixed by correcting the > manifest classpath. > > > > > > > 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). > > Hmm ok, I'll take a look at a newer version as I've only really played > with 3.0.2 so far. Do you remember what release your change first > appeared in? > > I hope to have a better look this evening. I'll report back with more > detailed findings then hopefully. > > Thanks for the info so far. > > Cheers, Matt > > > > > > > -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 > > > -- > Matt Goodall, Technical Director > Pollenation Internet Ltd, http://www.pollenation.net > e: [EMAIL PROTECTED] > t: 0113 2252500 > m: 07811 278951 > > > > ------------------------------------------------------- > 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
