Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (athena.apache.org: domain of darren.s.shepherd@gmail.com
 designates 209.85.192.180 as permitted sender)
Message-ID: <52265119.7090505@gmail.com>
Date: Tue, 03 Sep 2013 14:14:01 -0700
From: Darren Shepherd <darren.s.shepherd@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: dev@cloudstack.apache.org
Subject: [DISCUSS] @DB and @ActionEvent
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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