On Tuesday, January 28, 2003, at 12:47 AM, Dain Sundstrom wrote:
On Monday, January 27, 2003, at 09:36 PM, David Jencks wrote:
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.
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.
So we need to fix the jmx implementation.
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.
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.
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 think if you change several attributes at once the (not yet written)
"state change interceptor" should change the lifecycle state, change
the attribute values, and restore the lifecycle state. You shouldn't
have to explicitly stop the mbean, but it is stopped by the machinery.
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.
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.
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:-)
Cool. I personally have no problem with hard coding our web jmx
console to support the attributes we use.
me too
david
-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
-------------------------------------------------------
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
