For now we can generate standard mbean interfaces and, when we get an xmbean impl. switch over with minimal effort. Including appropriate documentation now will make the switch easier.
Is xdoclet being used in the current build system?
david jencks
On Tuesday, August 12, 2003, at 09:07 AM, 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?
Ie - for a given FooService, why do we need to write a FooServiceMBean interface that just has the methods we wish to expose?
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.
I think we should be able to just create the FooService objects and then describe any MBeans we want for them in XML - describing the methods and the meta data in one spot.
If we decide not to use MBeans, then we still have our FooService objects and we have no FooServiceMBean objects clutering up the repository.
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.
-- Greg Wilkins<[EMAIL PROTECTED]> Phone/fax: +44 7092063462 Mort Bay Consulting Australia and UK. http://www.mortbay.com
