beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daryl Olander <dolan...@gmail.com>
Subject Re: [VOTE] Binary compat breaking fix for o.a.b.c.spi.svc.ControlInterceptor
Date Fri, 13 Jan 2006 23:49:39 GMT
This is a pretty interesting issue.  I do agree that we should do the change
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 using
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'll
> > > > 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 going
> > > > 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. This
> > looks
> > > > > inconsistent to me. Imagine that you need to enforce J2EE
> > transaction
> > > > > behaviors using these interceptors (i.e. rollback a transaction in
> > 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
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message