On 2001.12.06 12:20:08 -0500 marc fleury wrote: > |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,
If its a comment it will be immediately out of date and wrong. > > |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. Maybe, but only after it's successfully deployed. If the jar is missing, and you don't know what it should be, you're stuck. > > |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. I don't think you've demonstrated this. > > |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 ;-) How do you propose specifying which scope/ application a jar/ear/whatever is part of? All I'm saying is this needs to be specified somewhere, why not at the service element. I want it possible for it to be explicit so you can know what is happening. david > > 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
