On Monday, January 27, 2003, at 09:36 PM, David Jencks wrote:
Ya sure, but the implementation just calls some setters. There implementation doesn't understand that this is a group of changes. If the setAttributes was implemented by hand it could understand that host, port and back log were all changed and only create the new listener socket once.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.
No I mean the second. If you change the port, it should close the existing socket and create a new one. I see no reason why the service should have to be stopped, as I can do this today... it is just an implementation decision.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.
Sorry, I ment to say that the attribute is read only in the running state with an icon that says you must stop the service to edit this attribute.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 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.
For hiding attributes, No thanks, then you can't tell what you might be able to set until you stop the mbean.
Cool. I personally have no problem with hard coding our web jmx console to support the attributes we use.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.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:-)
-dain
-------------------------------------------------------
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
