-----Mensagem original----- De: Thor Heinrichs-Wolpert [mailto:[EMAIL PROTECTED]
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
smime.p7s
Description: S/MIME cryptographic signature
