geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: GBeanName [was: svn commit: r154723...]
Date Wed, 23 Feb 2005 18:09:32 GMT

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

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.

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

View raw message