|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
including "jars" in classpath as code requirement is the initial problem, remove that. |b. No one has actually divided up the functionality of jboss into |reasonable independently deployable packages. (maybe this would be we shouldn't... the boot should be one file see my previous email |IMHO having the classpath element is very useful in showing what |jars you actually need for certain functionality. The no not as is, as is it is a stepback. put that in a comment, |MBeanClassLoader solution AFAIK will not provide this |documentation. I think being able to document where the classes it might, at least the coarse grained. MBCL-> what class-> what jar I have to look at it again to make sure. |you are using come from beats autodeploying everything in sight |and hoping the classes you need are present. no it doesn't, clearly doesn't. |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 which is what the one file achieves implictely. |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. that could very well be. |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 There we totaly agree. I think that would be very good. Although we will find that specifying the services for all the beans will be silly, combining the other files would be very good, packaging madness in the spec |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. I will shoot you in the head if you do this, "give the administrator input in the class loader". You are a bit like rickard, you are a wizard in code no doubt about it and in some "ease of use" instance you are a bit of a moron :) (no offense really, I called you a rickard ;-) Ok I think I got a pretty good handle on your work, sit back bite some rope and let me refactor this, "Victor, nettoyeur" -- Nikita ca.1988 -- marcf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
