Hi,
One of the goals of the kernel has been to support JMX but also to allow implementations that do not rely on it. However, one area of coupling that is prevalent is the use of javax.management.ObjectName to identify GBean instances.
I would like to propose we add an interface to the kernel module
that represents a GBean's identity (e.g. o.a.g.k.GBeanName) that
serves a similar function but which can be implemented based on j.m.ObjectName or alternatives.
I'm playing the role of the devil's lawyer here, and sure I lack deep knowledge about the kernel, but I was wondering: if GBeanName walks like an ObjectName, quacks like an ObjectName and looks like an ObjectName, then why not use ObjectName ?
Consider also that it is a standard JDK class in J2SE 5.
I mean: the kernel already depends on JDK classes like Map, HashMap, etc. Why ObjectName is different ?
The big one for me was that it does not become part of the SE API until JDK1.5. Given the newness, there is going to be inertia in the industry on widespread adoption until, I think, mid to late 2005. Until then, anyone looking for a lightweight, unmanaged Geronimo kernel would require, at minimum, an implementation of the JMX API classes.
The other one is that JMX imposes requirements on the semantic of ObjectName (e.g. the way in which names are structured, parsed and validated) that Geronimo does not need. We may be able to have alternate implementations that are tuned for Geronimo's use rather than JMX.
-- Jeremy
