Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v619.2)
In-Reply-To: <421CB8C5.2040009@apache.org>
References: <20050221211909.67281.qmail@minotaur.apache.org>
 <7c1b7d42812d1a853f80334f1d89c8a5@gluecode.com> <421BDE96.5080307@apache.org>
 <978d055531cdefd253931037f3dd160e@gluecode.com> <421C1D75.3060901@apache.org>
 <ad8cece919382c7eb5415e0f7e7a007a@gluecode.com>
 <45ff348a778b63a507f23508bfe85dd8@yahoo.com> <421CB8C5.2040009@apache.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <ab97853de39e1f79458ba5931fb41c06@gluecode.com>
Content-Transfer-Encoding: 7bit
From: David Jencks <djencks@gluecode.com>
Subject: Re: GBeanName [was: svn commit: r154723...]
Date: Wed, 23 Feb 2005 10:09:32 -0800
To: dev@geronimo.apache.org


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
>