geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: GBeanName [was: svn commit: r154723...]
Date Wed, 23 Feb 2005 04:56:08 GMT
On Feb 22, 2005, at 5:38 PM, Jeremy Boynes wrote:

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

Because, you want to print two gbeans names that are equal and get the 
same string. Because, you don't want geronimo classes bleeding into 
your apis.

Anyway, why not? ObjectName has a canonical format, why are we not 
providing one?

>> 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.

Is it faster to compare two strings or two strings and two hash maps?  
My guess is the former.

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

Right, because they are not equal strings.  If you do x.equals(new 
Float(x).toString()) it will no be true.

Anyway, if you want to keep the original form for this use case (which 
I doubt we will ever see), the add a getCanonicalName method like 
ObjectName has.

> 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.

The order should not be "meaningful".  If we are doing anything like 
ObjectName, the order does not matter, nor do I think we should be 
encouraging a meaning to order.

> 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.

Playing devils advocate, what if I provide you a LinkedHashMap 
containing a "meaningful" order.

>> 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 
> 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.

That is fine with me because it is further restriction on the type. But 
we must also include asterisk and question mark to not conflict with 
object name patterns (and it would allow for really ugly names).  Also 
we should disallow the quote character to not conflict with quoted 
object names.

So are you going to add a validation phase to scan the string for 
illegal characters?  We don't create names in critical sections of 
code, so I wouldn't mind the over head.  Also it should be pretty fast.

> 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.

If we take the restrictions above, there will not be need to escape at 


View raw message