|-----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

Reply via email to