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.
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. Kelven On 9/3/13 2:14 PM, "Darren Shepherd" <darren.s.sheph...@gmail.com> wrote: >All, > >I'm trying to cleanup the Spring stuff in ACS so that we can modularize >the configuration. While doing that I've dug into how Spring is >implemented in ACS and its a crazy tangled mess. It makes it very >difficult to fully leverage spring and even modularize it the way I wish >to. One of the issues that led to the current state was the attempt to >respect the legacy ACS cglib based AOP. > >After much analysis I've come to the conclusion that really we just have >to get away from that AOP style and adopt Spring AOP if we want AOP. >The fundamental difference between legacy and Spring AOP is that Spring >AOP is proxy based and only can do AOP when making method calls across >managed beans. So, for example, you can't intercept this.blah() because >it does not cross a bean boundary. I really hope this discussion >doesn't go down the rabbit hole on which AOP style we should use. Proxy >based AOP is very, very simple and works for the majority of use cases. > Full AOP (similar to legacy ACS) requires AspectJ which in turn >requires compile time or load time weaving. Both compile time and load >time weaving puts a additional burdens on either the dev process or the >production runtime. > >We only use AOP for two things. @DB and @ActionEvent. > >First @DB. @DB, from what I see is just a guard. The purpose is just >to ensure that people don't leave things open. The @DB logic gets >invoked in two places. 1) On calls to any GenericDao (because is has >the @DB annotation on GenericDaoBase) 2) on any method that has @DB and >the class implemented ComponentMethodInterceptable. > >What I propose with @DB is that we still invoke the @DB logic on >GenericDao calls. Spring AOP can handle that fine with a dynamic proxy. > Its all the other method calls that have @DB that cause a problem. >What I propose for that is that we put the guard logic at the bottom of >the call stack. Basically the code that sets up CallContext can check >that no transactions were left open or not cleaned up and then log big >ugly errors. > >With this approach it has the side benefit in that I'll have to dig >through all this stuff and make sure I really understand the transaction >handling. If I better understand the transaction management, it will >allow me to convert ACS to Spring TX management down the line. That's >where I really want to be, but we just have to take baby steps. > >Second @ActionEvent. This one just sucks and will be tedious. >Basically what I will have to do with @ActionEvent is validate all 241 >uses in ACS and make sure they are done a way that Spring AOP will catch >them. From what I understand, action events are for informational >purposely mainly. They don't have any resources IDs and are just pretty >much a string, so not like people can programmatically do too much with >them. So this process will the painful, but if I screw up 1 or 2 of the >241, I'm guessing the world won't end. Of course I'm going to try to >find some way to do this programmatically as I'm just lazy that way. > >Darren
