Does this mean that we will always have seperate .xml? Packaged is nice for classes and file systems, but when the config is inside too, then it is a pain to configure. Take jetty-plugin.sar. If a user wants to change ports or add/remove listeners then need to unjar/edit/rejar... kinda painful.
If your not talking about this at all then just ignore... --jason marc fleury wrote: >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 > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
