|I thought * did work for classpath archives, but I never tested it. (Did I |take it out? I didnt't think so) I have no problem with having it and |making it work.
You took out the full default (nothing specified) the classpath from DavidM is enough there. |I think the class dependency "nazi" is a good idea, not for initial |deployment but for redeployment: if you take a jar away and redeploy it, |all the depending packages will undeploy to a suspended state and redeploy |when the jar is redeployed. If you have lots (say...50) packages needing |the classes from one jar, this will guarantee that they all get stopped and |restarted with the new classes. Without this I would always shut down the |server to be sure I got all the dependencies updated. Fair and to enable that feature you need the explicit listing, but only if you need it. |This could (I think) be done for mbeans via the MBeanClassLoader. This Yes the way the MBeanClassLoader works is that it attaches an MBean moniker to a class loading request (that is all it does if you remember correctly) so that you can keep track of this explicitely in the SL. MBean -> first class it needs, that class is part of jar. you then have MBean loads from a jar named A Each Jar thus has a Set of MBeans that refer to it(whose initial class is given). A cycling jar -> cycling MBeans without anything specified (QED imho) |would be a mbean .. its own class dependency. Since I haven't tried it |yet, I don't really know how I'd like it. From just thinking about it, I |like the explicitly listed jar dependency better because: first, it |provides notes for those who come after you about what they need to get the |package to deploy. (MBeanClassLoaders might tell you the jar, but only this is where I really don't agree, if you are going to ship * a package * to a client "... those who come after you... " then the thinking is close to the jar thinking and we are really talking about a packaged SAR. If you are talking about ease of use in a cluster of services with central URL then... I think I disagree, everytime you change the list of jars it means updating the xml files with redundant information, just import the jars and be done with it, less to write. Specifying it is OK I guess it is the "mandatory" nature and not allowing for static lib/ext that I disagree with and is too much of a departure. We agree on the dynamicity of the system, we agree that it should be done in the "deploy" with sars, I think we can also automate following the above, |after they find the class. If they can't find the class because you |removed the jar because you thought it was unnecessary, you are stuck). your mbean doesn't boot period, it is better than "I am removing some jars" and my xml file still points to 1000 irrelevant jars (which is the problem with the service.xml file as it is today, that is what you have the file loads all the jars in teh planet when there is no corresponding mbean in it, i mean look at it). |So... I'd say lets make the classpath archives="*" work, and use it for the |base jboss-service.xml (well, maybe. I'd actually rather be specific about yes |which jars it uses.) Then anyone wanting the jar dependency can use it, it is an advanced feature for development, don't expose it for basic admiinstration. |anyone not wanting it can leave out the classpath element from their |my-service.xml and hope for the best. most people will run lib/ext with nothing and be quite happy, 2.4 is a success based on this simple approach, don't make the powerful and complex the norm for simple things. |david jencks I think we got it covered, torches away, amrcf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
