You are viewing a plain text version of this content. The canonical link for it is here.
Posted to scm@geronimo.apache.org by jb...@apache.org on 2005/02/21 22:19:09 UTC
svn commit: r154723 - in geronimo/trunk/modules/kernel/src:
java/org/apache/geronimo/gbean/GBeanName.java
test/org/apache/geronimo/gbean/GBeanNameTest.java
Author: jboynes
Date: Mon Feb 21 13:19:07 2005
New Revision: 154723
URL: http://svn.apache.org/viewcvs?view=rev&rev=154723
Log:
initial impl of GBeanName
Added:
geronimo/trunk/modules/kernel/src/java/org/apache/geronimo/gbean/GBeanName.java
geronimo/trunk/modules/kernel/src/test/org/apache/geronimo/gbean/GBeanNameTest.java
Added: geronimo/trunk/modules/kernel/src/java/org/apache/geronimo/gbean/GBeanName.java
URL: http://svn.apache.org/viewcvs/geronimo/trunk/modules/kernel/src/java/org/apache/geronimo/gbean/GBeanName.java?view=auto&rev=154723
==============================================================================
--- geronimo/trunk/modules/kernel/src/java/org/apache/geronimo/gbean/GBeanName.java (added)
+++ geronimo/trunk/modules/kernel/src/java/org/apache/geronimo/gbean/GBeanName.java Mon Feb 21 13:19:07 2005
@@ -0,0 +1,184 @@
+/**
+ *
+ * Copyright 2005 The Apache Software Foundation
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.geronimo.gbean;
+
+import java.io.Serializable;
+import java.util.Arrays;
+import java.util.Iterator;
+import java.util.Map;
+import java.util.Properties;
+
+
+/**
+ * Class that represents the name for a GBean.
+ * A name is comprised of a domain combined with one or more properties.
+ * The domain is a fixed base name, properties qualify that as necessary.
+ * Two names are equal if they have the same name and the same properties.
+ * The String representation of a name can be written as domain:key1=value1,key2=value2,...
+ * Values are case sensitive, spaces are significant and there is no escaping mechanism;
+ * this is intended to be fast rather than allow lax syntax.
+ *
+ * @version $Rev$ $Date$
+ */
+public final class GBeanName implements Serializable {
+ private static final long serialVersionUID = 8571821054715922993L;
+
+ /**
+ * Original name preserved; used for toString and Serialized form
+ */
+ private final String name;
+ private final transient String domain;
+ private final transient Properties props;
+ private final transient int hashCode;
+
+ /**
+ * Construct a GBeanName by combining a domain with explicit properties.
+ * The string representation of this name is generated by combining the properties in sorted order.
+ *
+ * @param domain the domain
+ * @param props the properties used to qualify this name
+ */
+ public GBeanName(String domain, Properties props) {
+ if (domain == null) {
+ throw new IllegalArgumentException("domain is null");
+ } else if (props == null) {
+ throw new IllegalArgumentException("props is null");
+ } else if (props.isEmpty()) {
+ throw new IllegalArgumentException("props is empty");
+ }
+ this.domain = domain;
+ this.props = new Properties(props);
+ this.name = sortName(domain, props);
+ this.hashCode = domain.hashCode() + 37 * props.hashCode();
+ }
+
+ /**
+ * Construct a GBeanName by parsing a string.
+ * @param name the name to parse
+ */
+ public GBeanName(String name) {
+ int idx = name.indexOf(':');
+ if (idx == -1) {
+ throw new IllegalArgumentException("Missing ':' for domain: " + name);
+ }
+ this.name = name;
+ this.domain = name.substring(0, idx);
+ this.props = parseName(name.substring(idx + 1));
+ this.hashCode = domain.hashCode() + 37 * props.hashCode();
+ }
+
+ private static Properties parseName(String name) {
+ if (name.endsWith(",")) {
+ throw new IllegalArgumentException("Missing last property pair");
+ }
+ Properties props = new Properties();
+ String[] pairs = name.split(",");
+ for (int i = 0; i < pairs.length; i++) {
+ String pair = pairs[i];
+ int idx = pair.indexOf('=');
+ if (idx == -1) {
+ throw new IllegalArgumentException("Invalid property pair: " + pair);
+ }
+ String key = pair.substring(0, idx);
+ String value = pair.substring(idx + 1);
+ if (props.put(key, value) != null) {
+ throw new IllegalArgumentException("Duplicate property: " + key);
+ }
+ }
+ return props;
+ }
+
+ private static String sortName(String domain, Map props) {
+ String[] names = (String[]) props.keySet().toArray(new String[props.size()]);
+ Arrays.sort(names);
+ StringBuffer buf = new StringBuffer(128);
+ buf.append(domain).append(':');
+ buf.append(names[0]).append('=').append(props.get(names[0]));
+ for (int i = 1; i < names.length; i++) {
+ String name = names[i];
+ buf.append(',').append(name).append('=').append(props.get(name));
+ }
+ return buf.toString();
+ }
+
+ /**
+ * Determine if this name matches the supplied pattern.
+ * This performs a fast but simplistic pattern match which is true if:
+ * <ul>
+ * <li>The domains are equal</li>
+ * <li>If this instance has all the supplied properties with equal values</li>
+ * <ul>
+ * A null domain and a null or empty properties object are considered wildcards
+ * and always match; in other words GBeanName.match(null, new Properties()) will
+ * always evaluate to true.
+ *
+ * @param domain the domain to match
+ * @param pattern the set properties to match
+ * @return true if this instance matches the pattern
+ */
+ public boolean matches(String domain, Properties pattern) {
+ if (domain != null) {
+ if (!this.domain.equals(domain)) {
+ return false;
+ }
+ }
+ if (pattern != null && !pattern.isEmpty()) {
+ for (Iterator i = pattern.entrySet().iterator(); i.hasNext();) {
+ Map.Entry entry = (Map.Entry) i.next();
+ String key = (String) entry.getKey();
+ String ourValue = (String) props.get(key);
+ if (ourValue == null || !ourValue.equals(entry.getValue())) {
+ return false;
+ }
+ }
+ }
+ return true;
+ }
+
+ /**
+ * Test for equality.
+ * This instance will be equal if the supplied object is a GBeanName with
+ * equal domain and properties.
+ * @param obj
+ * @return
+ */
+ public boolean equals(Object obj) {
+ if (obj == this) return true;
+ if (obj instanceof GBeanName == false) return false;
+ final GBeanName other = (GBeanName) obj;
+ return this.domain.equals(other.domain) && this.props.equals(other.props);
+ }
+
+ public int hashCode() {
+ return hashCode;
+ }
+
+ /**
+ * Return a human readable version of this GBeanName. If the instance was created
+ * by parsing a String, this will be the supplied value; it it was created by
+ * supplying properties, the name will contain properties in sorted order.
+ *
+ * @return a readable name
+ */
+ public String toString() {
+ return name;
+ }
+
+ private Object readResolve() {
+ return new GBeanName(name);
+ }
+}
\ No newline at end of file
Added: geronimo/trunk/modules/kernel/src/test/org/apache/geronimo/gbean/GBeanNameTest.java
URL: http://svn.apache.org/viewcvs/geronimo/trunk/modules/kernel/src/test/org/apache/geronimo/gbean/GBeanNameTest.java?view=auto&rev=154723
==============================================================================
--- geronimo/trunk/modules/kernel/src/test/org/apache/geronimo/gbean/GBeanNameTest.java (added)
+++ geronimo/trunk/modules/kernel/src/test/org/apache/geronimo/gbean/GBeanNameTest.java Mon Feb 21 13:19:07 2005
@@ -0,0 +1,157 @@
+/**
+ *
+ * Copyright 2005 The Apache Software Foundation
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.geronimo.gbean;
+
+import java.util.Properties;
+import java.util.HashSet;
+import java.util.Set;
+import java.rmi.MarshalledObject;
+
+import junit.framework.TestCase;
+
+/**
+ * @version $Rev$ $Date$
+ */
+public class GBeanNameTest extends TestCase {
+ private Properties props;
+
+ public void testPropertyConstruction() {
+ String domain = "testDomain";
+ props.put("prop1", "value1");
+ props.put("prop2", "value2");
+ GBeanName name = new GBeanName(domain, props);
+ assertEquals("testDomain:prop1=value1,prop2=value2", name.toString());
+ }
+
+ public void testNameConstruction() {
+ GBeanName name = new GBeanName("testDomain:prop1=value1,prop2=value2");
+ assertEquals("testDomain:prop1=value1,prop2=value2", name.toString());
+
+ name = new GBeanName("testDomain:prop2=value2,prop1=value1");
+ assertEquals("testDomain:prop2=value2,prop1=value1", name.toString());
+ }
+
+ public void testMatches() {
+ GBeanName name = new GBeanName("testDomain:prop1=value1,prop2=value2");
+ assertTrue(name.matches(null, null));
+ assertTrue(name.matches(null, props));
+ assertTrue(name.matches("testDomain", null));
+ assertTrue(name.matches("testDomain", props));
+
+ assertFalse(name.matches("test", null));
+ assertFalse(name.matches("test", props));
+
+ props.setProperty("prop1", "value2");
+ assertFalse(name.matches("testDomain", props));
+ props.setProperty("prop1", "value1");
+ assertTrue(name.matches("testDomain", props));
+ props.setProperty("prop2", "value2");
+ assertTrue(name.matches("testDomain", props));
+ props.setProperty("prop3", "value3");
+ assertFalse(name.matches("testDomain", props));
+ }
+
+ public void testInvalidNames() {
+ try {
+ new GBeanName(null);
+ fail();
+ } catch (NullPointerException e) {
+ }
+ try {
+ new GBeanName("");
+ fail();
+ } catch (IllegalArgumentException e) {
+ }
+ try {
+ new GBeanName("foo=bar");
+ fail();
+ } catch (IllegalArgumentException e) {
+ }
+ try {
+ new GBeanName("x:");
+ fail();
+ } catch (IllegalArgumentException e) {
+ }
+ try {
+ new GBeanName("x: ");
+ fail();
+ } catch (IllegalArgumentException e) {
+ }
+ try {
+ new GBeanName("x:foo");
+ fail();
+ } catch (IllegalArgumentException e) {
+ }
+ try {
+ new GBeanName("x:x=x,foo");
+ fail();
+ } catch (IllegalArgumentException e) {
+ }
+ try {
+ new GBeanName("x:x=x,").toString();
+ fail();
+ } catch (IllegalArgumentException e) {
+ }
+ try {
+ new GBeanName("x:x=x, ").toString();
+ fail();
+ } catch (IllegalArgumentException e) {
+ }
+ try {
+ new GBeanName("x:,x=x");
+ fail();
+ } catch (IllegalArgumentException e) {
+ }
+ try {
+ new GBeanName("x:x=x,,y=y");
+ fail();
+ } catch (IllegalArgumentException e) {
+ }
+ try {
+ new GBeanName("x:x=x,x=x");
+ fail();
+ } catch (IllegalArgumentException e) {
+ }
+ }
+
+ public void testEquals() {
+ GBeanName name = new GBeanName("testDomain:prop1=value1,prop2=value2");
+ assertEquals(name, name);
+ assertEquals(new GBeanName("testDomain:prop2=value2,prop1=value1"), name);
+ assertFalse(name.equals(new GBeanName("foo:prop1=value1,prop2=value2")));
+ assertFalse(name.equals(new GBeanName("testDomain:prop1=value1")));
+ assertFalse(name.equals(new GBeanName("testDomain:prop2=value2")));
+ assertFalse(name.equals(new GBeanName("testDomain:prop2=value2")));
+ assertFalse(name.equals(new GBeanName("testDomain:prop1=value1,prop2=value2,prop3=value3")));
+
+ Set set = new HashSet();
+ set.add(name);
+ set.add(name);
+ assertEquals(1, set.size());
+ }
+
+ public void testSerialization() throws Exception {
+ GBeanName name = new GBeanName("testDomain:prop1=value1,prop2=value2");
+ MarshalledObject o = new MarshalledObject(name);
+ GBeanName name2 = (GBeanName) o.get();
+ assertEquals(name, name2);
+ }
+
+ protected void setUp() throws Exception {
+ props = new Properties();
+ }
+}
Re: GBeanName [was: svn commit: r154723...]
Posted by Jeremy Boynes <jb...@apache.org>.
Hiram Chirino wrote:
> Does this mean that GBeanName is going to replace more than just where
> ObjectName was being used?
Not sure what you mean.
GBeanName is going to be how we identify GBean instances within a kernel
so instead of
Kernel.getAttribute(new ObjectName(instanceName), attrName)
you would write
Kernel.getAttribute(new GBeanName(instanceName), attrName)
If you are using the Kernel then you are already dependent on Geronimo;
we just eliminating the additional dependency on JMX.
> 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?
>
In either case you are looking up by the name object not the string and
in both cases the order of the key/value pairs is not significant.
If you are looking in JMX rather than the Kernel (which is what we are
trying to get away from) then you would continue to use ObjectName just
as before.
--
Jeremy
Re: GBeanName [was: svn commit: r154723...]
Posted by Hiram Chirino <hi...@hiramchirino.com>.
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
>
Re: GBeanName [was: svn commit: r154723...]
Posted by David Blevins <da...@visi.com>.
On Wed, Feb 23, 2005 at 09:16:58AM -0800, Jeremy Boynes wrote:
> David Blevins wrote:
> >The protocol layer in OpenEJB uses the canonical string version all over
> >the place. We avoided ObjectName on the wire as String is capable of
> >representing an ObjectName and serializes faster and with less bytes as
> >there is special logic in java.io.ObjectOutput/InputStream that
> >basically treats them like primitives.
>
> I take it you have some form of custom serialization code that converts
> ObjectName to String and back again. GBeanName is Serializable (and the
> serialized form is just a String) so it should continue to work right
> now until you can add custom serialization just as for ObjectName.
>
We don't convert to/from ObjectName on each call, we stick with string.
-David
Re: GBeanName [was: svn commit: r154723...]
Posted by David Blevins <da...@visi.com>.
On Wed, Feb 23, 2005 at 10:30:51AM -0800, Jeremy Boynes wrote:
> Dain Sundstrom wrote:
> >On Feb 23, 2005, at 9:16 AM, Jeremy Boynes wrote:
> >
> >>David Blevins wrote:
> >>
> >>>The protocol layer in OpenEJB uses the canonical string version all
> >>>over the place. We avoided ObjectName on the wire as String is
> >>>capable of representing an ObjectName and serializes faster and with
> >>>less bytes as there is special logic in
> >>>java.io.ObjectOutput/InputStream that basically treats them like
> >>>primitives.
> >>
> >>
> >>I take it you have some form of custom serialization code that
> >>converts ObjectName to String and back again. GBeanName is
> >>Serializable (and the serialized form is just a String) so it should
> >>continue to work right now until you can add custom serialization just
> >>as for ObjectName.
> >
> >
> >OpenEJB sends the string to the client and sometimes gets a string back
> >(ejbs are indexed by number for speed). When a string comes back it is
> >looked up directly into a hash, keyed on the string. The means that
> >OpenEJB clients do not see any Geronimo code. If GBeanNames were used,
> >then the client would need a GBeanName class.
> >
>
> I don't see the issue - OpenEJB can still send Strings to the client, it
> just needs to convert then into GBeanNames /back on the server/ before
> looking them up in its map; or ObjectNames, or whatever it wants to key
> the map on (although GBeanName seems intuitive).
We key on string as it's a lot faster on the .equals call.
> As you are already assuming the client is not going to be reordering
> the String you send it, then it seems to me that things would be
> unchanged.
Is it equally safe to assume the order won't change on the server? Things like EJB handles have to stay valid across server crashes and restarts. I want avoid anything that might cause the client and server versions of the name got fall out of sync.
> Anyway, isn't there a good chance there is going to be Geronimo code on
> the client anyway? Given this is a proprietary protocol, there is a high
> likelihood the client is some form of Geronimo server (e.g. an
> application client, web server, another OpenEJB server, or just a
> "remote" client in-VM) and where it is a non-J2EE client then its going
> to need OpenEJB jars anyway.
At current time, there is no chance there is going to be Geronimo or even 85% of the OpenEJB code on in a non-J2EE client. We've tried really hard to keep the openejb-client jar thin and free of dependencies. Anyway, I'm getting a little off-topic.
-David
Re: GBeanName [was: svn commit: r154723...]
Posted by Jeremy Boynes <jb...@apache.org>.
Dain Sundstrom wrote:
> On Feb 23, 2005, at 9:16 AM, Jeremy Boynes wrote:
>
>> David Blevins wrote:
>>
>>> The protocol layer in OpenEJB uses the canonical string version all
>>> over the place. We avoided ObjectName on the wire as String is
>>> capable of representing an ObjectName and serializes faster and with
>>> less bytes as there is special logic in
>>> java.io.ObjectOutput/InputStream that basically treats them like
>>> primitives.
>>
>>
>> I take it you have some form of custom serialization code that
>> converts ObjectName to String and back again. GBeanName is
>> Serializable (and the serialized form is just a String) so it should
>> continue to work right now until you can add custom serialization just
>> as for ObjectName.
>
>
> OpenEJB sends the string to the client and sometimes gets a string back
> (ejbs are indexed by number for speed). When a string comes back it is
> looked up directly into a hash, keyed on the string. The means that
> OpenEJB clients do not see any Geronimo code. If GBeanNames were used,
> then the client would need a GBeanName class.
>
I don't see the issue - OpenEJB can still send Strings to the client, it
just needs to convert then into GBeanNames /back on the server/ before
looking them up in its map; or ObjectNames, or whatever it wants to key
the map on (although GBeanName seems intuitive). As you are already
assuming the client is not going to be reordering the String you send
it, then it seems to me that things would be unchanged.
Anyway, isn't there a good chance there is going to be Geronimo code on
the client anyway? Given this is a proprietary protocol, there is a high
likelihood the client is some form of Geronimo server (e.g. an
application client, web server, another OpenEJB server, or just a
"remote" client in-VM) and where it is a non-J2EE client then its going
to need OpenEJB jars anyway.
--
Jeremy
Royal Blue, with a faint hint of Aquamarine!
Re: GBeanName [was: svn commit: r154723...]
Posted by Dain Sundstrom <ds...@gluecode.com>.
On Feb 23, 2005, at 9:16 AM, Jeremy Boynes wrote:
> David Blevins wrote:
>> The protocol layer in OpenEJB uses the canonical string version all
>> over the place. We avoided ObjectName on the wire as String is
>> capable of representing an ObjectName and serializes faster and with
>> less bytes as there is special logic in
>> java.io.ObjectOutput/InputStream that basically treats them like
>> primitives.
>
> I take it you have some form of custom serialization code that
> converts ObjectName to String and back again. GBeanName is
> Serializable (and the serialized form is just a String) so it should
> continue to work right now until you can add custom serialization just
> as for ObjectName.
OpenEJB sends the string to the client and sometimes gets a string back
(ejbs are indexed by number for speed). When a string comes back it is
looked up directly into a hash, keyed on the string. The means that
OpenEJB clients do not see any Geronimo code. If GBeanNames were used,
then the client would need a GBeanName class.
-dain
Re: GBeanName [was: svn commit: r154723...]
Posted by Jeremy Boynes <jb...@apache.org>.
David Blevins wrote:
> The protocol layer in OpenEJB uses the canonical string version all over
> the place. We avoided ObjectName on the wire as String is capable of
> representing an ObjectName and serializes faster and with less bytes as
> there is special logic in java.io.ObjectOutput/InputStream that
> basically treats them like primitives.
I take it you have some form of custom serialization code that converts
ObjectName to String and back again. GBeanName is Serializable (and the
serialized form is just a String) so it should continue to work right
now until you can add custom serialization just as for ObjectName.
>
> I'm happy to see GBeanName replace ObjectName so we can have a JMX-free
> Kernel, but I don't want to GBeanName creep into places where ObjectName
> didn't need to go.
>
I don't see why it would.
--
Jeremy
Re: GBeanName [was: svn commit: r154723...]
Posted by David Blevins <db...@gluecode.com>.
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.
>
The protocol layer in OpenEJB uses the canonical string version all
over the place. We avoided ObjectName on the wire as String is capable
of representing an ObjectName and serializes faster and with less bytes
as there is special logic in java.io.ObjectOutput/InputStream that
basically treats them like primitives.
I'm happy to see GBeanName replace ObjectName so we can have a JMX-free
Kernel, but I don't want to GBeanName creep into places where
ObjectName didn't need to go.
-David
Re: GBeanName [was: svn commit: r154723...]
Posted by David Blevins <da...@visi.com>.
+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
-David
On Wed, Feb 23, 2005 at 12:23:03AM -0800, 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
> +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
> >
Re: M4 Release Issue - GBeanName Veto
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
Given it's been a while, can someone just re-explain the issue? I'm
sure we'll just fix it and move on.
geir
On Jul 11, 2005, at 5:12 PM, Alan D. Cabrera wrote:
> I've reconsidered this:
>
> +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.
>
> How hard would it be to get the GBeanName to do this?
>
>
> Regards,
> Alan
>
>
> Dain Sundstrom wrote, On 7/11/2005 10:49 AM:
>
>
>> Before we release M4 we need to resolve the standing veto against
>> geronimo/trunk/modules/kernel/src/java/org/apache/geronimo/gbean/
>> GBeanName.java
>>
>> Note the +1s below are actually -1s the removal of said feature
>> from javax.management.ObjectName, which this class replaced.
>>
>> -dain
>>
>> Begin forwarded message:
>>
>>
>>> From: "Alan D. Cabrera" <ad...@toolazydogs.com>
>>> Date: February 23, 2005 11:56:20 AM PST
>>> To: dev@geronimo.apache.org
>>> Subject: Re: GBeanName [was: svn commit: r154723...]
>>> Reply-To: dev@geronimo.apache.org
>>>
>>>
>>> +1
>>>
>>> Dain Sundstrom wrote:
>>>
>>>
>>>
>>>> For the record;
>>>>
>>>> +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.
>>>>
>>>>
>>>
>>>
>>>
>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: M4 Release Issue - GBeanName Veto
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
I've reconsidered this:
+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.
How hard would it be to get the GBeanName to do this?
Regards,
Alan
Dain Sundstrom wrote, On 7/11/2005 10:49 AM:
> Before we release M4 we need to resolve the standing veto against
> geronimo/trunk/modules/kernel/src/java/org/apache/geronimo/gbean/
> GBeanName.java
>
> Note the +1s below are actually -1s the removal of said feature from
> javax.management.ObjectName, which this class replaced.
>
> -dain
>
> Begin forwarded message:
>
>> From: "Alan D. Cabrera" <ad...@toolazydogs.com>
>> Date: February 23, 2005 11:56:20 AM PST
>> To: dev@geronimo.apache.org
>> Subject: Re: GBeanName [was: svn commit: r154723...]
>> Reply-To: dev@geronimo.apache.org
>>
>>
>> +1
>>
>> Dain Sundstrom wrote:
>>
>>
>>> For the record;
>>>
>>> +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.
>>>
>>
>>
Re: M4 Release Issue - GBeanName Veto
Posted by Dain Sundstrom <da...@iq80.com>.
On Jul 31, 2005, at 8:56 PM, Aaron Mulder wrote:
> I don't fully understand the issue, but... I think we need to
> address the -1 by either changing the offending code or convincing
> Dain
> that he should withdraw the -1. I don't think it's a very useful
> path to
> allow one group of people to vote to ignore the -1 from another
> person in
> order to get a release out.
I know you didn't mean to, but please don't pin this on me alone.
According to David Jencks there were three -1s registered, two
"concerns" without a -1, and at the time David Jencks also registered
a -1.
> Dain (-1 on behavior of toString())
> David Blevins (-1 on behavior of toString(), IIUC entirely on the
> basis of difficulties with openejb ids)
> Alan (originally -1 on behavior of toString(), now +1)
> Hiram (expressed concerns about leaking geronimo classes into
> activemq. IIUC this has to do with getCanonicalName and would be
> solved by an id converter)
> Simone (expressed concerns about implementation complexities of
> basing ObjectName implementations off of the literal string
> representation. I don't think anyone proposed doing this, but I
> could have missed something.)
Please don't shoot the messenger.
-dain
Re: M4 Release Issue - GBeanName Veto
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I don't fully understand the issue, but... I think we need to
address the -1 by either changing the offending code or convincing Dain
that he should withdraw the -1. I don't think it's a very useful path to
allow one group of people to vote to ignore the -1 from another person in
order to get a release out.
From the limited amount of information in the last couple e-mails,
I don't think any of the issues David J described sounded particulary
-1-worthy to me, but I am a little concerned by Dain's suggestion that the
current code allows a GBean Name to contain characters that are not
allowed in an ObjectName. It seems that we're very tied to ObjectNames at
the moment, and opening this loophole doesn't sound very productive. I
can see "some day" replacing ObjectNames with non-ObjectName GBean Names
as the name of record, but until we get further down that path, I'm not
sure what this is getting us.
That said, I should probably read the original thread before I
comment any more. :)
Aaron
P.S. David, your message did sound a bit over the top -- if you really
feel that way, perhaps you should have gotten some clarification from Dain
privately first? Then again, perhaps you did.
On Sun, 31 Jul 2005, Dain Sundstrom wrote:
> On Jul 31, 2005, at 4:39 PM, David Jencks wrote:
>
> > I've reviewed the original discussion on this topic. I'm rather
> > appalled that dain appears to regard this discussion as resulting
> > in a technical -1 forcing removal of the current gbean name code.
> > I would regard this attitude as an attempt to divide the geronimo
> > community in an extremely unproductive direction, so I certainly
> > hope I have misunderstood his position.
>
> That was an incredibly negative thing to write, and I take offense.
>
> To clarify, it is my understanding that the Apache Software
> Foundation will not allow us release software that has a standing
> technical veto. There are several standing technical vetos on this
> subject, and several of the +1s on this subject are +1 to put a
> feature back into the software. I understand that people don't like
> to use the -1 but a +1 to revert a change is a effectively a -1.
>
> On the exact technical subject, I am against the toString behavior,
> allowing characters that are not allowed by object names, and against
> I am against the removal of support domain queries. IIRC you were
> also against the expansion of allowed characters.
>
> Anyway, unless someone objects I'll remove the code from the M4 tree
> now. The code is very isolated and should not have an impact.
>
> -dain
>
>
Re: M4 Release Issue - GBeanName Veto
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Aug 1, 2005, at 12:41 AM, David Jencks wrote:
>
> On Jul 31, 2005, at 8:29 PM, Dain Sundstrom wrote:
>
>
>> On Jul 31, 2005, at 4:39 PM, David Jencks wrote:
>>
>>
>>> I've reviewed the original discussion on this topic. I'm rather
>>> appalled that dain appears to regard this discussion as resulting
>>> in a technical -1 forcing removal of the current gbean name
>>> code. I would regard this attitude as an attempt to divide the
>>> geronimo community in an extremely unproductive direction, so I
>>> certainly hope I have misunderstood his position.
>>>
>>
>> That was an incredibly negative thing to write, and I take offense.
>>
>> To clarify, it is my understanding that the Apache Software
>> Foundation will not allow us release software that has a standing
>> technical veto. There are several standing technical vetos on
>> this subject, and several of the +1s on this subject are +1 to put
>> a feature back into the software. I understand that people don't
>> like to use the -1 but a +1 to revert a change is a effectively a -1.
>>
>
> My apologies. Upon further thought, I realize I have often been
> using -1 (and +1 to "put it back") to mean "I think there's a
> better way to do this, lets talk about it some more" rather than
> "I'm vetoing this". I assumed with no justification everyone else
> was doing the same. But, you are completely correct, we (including
> me) did -1 some features, and according to apache rules we have to
> resolve the situation before we ship. I am going to have to be
> more careful in the future about my unwarranted assumptions.
These are our rules too :) We are them, and they is us.
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: M4 Release Issue - GBeanName Veto
Posted by David Jencks <dj...@gluecode.com>.
On Jul 31, 2005, at 8:29 PM, Dain Sundstrom wrote:
> On Jul 31, 2005, at 4:39 PM, David Jencks wrote:
>
>> I've reviewed the original discussion on this topic. I'm rather
>> appalled that dain appears to regard this discussion as resulting in
>> a technical -1 forcing removal of the current gbean name code. I
>> would regard this attitude as an attempt to divide the geronimo
>> community in an extremely unproductive direction, so I certainly hope
>> I have misunderstood his position.
>
> That was an incredibly negative thing to write, and I take offense.
>
> To clarify, it is my understanding that the Apache Software Foundation
> will not allow us release software that has a standing technical veto.
> There are several standing technical vetos on this subject, and
> several of the +1s on this subject are +1 to put a feature back into
> the software. I understand that people don't like to use the -1 but a
> +1 to revert a change is a effectively a -1.
My apologies. Upon further thought, I realize I have often been using
-1 (and +1 to "put it back") to mean "I think there's a better way to
do this, lets talk about it some more" rather than "I'm vetoing this".
I assumed with no justification everyone else was doing the same. But,
you are completely correct, we (including me) did -1 some features, and
according to apache rules we have to resolve the situation before we
ship. I am going to have to be more careful in the future about my
unwarranted assumptions.
>
> On the exact technical subject, I am against the toString behavior,
> allowing characters that are not allowed by object names, and against
> I am against the removal of support domain queries. IIRC you were
> also against the expansion of allowed characters.
>
> Anyway, unless someone objects I'll remove the code from the M4 tree
> now. The code is very isolated and should not have an impact.
I think removing it from M4 is certainly the most expedient approach
for M4. I'd like to discuss it some more and actually review the code
before we do anything in M5.
thanks
david jencks
>
> -dain
>
Re: M4 Release Issue - GBeanName Veto
Posted by David Jencks <dj...@gluecode.com>.
Just to reiterate, I support dain's action to remove this code from M4
so we can get the release out and discuss what to do in M5.
thanks
david jencks
On Aug 1, 2005, at 9:33 AM, Dain Sundstrom wrote:
> On Aug 1, 2005, at 4:17 AM, Geir Magnusson Jr. wrote:
>
>> Um - didn't you wish to discuss?
>
> I thought we wanted to get the release out. I can rollback.
>
>> How will this affect users going forward since it still is in HEAD
>> and M5?
>
> It shouldn't. My objection was to differences between ObjectName and
> GBeanName. If we address those problems in GBeanName then there will
> not be a noticeable change. If we decide to deviate from ObjectName,
> the impact has been delayed a bit.
>
> -dain
>
Re: M4 Release Issue - GBeanName Veto
Posted by Dain Sundstrom <da...@iq80.com>.
On Aug 1, 2005, at 4:17 AM, Geir Magnusson Jr. wrote:
> Um - didn't you wish to discuss?
I thought we wanted to get the release out. I can rollback.
> How will this affect users going forward since it still is in HEAD
> and M5?
It shouldn't. My objection was to differences between ObjectName and
GBeanName. If we address those problems in GBeanName then there will
not be a noticeable change. If we decide to deviate from ObjectName,
the impact has been delayed a bit.
-dain
Re: M4 Release Issue - GBeanName Veto
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
Um - didn't you wish to discuss?
How will this affect users going forward since it still is in HEAD
and M5?
On Aug 1, 2005, at 2:52 AM, Dain Sundstrom wrote:
> On Jul 31, 2005, at 8:29 PM, Dain Sundstrom wrote:
>
>
>> Anyway, unless someone objects I'll remove the code from the M4
>> tree now. The code is very isolated and should not have an impact.
>>
>
> Done. The change was very isolated, so if someone objects we can
> easily rollback.
>
> -dain
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: M4 Release Issue - GBeanName Veto
Posted by Dain Sundstrom <da...@iq80.com>.
On Jul 31, 2005, at 8:29 PM, Dain Sundstrom wrote:
> Anyway, unless someone objects I'll remove the code from the M4
> tree now. The code is very isolated and should not have an impact.
Done. The change was very isolated, so if someone objects we can
easily rollback.
-dain
Re: M4 Release Issue - GBeanName Veto
Posted by Dain Sundstrom <da...@iq80.com>.
On Jul 31, 2005, at 4:39 PM, David Jencks wrote:
> I've reviewed the original discussion on this topic. I'm rather
> appalled that dain appears to regard this discussion as resulting
> in a technical -1 forcing removal of the current gbean name code.
> I would regard this attitude as an attempt to divide the geronimo
> community in an extremely unproductive direction, so I certainly
> hope I have misunderstood his position.
That was an incredibly negative thing to write, and I take offense.
To clarify, it is my understanding that the Apache Software
Foundation will not allow us release software that has a standing
technical veto. There are several standing technical vetos on this
subject, and several of the +1s on this subject are +1 to put a
feature back into the software. I understand that people don't like
to use the -1 but a +1 to revert a change is a effectively a -1.
On the exact technical subject, I am against the toString behavior,
allowing characters that are not allowed by object names, and against
I am against the removal of support domain queries. IIRC you were
also against the expansion of allowed characters.
Anyway, unless someone objects I'll remove the code from the M4 tree
now. The code is very isolated and should not have an impact.
-dain
Re: M4 Release Issue - GBeanName Veto
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
Ok. I just got off a plane and started reading this thread. I'm a
bit fog-headed after traveling across the country on equipment that
probably could be passed by a kite ("hello? American Airlines? A
737 is a glorified regional jet, and it's time to retire the
MD-80s..."), but was doing fine until I came across this gem from
David :
"This is a reversal of my former opinion in favor of the "against"
position."
We can't blow off outstanding vetos. The veto-ers can retract them,
or we fix it.
The summary below seems to be that the outstanding vetos are Dain and
David. The code has been in there for several months now - what
problems have arisen? Do you still feel the same about the problem?
geir
On Jul 31, 2005, at 7:39 PM, David Jencks wrote:
> I've reviewed the original discussion on this topic. I'm rather
> appalled that dain appears to regard this discussion as resulting
> in a technical -1 forcing removal of the current gbean name code.
> I would regard this attitude as an attempt to divide the geronimo
> community in an extremely unproductive direction, so I certainly
> hope I have misunderstood his position.
>
> So, first of all, I consider this a pretty minor disagreement that
> we should be able to resolve by discussion at our leisure. The
> code certainly poses no risk to the functionality of M4, and since
> it isn't used, I don't see why it would be relevant to release of M4.
>
> If I understand the discussion properly, it involves what
> gbeanName.toString() should return, and whether gbeanName should
> have a getCanonicalName() method.
>
> Again IIUC, w.r.t. toString(), for a gbean name constructed by new
> GBeanName(myString), toString() returns myString. I believe the
> competing proposal is that it return a canonical form.
>
> The argument for returning the constructor argument, IIUC, is that
> if the user went to the trouble to construct a string and give it
> to us, we should remember it and be able to retrieve it.
>
> The argument against this, AFAICT, is that
> x.equals(y) implies (x.toString()).equals(y.toString())
> should hold.
>
> Personally I can see merits in both of these arguments and would
> like to see the current implementation used for a while to see if
> it causes any problems. (This is a reversal of my former opinion in
> favor of the "against" position).
>
> The getCanonicalName method existence argument appears to center on
> the current use in openejb of this string to index ejb containers.
> IIUC correctly the goal here is to avoid tying openejb and
> especially the openejb client too closely to geronimo code and
> classes. I assume that an equally strong argument can be made for
> not tying openejb equally closely with ObjectName.
>
> For this, I think there is an obvious technical solution that would
> provide plenty of other benefits, namely that to use openejb with a
> particular naming system such as jmx, gbeans, dbeans, jbeans,
> foobeans, or whatever, you supply a name to id converter that uses
> whatever black magic the naming system requires to extract a
> consistent id.
>
> I'd like to point out that something like this converter may be
> necessary even with object names, once we implement rolling
> upgrades. The only way I've thought of to implement something like
> this is to include a version key in all the gbean names (however
> implemented). An external client would not want its ejb references
> to die just because you redeployed the latest bug fix. So, some
> way of eliminating some keys from the id would be needed. Of
> course there may be other, better ways to implement rolling upgrades.
>
> My email records indicate that the original participants in the
> discussion were
> Jeremy (wrote the code in question, and I believe still thinks it
> is a good idea)
> Dain (-1 on behavior of toString())
> David Blevins (-1 on behavior of toString(), IIUC entirely on the
> basis of difficulties with openejb ids)
> David Jencks (originally -1 on behavior of toString(), now +1
> until an actual problem arises)
> Alan (originally -1 on behavior of toString(), now +1)
> Geir (IIUC +1 on behavior of toString())
> Hiram (expressed concerns about leaking geronimo classes into
> activemq. IIUC this has to do with getCanonicalName and would be
> solved by an id converter)
> Simone (expressed concerns about implementation complexities of
> basing ObjectName implementations off of the literal string
> representation. I don't think anyone proposed doing this, but I
> could have missed something.)
>
> The original discussion was from Feb 22 to 23 with the subjects
> Re: svn commit: r154723 - in geronimo/trunk/modules/kernel/src:
> java/org/apache/geronimo/gbean/GBeanName.java test/org/apache/
> geronimo/gbean/GBeanNameTest.java
> Re: GBeanName [was: svn commit: r154723...]
>
> and on july 11 with the subject
> M4 Release Issue - GBeanName Veto
>
> I propose we all agree this is a non-critical issue and work on
> getting M4 out.
>
> thanks
> david jencks
>
> On Jul 11, 2005, at 10:49 AM, Dain Sundstrom wrote:
>
>
>> Before we release M4 we need to resolve the standing veto against
>> geronimo/trunk/modules/kernel/src/java/org/apache/geronimo/gbean/
>> GBeanName.java
>>
>> Note the +1s below are actually -1s the removal of said feature
>> from javax.management.ObjectName, which this class replaced.
>>
>> -dain
>>
>> Begin forwarded message:
>>
>>
>>> From: "Alan D. Cabrera" <ad...@toolazydogs.com>
>>> Date: February 23, 2005 11:56:20 AM PST
>>> To: dev@geronimo.apache.org
>>> Subject: Re: GBeanName [was: svn commit: r154723...]
>>> Reply-To: dev@geronimo.apache.org
>>>
>>>
>>> +1
>>>
>>> Dain Sundstrom wrote:
>>>
>>>
>>>
>>>> For the record;
>>>>
>>>> +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.
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: M4 Release Issue - GBeanName Veto
Posted by Davanum Srinivas <da...@gmail.com>.
+1 (I propose we all agree this is a non-critical issue and work on
getting M4 out.)
On 7/31/05, David Jencks <da...@yahoo.com> wrote:
> I've reviewed the original discussion on this topic. I'm rather
> appalled that dain appears to regard this discussion as resulting in a
> technical -1 forcing removal of the current gbean name code. I would
> regard this attitude as an attempt to divide the geronimo community in
> an extremely unproductive direction, so I certainly hope I have
> misunderstood his position.
>
> So, first of all, I consider this a pretty minor disagreement that we
> should be able to resolve by discussion at our leisure. The code
> certainly poses no risk to the functionality of M4, and since it isn't
> used, I don't see why it would be relevant to release of M4.
>
> If I understand the discussion properly, it involves what
> gbeanName.toString() should return, and whether gbeanName should have a
> getCanonicalName() method.
>
> Again IIUC, w.r.t. toString(), for a gbean name constructed by new
> GBeanName(myString), toString() returns myString. I believe the
> competing proposal is that it return a canonical form.
>
> The argument for returning the constructor argument, IIUC, is that if
> the user went to the trouble to construct a string and give it to us,
> we should remember it and be able to retrieve it.
>
> The argument against this, AFAICT, is that
> x.equals(y) implies (x.toString()).equals(y.toString())
> should hold.
>
> Personally I can see merits in both of these arguments and would like
> to see the current implementation used for a while to see if it causes
> any problems. (This is a reversal of my former opinion in favor of the
> "against" position).
>
> The getCanonicalName method existence argument appears to center on the
> current use in openejb of this string to index ejb containers. IIUC
> correctly the goal here is to avoid tying openejb and especially the
> openejb client too closely to geronimo code and classes. I assume that
> an equally strong argument can be made for not tying openejb equally
> closely with ObjectName.
>
> For this, I think there is an obvious technical solution that would
> provide plenty of other benefits, namely that to use openejb with a
> particular naming system such as jmx, gbeans, dbeans, jbeans, foobeans,
> or whatever, you supply a name to id converter that uses whatever black
> magic the naming system requires to extract a consistent id.
>
> I'd like to point out that something like this converter may be
> necessary even with object names, once we implement rolling upgrades.
> The only way I've thought of to implement something like this is to
> include a version key in all the gbean names (however implemented). An
> external client would not want its ejb references to die just because
> you redeployed the latest bug fix. So, some way of eliminating some
> keys from the id would be needed. Of course there may be other,
> better ways to implement rolling upgrades.
>
> My email records indicate that the original participants in the
> discussion were
> Jeremy (wrote the code in question, and I believe still thinks it is a
> good idea)
> Dain (-1 on behavior of toString())
> David Blevins (-1 on behavior of toString(), IIUC entirely on the basis
> of difficulties with openejb ids)
> David Jencks (originally -1 on behavior of toString(), now +1 until an
> actual problem arises)
> Alan (originally -1 on behavior of toString(), now +1)
> Geir (IIUC +1 on behavior of toString())
> Hiram (expressed concerns about leaking geronimo classes into activemq.
> IIUC this has to do with getCanonicalName and would be solved by an id
> converter)
> Simone (expressed concerns about implementation complexities of basing
> ObjectName implementations off of the literal string representation. I
> don't think anyone proposed doing this, but I could have missed
> something.)
>
> The original discussion was from Feb 22 to 23 with the subjects
> Re: svn commit: r154723 - in geronimo/trunk/modules/kernel/src:
> java/org/apache/geronimo/gbean/GBeanName.java
> test/org/apache/geronimo/gbean/GBeanNameTest.java
> Re: GBeanName [was: svn commit: r154723...]
>
> and on july 11 with the subject
> M4 Release Issue - GBeanName Veto
>
> I propose we all agree this is a non-critical issue and work on getting
> M4 out.
>
> thanks
> david jencks
>
> On Jul 11, 2005, at 10:49 AM, Dain Sundstrom wrote:
>
> > Before we release M4 we need to resolve the standing veto against
> > geronimo/trunk/modules/kernel/src/java/org/apache/geronimo/gbean/
> > GBeanName.java
> >
> > Note the +1s below are actually -1s the removal of said feature from
> > javax.management.ObjectName, which this class replaced.
> >
> > -dain
> >
> > Begin forwarded message:
> >
> >> From: "Alan D. Cabrera" <ad...@toolazydogs.com>
> >> Date: February 23, 2005 11:56:20 AM PST
> >> To: dev@geronimo.apache.org
> >> Subject: Re: GBeanName [was: svn commit: r154723...]
> >> Reply-To: dev@geronimo.apache.org
> >>
> >>
> >> +1
> >>
> >> Dain Sundstrom wrote:
> >>
> >>
> >>> For the record;
> >>>
> >>> +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.
> >>>
> >>
> >>
> >
>
>
--
Davanum Srinivas -http://blogs.cocoondev.org/dims/
Re: M4 Release Issue - GBeanName Veto
Posted by David Jencks <da...@yahoo.com>.
I've reviewed the original discussion on this topic. I'm rather
appalled that dain appears to regard this discussion as resulting in a
technical -1 forcing removal of the current gbean name code. I would
regard this attitude as an attempt to divide the geronimo community in
an extremely unproductive direction, so I certainly hope I have
misunderstood his position.
So, first of all, I consider this a pretty minor disagreement that we
should be able to resolve by discussion at our leisure. The code
certainly poses no risk to the functionality of M4, and since it isn't
used, I don't see why it would be relevant to release of M4.
If I understand the discussion properly, it involves what
gbeanName.toString() should return, and whether gbeanName should have a
getCanonicalName() method.
Again IIUC, w.r.t. toString(), for a gbean name constructed by new
GBeanName(myString), toString() returns myString. I believe the
competing proposal is that it return a canonical form.
The argument for returning the constructor argument, IIUC, is that if
the user went to the trouble to construct a string and give it to us,
we should remember it and be able to retrieve it.
The argument against this, AFAICT, is that
x.equals(y) implies (x.toString()).equals(y.toString())
should hold.
Personally I can see merits in both of these arguments and would like
to see the current implementation used for a while to see if it causes
any problems. (This is a reversal of my former opinion in favor of the
"against" position).
The getCanonicalName method existence argument appears to center on the
current use in openejb of this string to index ejb containers. IIUC
correctly the goal here is to avoid tying openejb and especially the
openejb client too closely to geronimo code and classes. I assume that
an equally strong argument can be made for not tying openejb equally
closely with ObjectName.
For this, I think there is an obvious technical solution that would
provide plenty of other benefits, namely that to use openejb with a
particular naming system such as jmx, gbeans, dbeans, jbeans, foobeans,
or whatever, you supply a name to id converter that uses whatever black
magic the naming system requires to extract a consistent id.
I'd like to point out that something like this converter may be
necessary even with object names, once we implement rolling upgrades.
The only way I've thought of to implement something like this is to
include a version key in all the gbean names (however implemented). An
external client would not want its ejb references to die just because
you redeployed the latest bug fix. So, some way of eliminating some
keys from the id would be needed. Of course there may be other,
better ways to implement rolling upgrades.
My email records indicate that the original participants in the
discussion were
Jeremy (wrote the code in question, and I believe still thinks it is a
good idea)
Dain (-1 on behavior of toString())
David Blevins (-1 on behavior of toString(), IIUC entirely on the basis
of difficulties with openejb ids)
David Jencks (originally -1 on behavior of toString(), now +1 until an
actual problem arises)
Alan (originally -1 on behavior of toString(), now +1)
Geir (IIUC +1 on behavior of toString())
Hiram (expressed concerns about leaking geronimo classes into activemq.
IIUC this has to do with getCanonicalName and would be solved by an id
converter)
Simone (expressed concerns about implementation complexities of basing
ObjectName implementations off of the literal string representation. I
don't think anyone proposed doing this, but I could have missed
something.)
The original discussion was from Feb 22 to 23 with the subjects
Re: svn commit: r154723 - in geronimo/trunk/modules/kernel/src:
java/org/apache/geronimo/gbean/GBeanName.java
test/org/apache/geronimo/gbean/GBeanNameTest.java
Re: GBeanName [was: svn commit: r154723...]
and on july 11 with the subject
M4 Release Issue - GBeanName Veto
I propose we all agree this is a non-critical issue and work on getting
M4 out.
thanks
david jencks
On Jul 11, 2005, at 10:49 AM, Dain Sundstrom wrote:
> Before we release M4 we need to resolve the standing veto against
> geronimo/trunk/modules/kernel/src/java/org/apache/geronimo/gbean/
> GBeanName.java
>
> Note the +1s below are actually -1s the removal of said feature from
> javax.management.ObjectName, which this class replaced.
>
> -dain
>
> Begin forwarded message:
>
>> From: "Alan D. Cabrera" <ad...@toolazydogs.com>
>> Date: February 23, 2005 11:56:20 AM PST
>> To: dev@geronimo.apache.org
>> Subject: Re: GBeanName [was: svn commit: r154723...]
>> Reply-To: dev@geronimo.apache.org
>>
>>
>> +1
>>
>> Dain Sundstrom wrote:
>>
>>
>>> For the record;
>>>
>>> +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.
>>>
>>
>>
>
Re: M4 Release Issue - GBeanName Veto
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
Is that one that boils down to the belief that
a.equals(b) <-> a.toString().equals(b.toString())
?
On Jul 11, 2005, at 1:49 PM, Dain Sundstrom wrote:
> Before we release M4 we need to resolve the standing veto against
> geronimo/trunk/modules/kernel/src/java/org/apache/geronimo/gbean/
> GBeanName.java
>
> Note the +1s below are actually -1s the removal of said feature
> from javax.management.ObjectName, which this class replaced.
>
> -dain
>
> Begin forwarded message:
>
>
>> From: "Alan D. Cabrera" <ad...@toolazydogs.com>
>> Date: February 23, 2005 11:56:20 AM PST
>> To: dev@geronimo.apache.org
>> Subject: Re: GBeanName [was: svn commit: r154723...]
>> Reply-To: dev@geronimo.apache.org
>>
>>
>> +1
>>
>> Dain Sundstrom wrote:
>>
>>
>>
>>> For the record;
>>>
>>> +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.
>>>
>>>
>>
>>
>>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: M4 Release Issue - GBeanName Veto
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 11, 2005, at 7:18 PM, David Blevins wrote:
> On Mon, Jul 11, 2005 at 06:38:39PM -0400, Geir Magnusson Jr. wrote:
>
>>
>> On Jul 11, 2005, at 4:45 PM, David Blevins wrote:
>>
>>
>>> On Mon, Jul 11, 2005 at 09:43:46PM +0200, Jacek Laskowski wrote:
>>>
>>>
>>>> Dain Sundstrom wrote:
>>>>
>>>>
>>>>> Before we release M4 we need to resolve the standing veto against
>>>>> geronimo/trunk/modules/kernel/src/java/org/apache/geronimo/gbean/
>>>>> GBeanName.java
>>>>>
>>>>> Note the +1s below are actually -1s the removal of said feature
>>>>> from
>>>>> javax.management.ObjectName, which this class replaced.
>>>>>
>>>>>
>>>>
>>>> Well, I don't see 0 as the 'I don't know/care' option, which I'm
>>>> not
>>>> very happy with. I seem to be unconscious of what the change would
>>>> result in. Would you provide more information to let me vote for or
>>>> against it *or* provide the 0 option.
>>>>
>>>>
>>>
>>> You can always vote anywhere in the range of +1 through -1,
>>> including fractionally like +0.9 or -0.5.
>>>
>>
>> I think fractions are confusing and I've never really seen them used
>> often. I tend to think conventional patterns like the following are
>> clearer :
>>
>> +1 : yes
>> +0 : yes, but I'm not helping
>> 0 : no opinion
>> -0 : no, but I'm not going to stand in the way
>> -1 : no
>>
>>
>
> I agree. Was just pointing out to Jacek that he can vote 0 if he
> wants too -- it's always an option even if not listed.
Agreed.
>
> -David
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: M4 Release Issue - GBeanName Veto
Posted by David Blevins <da...@visi.com>.
On Mon, Jul 11, 2005 at 06:38:39PM -0400, Geir Magnusson Jr. wrote:
>
> On Jul 11, 2005, at 4:45 PM, David Blevins wrote:
>
> >On Mon, Jul 11, 2005 at 09:43:46PM +0200, Jacek Laskowski wrote:
> >
> >>Dain Sundstrom wrote:
> >>
> >>>Before we release M4 we need to resolve the standing veto against
> >>>geronimo/trunk/modules/kernel/src/java/org/apache/geronimo/gbean/
> >>>GBeanName.java
> >>>
> >>>Note the +1s below are actually -1s the removal of said feature from
> >>>javax.management.ObjectName, which this class replaced.
> >>>
> >>
> >>Well, I don't see 0 as the 'I don't know/care' option, which I'm not
> >>very happy with. I seem to be unconscious of what the change would
> >>result in. Would you provide more information to let me vote for or
> >>against it *or* provide the 0 option.
> >>
> >
> >You can always vote anywhere in the range of +1 through -1,
> >including fractionally like +0.9 or -0.5.
>
> I think fractions are confusing and I've never really seen them used
> often. I tend to think conventional patterns like the following are
> clearer :
>
> +1 : yes
> +0 : yes, but I'm not helping
> 0 : no opinion
> -0 : no, but I'm not going to stand in the way
> -1 : no
>
I agree. Was just pointing out to Jacek that he can vote 0 if he
wants too -- it's always an option even if not listed.
-David
Re: M4 Release Issue - GBeanName Veto
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 11, 2005, at 4:45 PM, David Blevins wrote:
> On Mon, Jul 11, 2005 at 09:43:46PM +0200, Jacek Laskowski wrote:
>
>> Dain Sundstrom wrote:
>>
>>> Before we release M4 we need to resolve the standing veto against
>>> geronimo/trunk/modules/kernel/src/java/org/apache/geronimo/gbean/
>>> GBeanName.java
>>>
>>> Note the +1s below are actually -1s the removal of said feature from
>>> javax.management.ObjectName, which this class replaced.
>>>
>>
>> Well, I don't see 0 as the 'I don't know/care' option, which I'm not
>> very happy with. I seem to be unconscious of what the change would
>> result in. Would you provide more information to let me vote for or
>> against it *or* provide the 0 option.
>>
>
> You can always vote anywhere in the range of +1 through -1,
> including fractionally like +0.9 or -0.5.
I think fractions are confusing and I've never really seen them used
often. I tend to think conventional patterns like the following are
clearer :
+1 : yes
+0 : yes, but I'm not helping
0 : no opinion
-0 : no, but I'm not going to stand in the way
-1 : no
geir
>
> http://www.apache.org/foundation/voting.html
>
>
> -David
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: M4 Release Issue - GBeanName Veto
Posted by David Blevins <da...@visi.com>.
On Mon, Jul 11, 2005 at 09:43:46PM +0200, Jacek Laskowski wrote:
> Dain Sundstrom wrote:
> >Before we release M4 we need to resolve the standing veto against
> >geronimo/trunk/modules/kernel/src/java/org/apache/geronimo/gbean/
> >GBeanName.java
> >
> >Note the +1s below are actually -1s the removal of said feature from
> >javax.management.ObjectName, which this class replaced.
>
> Well, I don't see 0 as the 'I don't know/care' option, which I'm not
> very happy with. I seem to be unconscious of what the change would
> result in. Would you provide more information to let me vote for or
> against it *or* provide the 0 option.
You can always vote anywhere in the range of +1 through -1, including fractionally like +0.9 or -0.5.
http://www.apache.org/foundation/voting.html
-David
Re: M4 Release Issue - GBeanName Veto
Posted by Jacek Laskowski <jl...@apache.org>.
Dain Sundstrom wrote:
> Before we release M4 we need to resolve the standing veto against
> geronimo/trunk/modules/kernel/src/java/org/apache/geronimo/gbean/
> GBeanName.java
>
> Note the +1s below are actually -1s the removal of said feature from
> javax.management.ObjectName, which this class replaced.
Well, I don't see 0 as the 'I don't know/care' option, which I'm not
very happy with. I seem to be unconscious of what the change would
result in. Would you provide more information to let me vote for or
against it *or* provide the 0 option.
> -dain
Jacek
M4 Release Issue - GBeanName Veto
Posted by Dain Sundstrom <ds...@gluecode.com>.
Before we release M4 we need to resolve the standing veto against
geronimo/trunk/modules/kernel/src/java/org/apache/geronimo/gbean/
GBeanName.java
Note the +1s below are actually -1s the removal of said feature from
javax.management.ObjectName, which this class replaced.
-dain
Begin forwarded message:
> From: "Alan D. Cabrera" <ad...@toolazydogs.com>
> Date: February 23, 2005 11:56:20 AM PST
> To: dev@geronimo.apache.org
> Subject: Re: GBeanName [was: svn commit: r154723...]
> Reply-To: dev@geronimo.apache.org
>
>
> +1
>
> Dain Sundstrom wrote:
>
>
>> For the record;
>>
>> +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.
>>
>
>
Re: GBeanName [was: svn commit: r154723...]
Posted by "Alan D. Cabrera" <ad...@toolazydogs.com>.
+1
Dain Sundstrom wrote:
> For the record;
>
> +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.
Re: GBeanName [was: svn commit: r154723...]
Posted by Dain Sundstrom <ds...@gluecode.com>.
For the record;
+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.
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?
I am making the argument that we MUST have a canonical form, so my
question is why must we keep two strings around just to for display
purposes.
>> +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.
That is not true. There is no escaping mechanism in ObjectName for
domain names and key names, only for key value, so without restricting
the type to be a true subset of ObjectName and enforcing that
restriction, it would be possible to create names that cannot be
represented in JMX.
-dain
Re: GBeanName [was: svn commit: r154723...]
Posted by David Jencks <dj...@gluecode.com>.
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
>
Re: GBeanName [was: svn commit: r154723...]
Posted by "Alan D. Cabrera" <ad...@toolazydogs.com>.
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?
I would think that rearranging the string would reinforce the idea that
GBeanName will canonicalize what ever you put into it.
Regards,
Alan
Re: GBeanName [was: svn commit: r154723...]
Posted by Jeremy Boynes <jb...@apache.org>.
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?
> +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.
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
Re: GBeanName [was: svn commit: r154723...]
Posted by Dain Sundstrom <ds...@gluecode.com>.
On Feb 23, 2005, at 3:07 PM, Geir Magnusson Jr wrote:
> On Feb 23, 2005, at 11:46 AM, Dain Sundstrom wrote:
>>
>> That of course means that someone would have to define their own
>> types, and the latest changes by David Jencks make defining your own
>> types the norm. With his code you no longer declare an entire object
>> name for a gbean. Instead you just define an instance name and type
>> (the type is actually extracted from the GBeanInfo). So we are doing
>> everything possible to encourage the use of the JSR77 name hierarchy,
>> by making it the simplest and most natural configuration style.
>
> But we shouldn't require it for the container. Great for J2EE, but
> could be utterly useless for someone else.
I hope I did not give the impression that a name format is required; it
is just encouraged.
I disagree with the statement that a name hierarchy is useless for
anything but J2EE. To the contrary, I believe that it is useful to
everyone. Without a well understood hierarchy, a user will be
presented with thousands of components with no categorization, and this
makes for a pretty unusable system. After discussions with the James
team, I am very confident that JSR77 naming rules will map well to
their avalon based configs. It should also map well to Pico and
Spring. The idea is to encourage use with a bit of sugar by making it
the simplest and most powerful way to organize your components.
>> In the case where, they don't follow the JSR77 rules, the GBean
>> specific console would have to fall back to a default sorting rule.
>> This ugly display in the console would further encourage people to
>> use JSR77 names.
>
> Or they would just fix the console
Exactly. If the categorization rules did not map well to their system,
they would write a new sorter plugin and get the display just the way
they want it. If you have time, please take a look at the the new
configuration stuff David Jencks put in, and I bet you will see how
simple it is to use a hierarchy based name system.
-dain
Re: GBeanName [was: svn commit: r154723...]
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Feb 23, 2005, at 11:46 AM, Dain Sundstrom wrote:
> On Feb 23, 2005, at 10:59 AM, Geir Magnusson Jr wrote:
>
>> On Feb 23, 2005, at 10:14 AM, Dain Sundstrom wrote:
>>
>>> On Feb 23, 2005, at 9:24 AM, Geir Magnusson Jr wrote:
>>>
>>>>
>>>> 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...
>>>
>>> You're assuming that we build JSR77 names in a canonical format, and
>>> we don't. It is the job of the console to format a name into
>>> something readable by a user. IMO this is a tree and not a list of
>>> 200 character names.
>>
>> But I don't assume that geronimo is only used for things where JSR77
>> is relevant...
>>
>> I think it's really important that we remember how useful the
>> Geronimo container is w/o J2EE...
>
> Very good point.
>
> Of course, I'd like to challenge you assumption again ;) It seems to
> me that your assuming people will use GBeans without JSR77 style
> names. JSR77 not only address exactly what names must be used (e.g.,
> j2eeType=StatelessSessionBean), it also defines a way to buildup a
> name hierarchy. The rules for the name construction define a natural
> hierarchy that "falls out" from a few simple rules (I can go into the
> rules if you want). This means that you can easily define your own
> types and a smart console will be able to build it into a tree.
>
> That of course means that someone would have to define their own
> types, and the latest changes by David Jencks make defining your own
> types the norm. With his code you no longer declare an entire object
> name for a gbean. Instead you just define an instance name and type
> (the type is actually extracted from the GBeanInfo). So we are doing
> everything possible to encourage the use of the JSR77 name hierarchy,
> by making it the simplest and most natural configuration style.
But we shouldn't require it for the container. Great for J2EE, but
could be utterly useless for someone else.
>
> In the case where, they don't follow the JSR77 rules, the GBean
> specific console would have to fall back to a default sorting rule.
> This ugly display in the console would further encourage people to use
> JSR77 names.
Or they would just fix the console
>
> -dain
>
>
>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geir@gluecode.com
Re: GBeanName [was: svn commit: r154723...]
Posted by Dain Sundstrom <ds...@gluecode.com>.
On Feb 23, 2005, at 10:59 AM, Geir Magnusson Jr wrote:
> On Feb 23, 2005, at 10:14 AM, Dain Sundstrom wrote:
>
>> On Feb 23, 2005, at 9:24 AM, Geir Magnusson Jr wrote:
>>
>>>
>>> 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...
>>
>> You're assuming that we build JSR77 names in a canonical format, and
>> we don't. It is the job of the console to format a name into
>> something readable by a user. IMO this is a tree and not a list of
>> 200 character names.
>
> But I don't assume that geronimo is only used for things where JSR77
> is relevant...
>
> I think it's really important that we remember how useful the Geronimo
> container is w/o J2EE...
Very good point.
Of course, I'd like to challenge you assumption again ;) It seems to
me that your assuming people will use GBeans without JSR77 style names.
JSR77 not only address exactly what names must be used (e.g.,
j2eeType=StatelessSessionBean), it also defines a way to buildup a name
hierarchy. The rules for the name construction define a natural
hierarchy that "falls out" from a few simple rules (I can go into the
rules if you want). This means that you can easily define your own
types and a smart console will be able to build it into a tree.
That of course means that someone would have to define their own types,
and the latest changes by David Jencks make defining your own types the
norm. With his code you no longer declare an entire object name for a
gbean. Instead you just define an instance name and type (the type is
actually extracted from the GBeanInfo). So we are doing everything
possible to encourage the use of the JSR77 name hierarchy, by making it
the simplest and most natural configuration style.
In the case where, they don't follow the JSR77 rules, the GBean
specific console would have to fall back to a default sorting rule.
This ugly display in the console would further encourage people to use
JSR77 names.
-dain
Re: GBeanName [was: svn commit: r154723...]
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Feb 23, 2005, at 10:14 AM, Dain Sundstrom wrote:
> On Feb 23, 2005, at 9:24 AM, Geir Magnusson Jr wrote:
>
>>
>> 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...
>
> You're assuming that we build JSR77 names in a canonical format, and
> we don't. It is the job of the console to format a name into
> something readable by a user. IMO this is a tree and not a list of
> 200 character names.
But I don't assume that geronimo is only used for things where JSR77 is
relevant...
I think it's really important that we remember how useful the Geronimo
container is w/o J2EE...
geir
>
> -dain
>
>
--
Geir Magnusson Jr +1-203-665-6437
geir@gluecode.com
Re: GBeanName [was: svn commit: r154723...]
Posted by Dain Sundstrom <ds...@gluecode.com>.
On Feb 23, 2005, at 9:24 AM, Geir Magnusson Jr wrote:
>
> 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...
You're assuming that we build JSR77 names in a canonical format, and we
don't. It is the job of the console to format a name into something
readable by a user. IMO this is a tree and not a list of 200 character
names.
-dain
Re: GBeanName [was: svn commit: r154723...]
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
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:
>>>>> 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
>>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geir@gluecode.com
Re: GBeanName [was: svn commit: r154723...]
Posted by David Jencks <da...@yahoo.com>.
+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
>
Re: GBeanName [was: svn commit: r154723...]
Posted by Dain Sundstrom <ds...@gluecode.com>.
On Feb 23, 2005, at 9:35 AM, Jeremy Boynes wrote:
> Dain Sundstrom wrote:
>>> 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.
>
> Well they could, but I'm kind of disappointed that you don't think I
> would consider that and avoid it; especially as I'm trying to make
> this change in a way that's /as least disruptive as possible/.
The discussion has shown, that you do not believe that a canonical
format is necessary, which it is, so this isn't a matter of trust.
>> If you want, I'll implement the class and make the changes.
>
> Perhaps we should conclude this discussion first, and besides, I
> thought you were busy working on other things ...
Not really. I have plenty of time to work on stuff like this.
-dain
Re: GBeanName [was: svn commit: r154723...]
Posted by Jeremy Boynes <jb...@apache.org>.
Dain Sundstrom wrote:
>> 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.
>
Well they could, but I'm kind of disappointed that you don't think I
would consider that and avoid it; especially as I'm trying to make this
change in a way that's /as least disruptive as possible/.
> If you want, I'll implement the class and make the changes.
>
Perhaps we should conclude this discussion first, and besides, I thought
you were busy working on other things ...
--
Jeremy
Red!
Re: GBeanName [was: svn commit: r154723...]
Posted by Jeremy Boynes <jb...@apache.org>.
Dain Sundstrom wrote:
>
> My point is that your argument is invalid. There is no guarantee in
> java that x.equals(new SomeClass(x).toString()) is ever true.
>
It is for String :-)
My point here is that preserving the supplied name is useful, the order
is irrelevant to the implementation so there is no reason not to
preserve it.
>> 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.
>
77 names are one use case, there are likely to be others which the
console does not understand. There is no reason here to discard the
ordering provided by the user.
--
Jeremy
Re: GBeanName [was: svn commit: r154723...]
Posted by Dain Sundstrom <ds...@gluecode.com>.
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
Re: GBeanName [was: svn commit: r154723...]
Posted by Jeremy Boynes <jb...@apache.org>.
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
Re: GBeanName [was: svn commit: r154723...]
Posted by Dain Sundstrom <ds...@gluecode.com>.
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?
>> 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.
>> 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.
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.
> 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.
> 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.
>> 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.
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.
> 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
Re: svn commit: r154723 - in geronimo/trunk/modules/kernel/src: java/org/apache/geronimo/gbean/GBeanName.java
test/org/apache/geronimo/gbean/GBeanNameTest.java
Posted by Jeremy Boynes <jb...@apache.org>.
Dain Sundstrom wrote:
> I think we will need a canonical form.
Why?
> 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.
> 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())
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.
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.
> 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.
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.
KISS
--
Jeremy
Re: svn commit: r154723 - in geronimo/trunk/modules/kernel/src: java/org/apache/geronimo/gbean/GBeanName.java test/org/apache/geronimo/gbean/GBeanNameTest.java
Posted by Dain Sundstrom <ds...@gluecode.com>.
I think we will need a canonical form. There are many places that key
stuff off the string canonical form of the object name. 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. Also I would hope the canonical form is the same as
object name.
One other thing, it doesn't look like this is escaping key values, or
checking for illegal characters.
-dain
--
Dain Sundstrom
Chief Architect
Gluecode Software
310.536.8355, ext. 26