geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Remove reliance on JMX and
Date Sat, 20 Nov 2004 20:14:20 GMT

Good idea.  This has been bugging me for a long time.


On Nov 20, 2004, at 11:44 AM, Jeremy Boynes wrote:

> 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 
> 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

View raw message