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

ObjectName.toString(Comparator<String>)

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

List<ObjectName>
   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: :protocol=rmi,transport=jrmp,type=connector :protocol=rmi,transport=iiop,type=connector

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.

--
Jeremy

Royal Blue!

Reply via email to