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)
Message-ID: <421C2639.70203@hiramchirino.com>
Date: Wed, 23 Feb 2005 01:44:09 -0500
From: Hiram Chirino <hiram@hiramchirino.com>
User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: GBeanName [was: svn commit: r154723...]
References: <20050221211909.67281.qmail@minotaur.apache.org>
 <7c1b7d42812d1a853f80334f1d89c8a5@gluecode.com> <421BDE96.5080307@apache.org>
 <978d055531cdefd253931037f3dd160e@gluecode.com> <421C1D75.3060901@apache.org>
In-Reply-To: <421C1D75.3060901@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Does this mean that GBeanName is going to replace more than just where 
ObjectName was being used?  Right now ActiveMQ does not highly use the 
Geronimo Kernel at runtime like some of the other geronimo modules do, 
but if it did want to move in that direction, to for example to have the 
kernel lookup destinations at runtime, wouldn't not having a canonical 
name be less optimal when doing lookups?

Regards,
Hiram

Jeremy Boynes wrote:
> Dain Sundstrom wrote:
> 
>> 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?
>>
> 
> Well, apart from flight of fancy we don't actually have a need for it 
> yet. It's not exactly hard to add when we do.
> 
>>>> 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.
>>
> 
> That would be internal implementation detail in equals()
> 
> The point is that if you are keying on GBeanName then use 
> GBeanName.equals() rather then GBeanName.toString().equals()
> 
>>>> 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.
>>
> 
> I don't think approximate GBeanNames would be useful to anyone.
> 
>> 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.
>>
> 
> ObjectName.getCanonicalName() sorts the keys lexically which does not 
> keep the orginal form; toString()'s output format is undefined. That's 
> the problem. ObjectName does not allow you to easily preserve the 
> original name (you have to reconstruct it from getDomain() and 
> getKeyPropertyListString()).
> 
>>> 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.
>>
> 
> Order is not meaningful to us, but it may be to the user so why should 
> we rearrange it on them (especially when it doesn't matter to us)?
> 
> For example, the current approach means that the example names from the 
> JSR-77 spec would be displayed as they are specified; using the 
> canonical form of ObjectName would rearrange them. The order of the 
> parts is not meaningful to the implementation but it sure makes the 
> examples easier to understand.
> 
>>> 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.
> 
> 
> Because "in most cases the Map supplied will be a Properties object".
> 
> We could of course check for LinkedHashMap but, also playing devil's 
> advocate, the user could have their own implementation of Map.
> 
> Or, we can add an ordered constructor e.g.
> GBeanName(String domain, List<String> keys, List<String> values)
> GBeanName(String domain, String[] keys, String[] values)
> 
> Or, we can have two Map-type constructors e.g.
> GBeanName(String domain, Properties props) // we reorder
> GBeanName(String domain, Map props) // use order from iterator()
> 
> The behaviour currently is clear and simple, and if they want a specific 
> order they can always use the String constructor (because it preserves 
> the value they supply). We don't need to overcomplicate this.
> 
> 
>>
>>>> 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 
>>> javax.management.ObjectName 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.
>>
> 
> Patterns work differently - ObjectName's overloading of real names and 
> patterns is an abomination and we don't need to continue using it.
> 
>> 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.
>>
> 
> I still don't see the need. The JMXGBeanRegistry will need to convert 
> the names to valid ObjectName's to register/unregister instances with 
> the MBeanServer but that is a very specific circumstance, and IMO a JMX 
> problem. The BasicGBeanRegistry need not care.
> 
>>> 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 
>> all.
>>
>> -dain
>>
> 
> Can we be done with this bikeshed now?
> -- 
> Jeremy
>