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 Tue, 24 Jan 2006 20:24:58 GMT
I would vote to keep the current behavior.  I've never liked ignoring
exception because it treats exceptions as something expected instead of as
an exception.  Are there cases where a listener would ever through an
exception and you would want to continue forward?  I can imagine the
opposite being true.

On 1/24/06, Kenneth Tam <kentaminator@gmail.com> wrote:
>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message