This is a pretty interesting issue. I do agree that we should do the change given the description, but I'm not sure about setting a precedence like this. In the future, more and more advanced features will have people using them. It's a big price to pay though to add another interface to correct this problem.
Right now, I'm going to vote as +0 but I may change my mind as people respond to this thread. 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 > > > > > > > > > > > > > > > > > > > > > > > >
