cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <>
Subject Re: [RT] On building on stone
Date Sun, 28 Mar 2004 18:19:24 GMT
Thor Heinrichs-Wolpert wrote:

> 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?


Gianugo Rabellino
Pro-netics s.r.l. -
Orixo, the XML business alliance -
     (Blogging at:

View raw message