Comments inlined... > 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.
As an example of why this is useful, let me outline my companies development environment: Our cvs repository is itself an exploded ear file, plus an src directory, the ant build scripts, minus any compiled code. We have 3 war archives, and a single ejb-jar file. The ant scripts simply compile the appropriate source files to the propper directories (WEB-INF/classes, the ejb-jar, etc...). In development, this directory is directly deployed by JBoss. Another ant task builds the compressed archives for production (stripping out the src, build scripts, etc...), but development is done directly within the deployed application. This has improved the speed of developing / redeploying / testing dramatically. (Perhaps this gives you an idea why I have been so hung up on exploded deployment ;-) ) To remove an archive from our deployment would meen removing an entire CVS directory. > 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'm not suggesting getting rid of this. In fact, I like the convenience of not specifying Class-Path entries all over my META-INF files, and I think the spec should allow shared classpaths. But, it should be recognized that any user who makes use of this feature may need to make some configuration changes if they switch app servers. > I have never understood what the purpose of the classpath entries inside an > ear really was, nor the problems with deploying "everything in sight". It just takes control away from the user, though it could be argued that the user doesn't have to include things she does not want deployed. > 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. No, my problem is with an app-server making assumptions that a user may not want. Further, the user has no way of overriding these assumptions. Put simply: JBoss is violating the J2EE specification here. Consider the following, legal ear archive: 2 nested war files, who use the same web-context, but only the first specified in application.xml. JBoss will not be able to deploy this because of the context root conflict, however a compliant app server would. > 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. Yeah, a bit silly, but IMO better than what we have now. I would prefer a documented convention stating what directory within a sar archive nested deployments should live. The same goes for rar files. (Kind of like war files - they have the WEB-INF/lib and WEB-INF/classes directories). > Did you change the behavior of deploying sars or are all of them still deployed? No - I got yelled at when I tried :-) Everything works exactly as it did, except the EARDeployer, and I will submit a patch to revert this functionality if required. > Anyway for ears I guess looking at application.xml should be ok since the > user has to include it anyway. Sorry for rambling, and I hope I'm not coming off too strongly. Thanks for listening! -Larry _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
