GBeanNames

[Aaron Mulder <am...@alumni.princeton.edu>]

	Jeremy, David J, Dain, and I talked a bit about GBeanNames (vs 
ObjectNames) at OSCon.  We didn't fully resolve the issue, but I think we 
made some progress.  Here are some of the key issues:

1) Do we wish to eliminate JMX/ObjectNames from the core kernel?

 - Dain seemed less convinced of this than the rest of us, though I think 
in priniciple we all think this is fine, and differ mainly on the urgency 
and the work we're willing to incur to achieve this.

2) If we eliminate ObjectNames, should it always be possible to generate 
an ObjectName from a GBeanName for JMX interoperability?  Note that 
ObjectNames have a quoted form and limitations on the characters that can 
go into the "value" part of the 'key=value,key=value,...' part of the 
ObjectName.  We don't necessarily want to re-implement all that for the 
GBeanName, though we could simply copy the code from MX4J.

 - We struggled with the extensively before agreeing that GBeanNames 
should be *more* limited than ObjectNames.  That is, a GBeanName should 
have the same structure as an ObjectName, but should not support quoted 
form and should not support characters in the 'value' part that would 
otherwise require a quoted form (including comma, for example).

3) If a GBeanName works mainly like an ObjectName, it should have a String 
representation (foo:bar=baz,...).  You might construct one with a String 
-- new GBeanName("foo:bar=baz,...").  There is also a "canonical" String, 
where the name=value pairs are sorted alphabetically by name in the list.  
The question is, should the GBeanName save the String originally provided 
to the constructor (as one of the ObjectName methods says you should be 
able to access this) or should it save the canonical String (as that seems 
to be what a caller is most likely to want as a String form), or both?

 - This was the main point of disagreement.  There seems to be a clear 
advantage to storing the canonical String, to avoid reconstructing it on 
every call (the Geronimo code almost universally uses getCanonicalName() 
when trying to produce a String for an ObjectName).  However, if the 
original String isn't stored, then if you convert an ObjectName to a 
GBeanName to an ObjectName, the behavior of getKeyPropertyListString() may 
be different between first and third ObjectName instances (though they 
would still be equals() to each other since that only compares canonical 
forms).  We could also store both to achieve both, but that just takes 
twice the space.

4) Should GBeanName be allowed to represent a query (like an ObjectName 
"foo:bar=baz,*")?

 - We agreed that it should not.  We agreed to add a GBeanQuery object 
that could hold criteria for querying for a list of GBeans.  Further, we 
like the idea of querying by interface rather than by name where possible.  
This should eliminate many of the places ObjectNames are otherwise used, 
and encourage queries by functionality rather than by a name which may in 
many cases be somewhat arbitrary.  Side note: this has been implemented 
already, (GBeanQuery and Kernel.listGBeans(GBeanQuery), though it 
currently still supports querying by name as the idea is to be able to 
port everything over to GBeanQuery independently of making the rest of 
these changes).


	I think we'd like to resolve our direction on this for M5, so that 
we don't end up fussing or reverting code at the last minute.  I'm not 
sure we have any concensus on how much we should aim to implement in M5 
even if we come to full agreement.  But it would definitely be great to 
get more feedback from the rest of the group.  As not everyone's going to 
be available in the near future I think we'll need to keep this issue open 
for a while, but it may take time to resolve it anyway.

Thanks,
	Aaron