geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@gluecode.com>
Subject Re: Remove reliance on JMX and javax.management.ObjectName
Date Sat, 20 Nov 2004 22:10:01 GMT
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 ?
> 
> 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

Mime
View raw message