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... --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
RE: [JBoss-dev] notes on configuration
|-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
Re: [JBoss-dev] notes on configuration
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
RE: [JBoss-dev] notes on configuration
|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. correct, jetty knows best what requires a restart and what does not, all this handling should be done inside the MBean. we will get there, see, you are talking now :) marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: [JBoss-dev] notes on configuration
If we used ModelMBeans, the Attribute's desriptor could include a field runtimeConfigurable. The service deployer can then determine if a redeploy is required. Regards, Adrian |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. correct, jetty knows best what requires a restart and what does not, all this handling should be done inside the MBean. we will get there, see, you are talking now :) marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-dev lopment _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=9657 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: [JBoss-dev] notes on configuration
On 2002.02.26 08:57:05 -0500 Adrian Brock wrote: If we used ModelMBeans, the Attribute's desriptor could include a field runtimeConfigurable. The service deployer can then determine if a redeploy is required. Regards, Adrian Yes. Also there is the choice of -change attribute value while mbean is started -stop, change attribute value, start -stop, destroy, create(with new values), start -stop, destroy, remove, install, create(with new valuew), start These could all be specified w/model mbean attributes. I think this whole question is also getting into how will we use mbean persistence? and just what is that replacement for jboss-auto.jcml? david jencks |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. correct, jetty knows best what requires a restart and what does not, all this handling should be done inside the MBean. we will get there, see, you are talking now :) marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-dev lopment _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=9657 ___ 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
RE: RE: [JBoss-dev] notes on configuration
|If we used ModelMBeans, the Attribute's desriptor |could include a field runtimeConfigurable. |The service deployer can then determine if a redeploy |is required. ohhh so pretty we will use modelMBeans very soon, if we could get you get to put something out marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: RE: [JBoss-dev] notes on configuration
3 of 4 imho |Yes. Also there is the choice of |-change attribute value while mbean is started yes |-stop, change attribute value, start yes |-stop, destroy, create(with new values), start no (use below) |-stop, destroy, remove, install, create(with new valuew), start yes |These could all be specified w/model mbean attributes. yes |I think this whole question is also getting into how will we use mbean |persistence? and just what is that replacement for jboss-auto.jcml? right, you got your JMX book? If only I could get the flacid fin to get out of his hole marcf | |david jencks | | |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. | | correct, jetty knows best what requires a restart and | what does not, all | this handling should be done inside the MBean. | | we will get there, see, you are talking now :) | | marcf | | | ___ | Jboss-development mailing list | [EMAIL PROTECTED] | https://lists.sourceforge.net/lists/listinfo/jboss-dev | lopment | | | | _ | View thread online: http://main.jboss.org/thread.jsp?forum=66thread=9657 | | ___ | 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
Re: RE: [JBoss-dev] notes on configuration
On 2002.02.26 13:38:37 -0500 marc fleury wrote: 3 of 4 imho |Yes. Also there is the choice of |-change attribute value while mbean is started yes |-stop, change attribute value, start yes |-stop, destroy, create(with new values), start no (use below) I agree, just trying to be complete. |-stop, destroy, remove, install, create(with new valuew), start yes |These could all be specified w/model mbean attributes. yes |I think this whole question is also getting into how will we use mbean |persistence? and just what is that replacement for jboss-auto.jcml? right, you got your JMX book? yup. If only I could get the flacid fin to get out of his hole Right now I'm working on xdoclet tags xmbean xml (I want to get this in xdoclet 1.1.2, this weekend) and xmbean modifications to go with improved xmbean dtd. Then we can start converting all our mbeans to xmbean. Maybe I should include a hard coded named descriptor tag like update-service-level (STARTED|STOPPED|REMOVED) (otherwise we would have a descriptor name=update-service-level value=STARTED attribute) Suggestions for the names appreciated;-) I'm thinking in the back of my mind that there must be some way to use the xmbean xml and the *service.xml in combination more efficiently, but I don't know what it is yet. david jencks marcf | |david jencks | | |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. | | correct, jetty knows best what requires a restart and | what does not, all | this handling should be done inside the MBean. | | we will get there, see, you are talking now :) | | marcf | | | ___ | Jboss-development mailing list | [EMAIL PROTECTED] | https://lists.sourceforge.net/lists/listinfo/jboss-dev | lopment | | | | _ | View thread online: http://main.jboss.org/thread.jsp?forum=66thread=9657 | | ___ | 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 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: RE: [JBoss-dev] notes on configuration
David,
bringing you to the training was the best thing ever,
since then you have become quite the man ...
|Right now I'm working on xdoclet tags xmbean xml (I want to get this in
|xdoclet 1.1.2, this weekend) and xmbean modifications to go with improved
|xmbean dtd. Then we can start converting all our mbeans to xmbean. Maybe
|I should include a hard coded named descriptor tag like
|
|update-service-level (STARTED|STOPPED|REMOVED)
|
|(otherwise we would have a
|descriptor name=update-service-level value=STARTED
|attribute)
|
|Suggestions for the names appreciated;-)
This is unclear though, are you saying what should the service controller
do on a change?
if that is the question then the values should be
state-action-on-update {KEEP-RUNNING| RE-START | RE-INSTANCIATE}
|I'm thinking in the back of my mind that there must be some way to use the
|xmbean xml and the *service.xml in combination more efficiently, but I
|don't know what it is yet.
remember the law of the 2 ideas, only when you know clearly what it is and
what it does do we want to hear about it :)
marcf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: RE: [JBoss-dev] notes on configuration
|This is unclear though, are you saying what should the service controller
|do on a change?
|if that is the question then the values should be
|
|state-action-on-update {KEEP-RUNNING| RE-START | RE-INSTANCIATE}
hey supposedly JSR 111 deals with this? does it? the HP guys have been
talking about it like it was something special so maybe we could find out?
marcf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] notes on configuration
Again, why not use a notification here? If an attrib is exposed, then we have to poll. If the service sends a note, then we just sit until we get one... Or am I missing the point? --jason marc fleury wrote: |If we used ModelMBeans, the Attribute's desriptor |could include a field runtimeConfigurable. |The service deployer can then determine if a redeploy |is required. ohhh so pretty we will use modelMBeans very soon, if we could get you get to put something out 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
Re: [JBoss-dev] notes on configuration
Hi I didn't follow the discussion but when you want to wait for an attribute to be changed you can use the Monitoring Service which sends you also a Notification but you can add this outside the MBean. Andy - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: marc fleury [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, February 26, 2002 3:40 PM Subject: Re: [JBoss-dev] notes on configuration Again, why not use a notification here? If an attrib is exposed, then we have to poll. If the service sends a note, then we just sit until we get one... Or am I missing the point? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] notes on configuration
The model mbean descriptors can include information per-attribute about what level of service shutdown is necessary. No need to bother the service itself. See some later messages. david jencks On 2002.02.26 18:40:24 -0500 Jason Dillon wrote: Again, why not use a notification here? If an attrib is exposed, then we have to poll. If the service sends a note, then we just sit until we get one... Or am I missing the point? --jason marc fleury wrote: |If we used ModelMBeans, the Attribute's desriptor |could include a field runtimeConfigurable. |The service deployer can then determine if a redeploy |is required. ohhh so pretty we will use modelMBeans very soon, if we could get you get to put something out 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
Re: RE: [JBoss-dev] notes on configuration
On 2002.02.26 15:17:00 -0500 marc fleury wrote:
|This is unclear though, are you saying what should the service
controller
|do on a change?
|if that is the question then the values should be
|
|state-action-on-update {KEEP-RUNNING| RE-START | RE-INSTANCIATE}
hey supposedly JSR 111 deals with this? does it? the HP guys have been
talking about it like it was something special so maybe we could find
out?
Do you have any idea how to find out? I can't find any publicly available
info. I did notice a very large number of no votes on it, all of which
said this is too vague and preliminary. Do some more research
david jencks
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
RE: RE: [JBoss-dev] notes on configuration
|Do you have any idea how to find out? I can't find any publicly available |info. I did notice a very large number of no votes on it, all of which |said this is too vague and preliminary. Do some more research oh no yet another JSR that will end up ripping JBoss and claiming official status. Just blaze forward my friend, just go. marcf Working for eternity -- McDonald's motto-- | |david jencks | | 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
[JBoss-dev] notes on configuration
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
