One correction, it should be "usage of @ActionEvent is not compatible to proxy based AOP".
Proxy based AOP is suitable if there is no re-entrance from one interception point to another one of the same object. But most of @DB/@ActionEvent semantics are implemented by relying on general method interception. Kelven On 9/3/13 3:58 PM, "Kelven Yang" <kelven.y...@citrix.com> wrote: > > >On 9/3/13 3:41 PM, "Darren Shepherd" <darren.s.sheph...@gmail.com> wrote: > >>On 09/03/2013 03:05 PM, Kelven Yang wrote: >>> The only purpose for @DB is to provide a transaction context >>> automatically(open/close) in thread's calling stack. We can fully get >>>rid >>> of it if we guard it from the entry point of every runnable. A little >>> caution though, we have a couple places that involve with switching >>> between Cloud DB instance and usage DB instance. >> >>I'll pay extra attention to that. >> >>> Unfortunately, @ActionEvent is not compatible to proxy based AOP, the >>> information it generates is not only informational for debugging >>>purpose. >>> Some business logic (auditing or billing) depend on it. You probably >>>need >>> to be careful. Whatever change you want to make, it should not break >>>the >>> semantics of generating correct events for its business logic users. >> >>I have no intention of changing the semantics. I'll see how I can >>ensure that the changes don't have any impact through some programmatic >>verification. > >That sounds great!. >-Kelven > >> >>Darren >> >
