On Feb 23, 2005, at 12:23 AM, 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've been following from the peanut gallery, and like deployment, this seems to be a required topic for participation, so I need to ask :
Why not preserve the string? it has no intrinsic meaning, does it? And thus, why not let it be preserved as a convenience for the user?
That way, JSR77 name retain their conventional structure, for example...
+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: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.Dain Sundstrom wrote:
I think we will need a canonical form.
Why?
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).
Is it faster to compare two strings or two strings and two hash maps? My guess is the former.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.
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.
Right, because they are not equal strings. If you do x.equals(new Float(x).toString()) it will no be true.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())
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.
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.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.
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
-- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
