On Tuesday, Aug 12, 2003, at 14:07 Europe/London, Greg Wilkins wrote:
James Strachan wrote:
Why? Whats confusing about it? Why would inventing yet-another-API be any less confusing?An interface based MBean is just a naming convention. There is no tying to anything. Indeed there's not even a dependency on JMX never mind any other container API. Then the container is totally free to go in whatever direction it wishes.But by creating (and calling) them MBeans, you are tying it down to a naming convention expected by JMX which may confuse the issue later.
Why can't we go for a totally dynamic MBean model?
Yes, this is precisely the kind of thing I was working towards. In the code sample posted earlier, I wanted to demonstrate how it could be done to avoid dependency on the JMX spec of calling things MBean, but still provide that as a service. There's no reason why it couldn't be achieved using a dynamic interface instead.
This is the simplest form of MBean, but contains no meta data to describe that MBean - which has to be placed in an xml file elsewhere.
If we decide not to use MBeans, then we still have our FooService objects and we have no FooServiceMBean objects clutering up the repository.
Yes, the less clutter (and dependency on MBeans) the better.
If we decide to use MBeans - it means that we will have fewer undocumented MBeans without real meta data. We can also expose more of an object simply by changing the MBean descriptor file.
Agree completely.
Alex.
