Dain Sundstrom wrote:
I think we will need a canonical form.

Why?

There are many places that key stuff off the string canonical form of the object name.

Isn't that fundamentally a bad idea? If you want to key off GBean name, key off GBeanName and not the string representation.


I think that instead of keeping the original name around, we throw it out and replace it with canonical name form, since the original name doesn't really matter.

It does to the user - it means that for a String x x.equals(new GBeanName(x).toString())

Or specifically, that if you specify properties in some meaningful order the name does not get rearranged on you. So if you have a name in a plan that will be the name displayed in the console not some variant of it.

On the other hand, if you supply the properties using a Map, they are sorted into lexical order when constructing the String representation on the assumption that most Maps will be non-deterministically ordered (i.e. that in most cases the Map supplied will be a Properties object) and this provides a representation that is consistent between VMs/architectures.

Also I would hope the canonical form is the same as object name.


That assumes a need for canonical name.

One other thing, it doesn't look like this is escaping key values, or checking for illegal characters.


Nope - there is a significant performance overhead with javax.management.ObjectName in all the validation and esacaping it does of key/value pairs. We can avoid all of that by imposing the condition that ':', ',' and '=' are reserved characters and should not be used.


Any GBean can be registered with an MBeanServer simply by quoting the name, making escaping a JMX issue not a GBean one which should be handled in the JMX registry.

KISS
--
Jeremy

Reply via email to