You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Dain Sundstrom <ds...@gluecode.com> on 2005/07/11 19:49:06 UTC
M4 Release Issue - GBeanName Veto
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>.
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