cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thor Heinrichs-Wolpert <>
Subject Re: [RT] On building on stone
Date Mon, 29 Mar 2004 01:31:42 GMT
>> 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).

Well, you can get a good glimpse of how things are done from Juha 
Lindfors book.  There are only so many ways you can call and use MLet 
services ... so there shouldn't be any tainting there (ISBN 
0-672-232288-9).  It might be a bit dated, but I found it to be a 
decent reference when I started using JMX.

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

I agree there.  I only use the MLet services to dynamically load and 
unload my services.  I pass in the configs a'la IOC style as that seems 
the most flexible was easier for me to comprehend (and dump 
configurations for debugging).  I'm going to be moving towards the 
MD5Url for getting my component services as this provides some security 
and version management for the archives I'm using.  To manage load 
dependencies I've opted for service strings.  I read about them in 
various implementations at CERN, but I think the only accessible 
example is the Rio project at to see an implementation that 
they have tried.  They have an attached QoS that is better suited for 
distributed services.  My service string isn't so clever, in that I 
don't manage QoS, but I do tag in version ranges (e.g. so one component 
can say it is known to work with versions 1.x - 2.6 of the network 
alarm agent).  All components lookup the service they want from the JMX 
server, stat current version is compatible (if not they can request an 
update) and then call the service via a Proxy that is built when the 
service is loaded.  I haven't tried to totally encapsulate all of the 
indirect calls in a smart proxy, but I've been told that is a batter 
way to go by Rickard Oberg.  If there was an XDoclet like tool with the 
correct license, I'd say we should look at that for helping with JMX 
work ... but for our limited requirements we could probably use a 
transformer of some sort in Ant to create either the classes or if we 
want to create totally described ones in a configuration doc, with a 
set of MBeans that get instantiated from an XML descriptor file.  We 
lose some of the compile time checking, but I've found it easier to 
keep the required JMX info in my interfaces so that the sources are 
close together.

Does anyone here know how they are using MX4J in the Geronimo container?

Thor HW

View raw message