Mailing-List: contact dev-help@beehive.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Beehive Developers" <dev@beehive.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of dolander@gmail.com designates
 66.249.82.195 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=Httgla58evCiYPR+WANRsybBtJWZihCz7nSDHO2BbQGPzze/1TJHaFFeHODGHaRO7EGhUofhLY/xy791k7SCBFXRxlfyqYpoNWA5pULFBnG0T1wdSnfEg1PmZMprzWgr7ZyHiUMsS2j6Fj73ESxlsqm3Dm+MGf6Tqvq+fjFiG1g=
Message-ID: <40f026540601131549n4a7567d6q1d0c1c61d8f52e55@mail.gmail.com>
Date: Fri, 13 Jan 2006 16:49:39 -0700
From: Daryl Olander <dolander@gmail.com>
To: Beehive Developers <dev@beehive.apache.org>
Subject: Re: [VOTE] Binary compat breaking fix for
 o.a.b.c.spi.svc.ControlInterceptor
In-Reply-To: <350ef8d0601131401j1780e859n626a93b62e820010@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_1165_13754929.1137196179256"
References: <e52f74f80601131356s76e34cd7y396d09fc118b3e77@mail.gmail.com>
	 <350ef8d0601131401j1780e859n626a93b62e820010@mail.gmail.com>

------=_Part_1165_13754929.1137196179256
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This is a pretty interesting issue.  I do agree that we should do the chang=
e
given the description, but I'm not sure about setting a precedence like
this.  In the future, more and more advanced features will have people usin=
g
them.  It's a big price to pay though to add another interface to correct
this problem.

Right now, I'm going to vote as
+0

but I may change my mind as people respond to this thread.

On 1/13/06, Xibin Zeng <xibin.zeng@gmail.com> wrote:
>
> +1 (non-committer vote)
>
> On 1/13/06, Kenneth Tam <kentaminator@gmail.com> wrote:
> >
> > The main concern here is that as an SPI change, it'll break binary
> > backwards compat.  The classic way to handle this would be to rev the
> > interface with e.g. ControlInterceptor2 and require you to implement
> > the newer interface in order to get the new param.
> >
> > Our general guiding policy in Beehive has been to _not_ break binary
> > compat within a major release (which would apply to this upcoming dot
> > release).  That said, I agree this is a very localized change -- it
> > basically only affects anyone extending Beehive via annotation based
> > interceptors (a very advanced use-case) and thus had an implementation
> > of this interface.  Those folks would simply need to modify their
> > implementation's signature and recompile.  I propose a vote:
> >
> > [ ] Accept a fix to o.a.b.c.spi.svc.ControlInterceptor that adds a
> > param to the signature, thus breaking binary compat with previously
> > release versions of Beehive.
> >
> > If this gets voted down, I will go ahead with adding a new
> > ControlInterceptor2 interface and appropriate support.
> >
> > thanks,
> > k
> >
> >
> >
> > On 1/11/06, Xibin Zeng <xibin.zeng@gmail.com> wrote:
> > > Hey Ken -
> > >
> > > Thanks for your reply. I'm glad that you are willing to fix this
> problem
> > and
> > > appreciate it.
> > >
> > > To the devs on the list, are there any problems if Ken made this fix
> in
> > for
> > > the current dot release? This would help me a lot, and I think it is =
a
> > > localized change that has minimal impact other areas.
> > >
> > > Your opinion?
> > >
> > > Thanks
> > > Xibin
> > >
> > > On 1/11/06, Kenneth Tam <kentaminator@gmail.com> wrote:
> > > >
> > > > Hey Xibin,
> > > >
> > > > Good catch -- this was just oversight.  You're absolutely right,
> > > > postEvent should also have a Throwable param in its signature.  I'l=
l
> > > > be happy to make this change, but I'm not completely on top of the
> > > > dot-release cycle right now, so I want to make sure this isn't goin=
g
> > > > to give anyone problems right now before actually submitting.
> > > >
> > > > thanks,
> > > > k
> > > >
> > > > On 1/10/06, Xibin Zeng <xibin.zeng@gmail.com> wrote:
> > > > > Hi -
> > > > >
> > > > > There are 4 methods on the
> > > > > org.apache.beehive.controls.spi.svc.Interceptorinterface. For a
> > > > > control operation, preInvoke/postInvoke are called before
> > > > > and after the operation, respectively. The postInvoke callback
> > contains
> > > > the
> > > > > exception that the operation threw. For preEvent/postEvent,
> however,
> > > > there
> > > > > is no exception information passed to the postEvent callback. Thi=
s
> > looks
> > > > > inconsistent to me. Imagine that you need to enforce J2EE
> > transaction
> > > > > behaviors using these interceptors (i.e. rollback a transaction i=
n
> > case
> > > > of a
> > > > > system exception), you will need to know what exception has been
> > > > generated
> > > > > as the result of invoking the operation or event callback. You
> could
> > do
> > > > this
> > > > > for your control operations, but not event callbacks, since the
> > > > exception
> > > > > caught during event callback isn't passsed to the interceptor.
> > > > >
> > > > > There might be reasons why Beehive chose to implement the 2 sets
> of
> > API
> > > > > differently. In my humble opinion, I think we should make them
> > > > symmetric. If
> > > > > I missed something here, please let me know.
> > > > >
> > > > > Thanks
> > > > > Xibin Zeng
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>

------=_Part_1165_13754929.1137196179256--