On Wednesday, Aug 13, 2003, at 08:35 Europe/London, Pasi Salminen wrote:
At least I'm in favour of model MBeans. They can be described in XML (which I think is a good idea) and they can have annotations. What does it say to an administrator if he can see an operation stop? For us (being professional J2EE propeller heads) it may be obvious but for an administrator it would be nice to see some description of the operation or attribute he is trying to invoke or manipulate. That's why model beans are nice. And if the configuration file is implemented so that it can "dig" information out of the bean (if not
overridden in the XML configuration) that's cool and keeps configuration simpler.
Bear in mind that a console doesn't have to be provided in terms of its coding interface. I have used another J2EE server where it is clear that everything is exposed from underlying MBeans, and the net effect is of a very disorganised and non-user-friendly UI.
Secondly, I don't understand why some of you are so afraid of JMX. Nobodys afraid of HTTP fading away. It's there in the spec and it'll be part of the server anyhow, just like servlets.
I think that the big disadvantages of using JMX as a kernel is ...
However, whoever has proposed JMX (kernel) to be used as an invocation bus, I not sure if I agree with him/her. The MBeans could just expose, for example the HTTP support, and from then on it just controls when to stop it and how to get performance metrics (etc) from it. Inter-service bindings/lookups could of course be implemented with JMX relation service...
... the one you mentioned.
Plus, it does tend to take the discussions of the configuration file as: "Let's use XML to configure which MBeans to start up", which again may not be the most user-friendy way of providing the information to an administrator.
You also run into further issues in the ConfigurationAsFlatFile and ConfigurationAsRegistry wiki pages, which I won't go into any more here.
Alex.
