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 22:22:14 GMT
I'm trying to guarantee all _event listeners_ get called (for an event
with multiple listeners), regardless of what any particular one might
do.  Even today, interceptors are always called in this situation,
it's just that those interceptors don't get passed a throwable.  The
issue is that it might make sense for interceptors to get passed a
_collection_ of throwables some day, at which point the obvious answer
is to change the interface yet again.  However, since I think it'll be
just as effective to throw a single wrapper exception (that holds the
collection of throwables), I'm in no hurry to change the existing
behaviour and will leave it as it for now.

On 1/24/06, Xibin Zeng <xibin.zeng@gmail.com> wrote:
> Ken -
>
> I think keeping the existing behavior is OK for now.
>
> If I understand your proposal correctly, you are trying to guarantee an
> interceptor is called even when another listener throws an exception (in
> case of multicast). I can see valid points in that design. I'm not sure if
> it's necessary. If you want to handle the event alone, you'd better make it
> unicast, right?
>
> Just my $0.02.
>
> Thanks
> Xibin
>
> On 1/24/06, Daryl Olander <dolander@gmail.com> wrote:
> >
> > 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
View raw message