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 Thu, 25 Mar 2004 19:40:31 GMT
Hmmm ... I've never used JMX for remote loading as the security just 
isn't there for my tastes and there other mechanisms that work so much 
better.  It does do a fine job of loading/unloading components though.

Thor HW
On 25-Mar-04, at 9:17 AM, Pier Fumagalli wrote:

> On 25 Mar 2004, at 16:58, Hamilton Verissimo de Oliveira (Engenharia - 
> SPO) wrote:
>> -----Mensagem original-----
>> De: Thor Heinrichs-Wolpert []
>>> So I think JMX can be a bolt on, or an underpinning depending on how
>>> you use it.  I'd be surprised if it didn't meet the core of what you
>>> described blocks needed.  If a block has a consistent API (Interface)
>>> then any block that supports that API could be loaded/unloaded and
>>> messaged to from other components using the JMX services and usage
>>> guidelines.
>> JMX really helps to develop a extremme loosely-coupled application. 
>> For
>> JBoss its was a necessity, for Cocoon I don't know. And my personal 
>> feeling
>> is that it can increase complexity.
> That's why it should be an instrumentation layer on top of the kernel 
> core, and not "kernel core" in itself.
> Cocoon components are tightly coupled, reside in the same VM, on the 
> same host (they're not remote) BUT they can be reloaded, so they need 
> to have a certain degree of separation.
> JMX allows you to componentize distributed applications, but that's 
> not our focus, Cocoon (at the end of the day) is a servlet... You need 
> something from elsewhere? go and fetch it using the 
> HttpProxyGenerator.
> From the perception of JMX what one should allow (if they want to 
> write it) is to instrument the process of deploying, reloading and 
> reconfiguration (remote) of live running blocks, but the first one who 
> writes a "network remote" transformer, is eligible for severe 
> beating...
> We shouldn't over-indulge in generalization (I personally made that 
> mistake already a while back).
> 	Pier

View raw message