On Monday, January 27, 2003, at 07:39 PM, Dain Sundstrom wrote:
Wow, I had no idea it was this complicated. Anyway the real problem is a Dynamic MBean has a setAttributes method to group together an entire set of attribute changes in one operator, but when we go to standard mbeans we lose that concept because we only have a bunch of setters. That sucks.??? You still have the setAttributes method on the mbean server, which is the only way you can get at the stuff.
I'm not sure if you are complaining about mbeans that don't actually undo the start in stop (i.e. if it creates a socket in start, it should forget it in stop, then make a new one when start is called again), or saying you think socket creation should be done immediately when you change the port, irrespective of mbean state. I hope it's the first.
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.
For info-- we have this in the xmbean dtd, but we don't have any interceptor support for it yet, and I won't work on it until the aop stuff has settled down. I think some kind of icon indicating the lifecycle state needed for the change would be best.
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?
For hiding attributes, No thanks, then you can't tell what you might be able to set until you stop the mbean.
modelmbean metadata is already generically extensible, and we have extended it with stuff like the lifecycle level and (actually implemented thanks to Matt Munz) persistence. Right now I don't know of a generic way to display arbitrary metadata like this, AFAIK each item would have to be hardcoded. Maybe someone who can actually design usable interfaces could suggest something:-)
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.
david
-dainOn 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
------------------------------------------------------- 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
