On Feb 23, 2005, at 9:09 AM, Jeremy Boynes wrote:
David Jencks wrote:+1 on canonical name as internal string representation
-1 on attempting to preserve whatever string is used to construct the gbean name
I think the usability value in getting back what you put it is greater than having the keys rearranged on you (given the order of the keys is not significant to the implementation).
Why do you think rearranging them is more usable?
given the choice of: a) x.equals(y) implies x.toString().equals(y.toString())
and b) name == new GBeanName(name).toString()
I pick (a) by a preference of about 10^^10.
It's a relatively unimportant side effect, but if we calculate and intern the canonical string in the constructor, we can have x.equals(y) iff x.toString() == y.toString() and the gbean registry can use an IdentityHashMap to key the gbean instances.
+1 on restricting characters in gbean name and assuring that gbean name >> object name conversion always works in a non-surprising manner.
The restrictions on characters in ObjectName and the subsequent quoting mechanism are a consequence of the overloading between values and patterns. If we simplify the API and get rid of the latter then we no longer need any additional restrictions inside Geronimo.
There is a clear conversion between a GBeanName and an ObjectName: any keys or values that contain characters that are illegal in JMX can be quoted and escaped /in JMX/; GBeanNames that are legal ObjectNames can be used as-is.
no problem there then.
thanks david jencks
Of course, we would recommend that users stick to simple names that are compatible with both but there is no need to enforce JMX restrictions on a non-JMX implementation.
-- Jeremy
