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
