beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kenneth Tam <kentamina...@gmail.com>
Subject Re: [VOTE] Binary compat breaking fix for o.a.b.c.spi.svc.ControlInterceptor
Date Tue, 24 Jan 2006 20:14:51 GMT
Yup, I was thinking the same thing (adding the return value as well as
the throwable).

I am trying to decide what to do about exceptions thrown out of
multicast events.  Today, if there are multiple event listeners and
one of them throws an exception, any subsequent listeners will never
be called.  The easiest thing to do is not change that, and simply
pass any thrown exception to postEvent via a throwable param. 
However, it arguably makes more sense to change the behaviour so that
when a listener throws an exception, it's noted, but subsequent
listeners still get called (and may themselves throw an exception). 
This would mean that we'd want postEvent's signature to have a
collection of throwables (possibly including/associated with the name
of the listener that threw each one).

I'm leaning towards the latter.

Thoughts?

On 1/23/06, Xibin Zeng <xibin.zeng@gmail.com> wrote:
> Ken -
>
>  I don't currently have a patch for this; If you've got the fix please go
> ahead make it. A suggestion of mine is that if we could get the return value
> for the postEvent, you might pass that in also. Trying to avoid having to do
> this again in the future...
>
>  Thanks a lot for the help,
>  Xibin
>
>
> On 1/23/06, Kenneth Tam <kentaminator@gmail.com> wrote:
> > Some concerns expressed, but no vetos, so it looks like we'll go ahead
> > with the change.
> >
> > Xibin, I know you've been working in this area -- if you have a patch,
> > I'll be glad to review & submit it, otherwise I can do it myself (the
> > bulk of the work is in ControlBean.vm so that the generated event impl
> > method has the same exception catching support that is in the
> > generated operation impl code).
> >
> > Let me know ASAP pls, our time is pretty tight given the upcoming release.
> >
> > thanks!
> > k
> >
> > 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
View raw message