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" <[EMAIL PROTECTED]>
Date: February 23, 2005 11:56:20 AM PST
To: [email protected]
Subject: Re: GBeanName [was: svn commit: r154723...]
Reply-To: [email protected]
+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.
