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: <ad8cece919382c7eb5415e0f7e7a007a@gluecode.com>
References: <20050221211909.67281.qmail@minotaur.apache.org>
 <7c1b7d42812d1a853f80334f1d89c8a5@gluecode.com> <421BDE96.5080307@apache.org>
 <978d055531cdefd253931037f3dd160e@gluecode.com> <421C1D75.3060901@apache.org>
 <ad8cece919382c7eb5415e0f7e7a007a@gluecode.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <45ff348a778b63a507f23508bfe85dd8@yahoo.com>
Content-Transfer-Encoding: 7bit
From: David Jencks <david_jencks@yahoo.com>
Subject: Re: GBeanName [was: svn commit: r154723...]
Date: Wed, 23 Feb 2005 00:23:03 -0800
To: dev@geronimo.apache.org

+1 on canonical name as internal string representation
-1 on attempting to preserve whatever string is used to construct the 
gbean name
+1 on restricting characters in gbean name and assuring that gbean name 
 >> object name conversion always works in a non-surprising manner.

(although I may change my mind, currently I am strongly in favor of the 
above)

thanks
david jencks

On Feb 23, 2005, at 12:13 AM, Dain Sundstrom wrote:

> On Feb 22, 2005, at 10:06 PM, 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.
>
> This is not an flight of fancy. The first argument is a desire to 
> preserve useful functionality that ObjectName provided (i.e., a string 
> from that is guaranteed to be equal only when the names are equal), 
> and the second argument is a desire to keep our objects from bleeding 
> into other people's apis (i.e., I don't want another qname fiasco).
>
>>>>> 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()
>
> Internal implementation matters unless you make GBeanName an interface 
> or non-final.  In the case of a single implementation class such as 
> this, the implementation we choose dictates performance.
>
>> The point is that if you are keying on GBeanName then use 
>> GBeanName.equals() rather then GBeanName.toString().equals()
>
> I understand you desire to have people to use the name as a key, but 
> we should not require it.  ObjectName has shown that providing a 
> simple string canonical form allows people to key without needing to 
> use their classes, and we should do the same.  Most importantly it 
> keeps user apis free of geronimo classes.
>
>>>>> 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.
>
> My point is that your argument is invalid.  There is no guarantee in 
> java that x.equals(new SomeClass(x).toString()) is ever 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.
>>
>> 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)?
>
> Why keep it around if it is only for display purposes?  The reason I 
> ask, is an unordered name is useless for any other purpose.
>
> Well, having a canonical form is important, so this would mean we need 
> two strings.  If the group wants the GBeanName to carry two strings, 
> then that works.  I personally only want one string, canonical form.
>
>> 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.
>
> 77 names are generated in the deployment code using unordered maps.  
> IMNHO, a console respecting 77 should sort the 77 names into a tree 
> based on the hierarchy laid out in the spec.
>
>>>> 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.
>
> I'm not going to press this point, other then to say I believe your 
> analysis supports my point.
>
>>>>> 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.
>
> That is for another discussion.  If we don't restrict asterisk and 
> question, we are expanding on the type which I am definitely -1 for as 
> it would make it impossible to mount some names into an mbean server.
>
>>> 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.
>
> If we restrict characters, we should enforce the restriction.  
> Otherwise, names will be created that can not be mounted into JMX.  
> That means that someone could have a perfectly working system, turn on 
> jmx and nothing works.  I personally don't ever want to be in that 
> situation.
>
>>>> 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?
>
> This is not a bikeshead; these are important decisions that should be 
> discussed.  Your decisions could break seamless integration with JMX, 
> and could require redesign of OpenEJB, ActiveMQ gbeans, and gbeans in 
> geronimo itself.
>
> If you want, I'll implement the class and make the changes.
>
> -dain
>