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