I see a distinction between multicast & unicast events, in that multicast events are semantically one-way notifications (we already restrict multicast events signatures so that they must have a void return type). As such, I think of their listeners as independent of each other, and I don't think that an exception in one's response to a notification should stop the others from getting it. One case where I think this matters is where listeners may be depending on getting notified in order to release resources.
Another way of looking at it is to consider multicast events like a pub-sub system. Just because one subscriber has a problem when they get a msg doesn't mean other subscribers shouldn't get that same msg. Actually, I'd like to consider the impact of further restricting multicast event signatures to disallow a throws clause. It wouldn't change this discussion, since runtime exceptions & errors could always come through, but I think it might clarify matters. We could punt on this issue for now -- if we kept the signature the same (ie a single throwable), we could still address it later by create a runtime exception for multicast events which wrapped the collection of actual exceptions thrown from all listeners. (note that in no case am I advocating "ignoring" exceptions; the code firing the event is always going to get an exception if one occurs) On 1/24/06, Daryl Olander <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > > > +1 (non-committer vote) > > > > > > > > > > On 1/13/06, Kenneth Tam < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
