There is a fundamental weakness we carry in our design since 2.0 days the jboss.jcml/service.xml files
we mix in SAR/jcml existence of the bean configuration of the bean classes for the bean If we change the configuration of the service we are requiring that we restart the service. Only changes through 8082/direct JMX won't do that. In short with the jcml stuff (compounded in service.xml) we actually mask one of the big features of JMX, the fact that we can reconfigure an MBean at run-time. If we touch the service.xml, we cycle everyone. The adaptation must do the following: "if new file then create and configure" "if old file just reconfigure (don't undeploy)" "if file removed then undeploy" Class changes need a full redeploy, which is a fundamental problem of the EJB packaging, we should be able to cycle the ejb-jar.xml files (env-entries) dynamically without warranting a redeploy and class loader ditch/class reload. I tell you, one of the biggest problem in J2EE is this artificial packaging madness. I much, much, much prefer the solution where we isolate the classes and monitor these independently cycle the deployments that depend on them but DON'T CYCLE THE XML ONLY DEPLOYMENTS, this is just a "ON THE FLY" reconfiguration. And unless I am so tired I don't see it, I think this solves that... we require xml only deployment with separate classes in case you want fine grained redeploy of SARs and JARs. that was ok, I think I can code that but if there is a brave soul, or a young coder looking for fame and fortune (not you Jason, you already have fame)... marcf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
