geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
Subject Re: GBeanName [was: svn commit: r154723...]
Date Wed, 23 Feb 2005 18:12:27 GMT
Bordet, Simone wrote:
> Hi, 
>>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).
> Just as an aside note, JMX may change in the future about orders of the
> keys.
> One thing the expert group is evaluating for inclusion in J2SE 6 is to
> make ObjectName implements Comparable<ObjectName>, and the
> implementation of compare() be "smart".

Not sure what you mean here - are you comparing ObjectNames or keys?

I would have thought for keys you would want


where the Comparator was used to order the keys. Hmm, perhaps we do that 
for GBeanName?

On the other hand, if you are looking to order query results then perhaps

    MBeanServer.queryNames(ObjectName, QueryExp, Comparator<ObjectName>)

would be adequate.

> For example, to "sort" the keys so that the "type" key is always the
> first.
> This is intended for further grouping (beyond what you can do with the
> domain), e.g.:
> :type=connector,protocol=rmi,transport=jrmp
> :type=connector,protocol=rmi,transport=iiop

Of course, the canonicalization here would have converted those back to:

Humans (ok, Westerners) tend to read left to right so from a usability 
perspective it makes sense to have the more significant keys first 
(according to some context known to the user).

> "Sorted" this way MBeans are probably more human readable than the case
> where the keys are in random order.
> Not that it may be relevant for this discussion, but wanted to let you
> know.
> My experience with JMX tells that trying to preserve the string at
> construction lead to complexity in the implementation (I hope that
> GBeanNames don't have a GBeanName(String domain, Map keys) constructor)
> and it is not very often needed.

Ironically we use that quite a bit as it allows us to build up JSR77 
names incrementally.

The current implementation is fairly simple, I think mainly because we 
dumped all the quoting mechanisms and separated out patterns.


Royal Blue!

View raw message