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
