cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <p...@betaversion.org>
Subject Re: [RT] On building on stone
Date Thu, 25 Mar 2004 17:17:12 GMT
On 25 Mar 2004, at 16:58, Hamilton Verissimo de Oliveira (Engenharia - 
SPO) wrote:

> -----Mensagem original-----
> De: Thor Heinrichs-Wolpert [mailto:thor@lunartek.com]
>
>> 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

Mime
View raw message