On Nov 20, 2004, at 1:43 PM, Bordet, Simone wrote:
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?
I hope it doesn't quack like an ObjectName. We already have utility methods to construct object names because of the checked exceptions.
Consider also that it is a standard JDK class in J2SE 5.
We are targeting 1.4 platforms, but the real problem I see is if we use a JDK class, we can not add optimizations the class. Considering object name is the *key* class in geronimo, we may store a geronimo specific hash code or index the GBeanName instance. If we use ObjectName, we are stuck with what ever sun give us.
I mean: the kernel already depends on JDK classes like Map, HashMap, etc. Why ObjectName is different ?
The nice thing about HashMap is that is implements the Map interface, so we always have ability to change the implementation. For ObjectName, we are stuck with what ever sun give us.
-dain
