Why not make more usage of notifications here. Such that jetty could send a notificatioin when it needs to be redeployed due to config change. It may know best for some/most config changes.
--jason marc fleury wrote: > >|-----Original Message----- >|From: [EMAIL PROTECTED] >|[mailto:[EMAIL PROTECTED]]On Behalf Of Jason >|Dillon >|Sent: Tuesday, February 26, 2002 12:41 AM >|To: marc fleury >|Cc: Jboss-Development@Lists. Sourceforge. Net >|Subject: Re: [JBoss-dev] notes on configuration >| >| >|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... > >That and the fact that if you need to change the configuration without >shutting down the service you can't do that. a touch to jetty-plugin.sar >will restart jetty. > >In some cases I guess that is good (the port change) in some others... the >class needs to pick up the changes and we need a callback in there, somehow, >somewhere, > >this part needs more thinking > >marcf >| >|--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 > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
