geronimo-dev mailing list archives

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

To instantiate these, we would add methods to the Kernel like:
    public GBeanName newName(String name) throws InvalidNameException;
    public GBeanName createName(String name) throws InvalidNameError;

where InvalidNameError extends AssertionError and createName works 
similarly to the create operation for URI. Variations would also be 
added that take properties in a manner similar to j.m.ObjectName

One consequence would be that we could no longer create names in static 
initializers (typical use of JMXUtil.getObjectName(String)) as the 
implementation needed would depend on the kernel it was going to be used 
with.

This will also mean changing a lot of code that currently expects to use 
JMX ObjectNames to interact with the kernel. To phase this in I would 
propose we deprecate the existing API calls that use ObjectName and add 
new versions that use GBeanName; we would then remove the ObjectName 
variants at some time between now and RC1 depending on how quickly code 
can be transitioned over.

If no-one objects I will start implementating this next week and expect 
it will take a couple of weeks to complete.

--
Jeremy

Mime
View raw message