+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 > > > > > > > > > > > > > > > >
