The J2EE 1.3 spec (8.1.1.2) goes into several examples of how nested ejb-jar's and war's should share classes, and it is all based on Class-Path Manifest entries. Technically, per spec, nested archives should never share Classpath's unless there is a Class-Path META-INF entry (i.e. web archives should not, by default, be able to see ejb-jar files within the same ear archive).
JBoss takes a more conservative approach, and gives each deployment access to each other's information. This sacrifices archive interoperability for ease of use. The patch I put forward took a middle of the road approach - only those archives specified in application.xml are deployed, but they can all access each others data without Class-Path entries. I like being able to limit the deployments by commenting out portions of my application.xml. I use this all the time when testing within an exploded archive - it allows me to isolate one portion of development. Personally, I don't like the "deploy everything" philosophy. It just seems sloppy to me. I don't like it within sars, rars, or anything else. There should be a single, definitive, user-specified list of exactly what should be deployed, and when. The idea of: "search through every single file within an archive, and check to see if it is deployable" leads to hacks like the one currently in MainDeployer: "... unless it is a war file, then let the war deployer figure it out". -Larry > Hmmm, I thought that might be what the spec wanted, but when I read it I > decided it was consistent with "put everything in sight on the classpath" > since then everything they mention is definitely on the classpath. Maybe > we need a configuration switch? What problems come from "everything in > sight?" If you have server-specific jars, you'd need to change the ear > anyway to change which are deployed, so why not take out the packages you > don't want deployed? > > Any other thoughts? > > david jencks > > On 2002.04.16 17:01:13 -0400 lsanders wrote: > > It was my patch that changed this. I changed the EARDeployer to only > > deploy > > those applications listed in an application.xml file (I believe that this > > was another bug on sourceforge?). The struts.jar should only be included > > on > > the classpath if it is an application in the application.xml file, if it > > is > > in the WEB-INF/lib, or if it is listed in a Class-Path entry in the > > META-INF > > file. I believe this is how the spec defines things. Is this right? > > > > -Larry > > > > > > > Bugs item #544848, was opened at 2002-04-16 15:19 > > > You can respond by visiting: > > > > > http://sourceforge.net/tracker/?func=detail&atid=376685&aid=544848&group_id= > > 22866 > > > > > > Category: None > > > Group: v3.0 Rabbit Hole > > > Status: Open > > > Resolution: None > > > Priority: 5 > > > Submitted By: Peter Luttrell (objec) > > > Assigned to: Nobody/Anonymous (nobody) > > > Summary: EAR Deployments don't work the same > > > > > > Initial Comment: > > > with jboss3.0rc1 with tomcat4.0.3 if I create an ear > > > file such as this: > > > > > > one.war > > > two.war > > > struts.jar > > > META-INF/application.xml > > > > > > where one.war and two.war depend on structs.jar, jboss > > > blows up when one.war attempts to preload the structs > > > servlet. > > > > > > with jboss3.0b1 with tomcat4.0.3, the above > > > configuration worked perfectly. > > > > > > was this intentionally changed? or is it a bug? > > > > > > if i use the "Class-Path" entry to specify the > > > structs.jar file in the manifest file for both one.war > > > and two.war it also works. I've only tested this on > > > rc1. > > > > > > ---------------------------------------------------------------------- > > > > > > You can respond by visiting: > > > > > http://sourceforge.net/tracker/?func=detail&atid=376685&aid=544848&group_id= > > 22866 > > > > > > _______________________________________________ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > _______________________________________________ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
