On Tuesday, Aug 19, 2003, at 16:01 Europe/London, Dain Sundstrom wrote:

On Tuesday, August 19, 2003, at 12:51 AM, gianny DAMOUR wrote:

Dain Sundstrom:
Can you tell me what your goal is,
My intent is to propose an implementation of JSR77, which could potentially be re-used.

Reused by whom? ...by some other container using something other then JMX. I really don't see a demand for this, and adding another layer of complexity (for something we don't plan on using) at this stage seems like a bad idea. If it becomes a priority later we can easily add the abstraction in.

Actually, the more dependencies you hard-wire into JMX now, the more difficult it's going to be to put that abstraction layer in. Having it in now is both sensible from a design perspective, and also allows common services to be implemented using abstract classes that implement the interface, as opposed to a bunch of methods that get called through reflection.


I really don't understand why we need this abstraction layer.
I would like to remove from the type hierarchy of the kernel components the specificities of JSR77.

Our deployment system is fundamentally based on 77, but our kernel only understand JMX and specifically doesn't do any 77 stuff. 77 is really handled by the components, if they don't implement it properly the kernel doesn't care. Other components will care if they depend on something that does not properly implement the life-cycle, but the kernel doesn't care in the least bit.

The kernel is the right place to handle the 77 management; whilst it doesn't get handled by the kernel at the moment, it probably should do in the future.


Alex.



Reply via email to