I think a big point (and that may be from never having used JMX) that is being missed. When I was saying JMX and its style form part of a good kernel candidate, you have to look at how JMX is used. It uses a standard reflection mechanism to talk to components. Just to say it supports an MBean interface is missing quite a bit. The main things it does it load, unload, start, stop and manage the config of components. It does this all by reflection, which isn't a big deal, other than the method calls are standardized. There are some basic lifecycle states that can determine a components current state.
Well, you have been missing a point in my reply, which was about ease of configuration not being necessarily a good thing. Anyway, I'm catching up on the whole JMX thing, reading specs and books. So far, I must confess that I'm *horrified* about the tangled web of reflection hacks that make up the spec, not to mention the xml support done *wrong* and the horrible procedural and non-OOP approach that is forced by MBeans interfaces (which quickly become huge switchboards made of if/else statements): no wonder this stuff came from EJB people.
But in any case, for now, I'll refrain to comment further: I'm curious to hear what is your plan of implementing/integrating JMX as a core part of the container, since the more I know about this stuff, the more I get convinced that we need to support it (given the goods it would buy us and given that it makes no sense to use another instrument manager) but as an external thing.
I'm not sure that there is an "other-side of the fence" where you don't need to make things work in real life if you are actually a long-term living in this industry. I'm going to assume that my JMX projects, others that are successful and the JBoss kernel argue the opposite of your "other side of the fence" comment.
I'm wondering if you've ever been on the other side of the fence, which is made of sys/network admins who don't quite give a damn about languages, OOP abstractions and design stuff (I've been there for almost 7 years, so let me state that I know my kids): they have to work with a web of multi-architectural, multi-language, multi-environment stuff which has the growing tendency of working badly together, and they don't want to know what a garbage collector is.
They need tools to give them an overview on how their IT system is working, and they need standard and language neutral stuff to make it work again. Their little world is made of Tivoli, OpenView, some MRTG and, occasionally, a bit of shell scripting: they will know about the problem domain and they will (possibly) have a clue on the generic environment, but just don't ask them to understand dynamic loading through proxies, it just isn't their cup of tea. See my point?
Ciao,
-- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Blogging at: http://www.rabellino.it/blog/)
