What you have detailed looks like a good solution to me. In the end, I just want to make the admins happy.
BTW, I believe we do have an orthogonal problem with MBeans being implemented incorrectly. We have a ton of beans that simply don't do what they say they will. I see no reason why an bean that has a port setting can't remove the existing socket and create a new one.
Hey I just thought of something. We implement our own MBean spec... XMBean right? We could have additional state for attributes that says these attributes are only writable while the bean is stopped. Then in the MBeanMetaData getter we check the state and only return the attributes that are editable at that state. This will work since we don't cache MBean MetaData. What do you think?
I also think we should extend the MBeanMetaData objects to support jboss specific stuff like the above attributes. Then we can display these in our consoles.
-dain
On Friday, January 24, 2003, at 08:00 PM, David Jencks wrote:
Yes, that's the idea. It goes like this when jboss instantiates an mbean from a *-service.xml file:
(create mbean)
state: instantiated
(set attributes)
state: configured
(call create method) ~(call destroy method)
state: created
(call start method) ~(call stop method)
state: started
where the ~() methods go backwards from the other methods.
Personally I think the create and destroy methods could be safely removed as useless, but I lost the argument the last time we had it.
Anyway, to see why this might be useful, lets hypothesize an mbean that takes a long time to create (just as an object) and has a socket. You want to set the ip address and port on the socket as separate attributes on the mbean. Well, creating a new socket whenever you change the host or port is not very satisfactory since there's a good chance you want to change both. Changing just one will leave the mbean in a unusable state, pointing to the right host but wrong port. You don't want to replace the mbean object with a new one because it takes a long time to create. So , the service lifecycle lets you:
stop (mbean is now theoretically unusable: this should be implemented in an interceptor, but is not right now)(this would discard the old socket)
change both attributes (while the mbean is "off")
start (this creates a new socket with all correct parameters)(mbean is now usable again).
There are also mbean dependencies, whereby if your mbean has an ObjectName valued attribute, and you tell jboss, your mbean can't start until the referenced mbean has started. This is used to get most of jboss to start in an order that will work.
The code that does this is now spread over ServiceController, ServiceConfigurator, and ServiceContext with a little bit of ServiceCreator thrown in.
Hope this clarifies what is going on a little bit. There are no attributes that have no effect... its just that say a port number may not get into the socket until you cycle the mbean, in case you want to change the host also.
I also mentioned earlier that there's an xmbean attribute indicating what the effect on service lifecycle should be of changing an attribute value. The idea behind this (unimplemented) is that if you set several attributes at once, jboss should be able to cycle the lifecycle state for you.
david jencks
On Friday, January 24, 2003, at 05:07 PM, Matt Munz wrote:
David,
We are miscommunicating.
>In all the mbeans I have written and seen in jboss, aside from
>egregious bugs, if setting an attribute doesn't have an immediate
>effect, it does have the desired effect if you run through the service
>lifecycle (usually stop, start, occasionally stop, destroy, create,
>start). My view is that mbeans in jboss can take advantage of the
>service lifecycle. If you don't want to, make all your attribute
>changes have their effects immediately. All our mbeans are pretty much
>jboss specific and most heavily use the service lifecycle. They just
>won't run without it. I still think it is a really convenient
>extension to vanilla jmx and don't see why we should replace it.
I barely know what the service lifecycle is. I have not used it. I am not arguing to replace it. I never said that. You said that.
How do I set an attribute correctly, step by step, for a Bean that uses the service lifecycle?
It helps me to use a state metaphor when considering lifecycle issues. It sounds like there are several states a lifecycle-oriented bean can be in: destroyed, created, running. In which state is it safe to set RW attributes on lifecycle-oriented beans?
Is the following the appropriate way to set values on a lifecycle-oriented bean (pseudo-code)?
if(bean.isLifecycleOriented())
{
if(bean.isRunning())
{
bean.stop();
}
bean.setAttribute(newValue);
bean.start();
}
I'm here to learn :)
- Matt
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
