geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <dsundst...@gluecode.com>
Subject Re: Remove reliance on JMX and javax.management.ObjectName
Date Sat, 20 Nov 2004 22:07:45 GMT
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


Mime
View raw message