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" <[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.
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
