I agree that there should be a single definitive user-specified list of what should be deployed, but I think it belongs in the ant build file that constructs what gets deployed. To me, it is more sloppy to include stuff in your package that you don't want deployed than to deploy everything in a package.
The original motivation behind the unified classloader was to make it practical to work on giant applications that are manageable only if they are packed into multiple ears, but which need to refer to each other's classes, and which need to be independently redeployable. A tree-based classloader scheme isn't going to work for this. I have never understood what the purpose of the classpath entries inside an ear really was, nor the problems with deploying "everything in sight". To me, your problem seems like it is based on your convenience and way of working rather than an intrinsic problem with "everything". I could be missing something, please let me know what. Also, we still need to deploy every .sar inside a j2ee package unless we want to add a jboss-specific dd to every package indicating which sars get deployed. I think adding a dd just for this is silly. Did you change the behavior of deploying sars or are all of them still deployed? Anyway for ears I guess looking at application.xml should be ok since the user has to include it anyway. Thanks david jencks On 2002.04.16 18:17:39 -0400 lsanders wrote: > 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 > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
