+1 (I propose we all agree this is a non-critical issue and work on getting M4 out.)
On 7/31/05, David Jencks <[EMAIL PROTECTED]> 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. > >>> > >> > >> > > > > -- Davanum Srinivas -http://blogs.cocoondev.org/dims/
