+1
Good idea. This has been bugging me for a long time.
-dain
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 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
