Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <40673F2E.1010903@apache.org>
Date: Sun, 28 Mar 2004 23:10:06 +0200
From: Gianugo Rabellino <gianugo@apache.org>
User-Agent: Mozilla Thunderbird 0.5 (Macintosh/20040208)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] On building on stone
References: <07258F4244D6F649B1A78993D070B7CA6F7830@ACSPMXE02>
 <41AF6667-7E80-11D8-9EBC-000393C27E0C@betaversion.org>
 <46A5A93C-7E94-11D8-824F-00039388DCEE@lunartek.com>
 <7CB1C412-7EB3-11D8-92A8-000A95984AEA@betaversion.org>
 <40644882.4030003@apache.org>
 <A21872B8-800C-11D8-824F-00039388DCEE@lunartek.com>
 <4067172C.2080503@apache.org>
 <C63F0EAA-80E7-11D8-824F-00039388DCEE@lunartek.com>
In-Reply-To: <C63F0EAA-80E7-11D8-824F-00039388DCEE@lunartek.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Thor Heinrichs-Wolpert wrote:

> I'll have to say yes I do know about sys admin work (if we're going to 
> count years, mine is 22 years now).  Matter of fact one of the JMX 
> products I mentioned is a IT management tool (monitoring SNMP, services, 
> even SSH accessible shell scripts and the internals of our Oracle, MySQL 
> and other databases, Cisco routers, Linux routers, and even slot 
> machines *g*).

Well, of course I have no interest in a "my experience is longer than 
yours" discussion. :-) I'm not saying that JMX can't be part of an IT 
management environment, it's quite the opposite actually. What I'm 
contesting is that every configuration and basic application behaviour 
should be managed via JMX since this would mean forcing your application 
to adhere to the JMX model which is, AFAIU, somehow limited 
architecturally: it seems to me that it's easy to do simple task (set 
and get properties, send notifications) but it becomes horribly (and 
uselessly) complicated when it comes to complex stuff. There are things 
that are better done with plain old configuration systems, which can 
express much more: starting to use model/open MBeans seems to me ankward 
as hell and, most of all, unmanageable (go figure!) from the application 
development point of view: my impression is that there is a high chance 
of inserting bugs when using JMX the way it wasn't conceived for.

> I know there is no love lost between the Apache and JBoss communities, 
> but have a look at their kernel.  It is not entirely based upon JMX, but 
> JMX forms a very integral part of their kernel and is pretty good, all 
> things considered.

Well, you see, I don't want to do that because of licensing issues: it's 
very easy to become tainted, and I definitely don't want to do that with 
a GPL product (and yes, I know that sucks big time, but we have to face it).

> In the products I've built using JMX, like I stated earlier, I use JMX 
> to load/unload and to manage the config of the components.  I think the 
> last one we did was better in that the global configuration is held in a 
> centralized database and the framework itself messaged the new 
> configuration to the servers (nodes) and the JMX system was used to get 
> the new component (via Jini calls, but JMX has no idea how it gets 
> there) and then load it in with the IoC config and swaps out the old 
> component, which is then GC, or can be dropped by kicking the classloader.
> 
> Have a quick look at those systems for ideas.  When you swap in a 
> component, you also have to consider how all of the other components are 
> talking to it.  Almost every system out there that attempts this uses 
> the concept of a messaging bus between components, so that you can 
> actually swap out a component, which becomes difficult and language 
> dependent when using direct references.
> 
> The ability to swap in/out components and have the other components in 
> the system use it without much in the way of hiccups is a more 
> interesting design problem than the load/unload and config.

Definitely. I'm still wondering how you might deal with this nightmare 
with JMX. It's pretty clear to me that JMX relations are not enough. 
Care to tell us more on how you solved or plan to solve this kind of issues?

> Thor HW (who is really enjoying these discussions!!!)

Oh, same here, that's for sure. :-)

-- 
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/)