beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Xibin Zeng <xibin.z...@gmail.com>
Subject Re: [VOTE] Binary compat breaking fix for o.a.b.c.spi.svc.ControlInterceptor
Date Tue, 24 Jan 2006 21:54:09 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message