My plans are way ahead of my time to implement any of this... some comments.
1. Don't confuse the utterly messed up and misleading current use of the classpath element and service.xml packaging with its capabilities and usefulness. There are 2 problems with the current packaging IMHO: a.the base jboss-service.jar includes every jar under the sun that I didn't explicitly remove, rather than the ones actually used in the base package, and b. No one has actually divided up the functionality of jboss into reasonable independently deployable packages. (maybe this would be an actually useful project for that debian packaging guy...???) For instance, there could be a castor-service.xml referencing the castor.jar. Loading castor classes if you aren't going to use them is silly. IMHO having the classpath element is very useful in showing what jars you actually need for certain functionality. The MBeanClassLoader solution AFAIK will not provide this documentation. I think being able to document where the classes you are using come from beats autodeploying everything in sight and hoping the classes you need are present. 2. There is definitely a problem with relying on the autodeployer: although everything may all start in the right order due to automatically computed dependencies, it doesn't look that way and is confusing. My proposed solution for this is a deployment script facility, basically a list,"deploy this, now this, now this,..." This should make it easy to construct a customized jboss by deploying the appropriate packages, including the ears etc for your application. I think this may be an easier to use and more flexible solution than the run level idea. 3. Scoping... I would like every set of deployment descriptors to be converted to a single jboss-service.xml file that explictly includes security domain/virtual host/classloader information. I think this info should be in attributes in the server element. So, for instance, for an ejb module, I would combine ejb-jar.xml, jaws.xml, and jbosscmp-jdbc.xml into a single jboss-service.xml where the module and each ejb is represented by an mbean config representing the meta data for that object. This combination is pretty easy to do with xslt, and would IMHO greatly simplify metadata loading and provide alternative "single dd" deployment descriptors. It would also provide a place to put the scoping info about which classloader to use. ---- View: http://jboss.org/forums/thread.jsp?forum=66&thread=4977 _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
