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 kelven.yang@citrix.com
 designates 66.165.176.63 as permitted sender)
From: Kelven Yang <kelven.yang@citrix.com>
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
Subject: Re: [MERGE] spring-modularization to master - Spring Modularization
Thread-Topic: [MERGE] spring-modularization to master - Spring Modularization
Thread-Index: AQHOv8Gvh00bDnx+RUGY2CoM1ePFcJniEaqA
Date: Wed, 2 Oct 2013 23:39:10 +0000
Message-ID: <CE71FA2D.561DE%kelven.yang@citrix.com>
In-Reply-To: 
 <CAMCEDC0=PbcE7YYjjnV1Dsit+c3NCe0CcrMWC3qgSc4K2ZAXbg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.2.3.120616
Content-Type: text/plain; charset="us-ascii"
Content-ID: <74713F140B2C5443B4767B91819EA01D@citrix.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Darren,

This looks really nice. A few questions on Spring AOP replacement.

1) Spring AOP is proxy-based, the reason we ended up of using customized
AOP is mainly due to that inside existing CloudStack codebase, we have
many places that are doing run-time type-casting, the code in these places
assumes a real object that implements all interfaces in the semantics
context. At the time when I initially converted to Spring, I couldn't
ensure that switching to proxy-based AOP can have 100% coverage for these
run-time cases. What is your approach to address this run-time
type-casting issue?

2) We've run into a huge-memory footprint issue that may be caused by
conflicts of CGLIB usage in Spring AOP and the CGLIB usage in CloudStack
Dao layer. Do you have a chance to run a memory analysis in the heap after
management server is started.

I might be good to run BVT test on the branch before the merge, could
someone initiate the effort?

kelven


On 10/2/13 3:48 PM, "Darren Shepherd" <darren.s.shepherd@gmail.com> wrote:

>Not sure how this works...  I would like to merge in the new
>modularized Spring setup to master. There is info on the wiki about it
>[1] [2] [3].  The primary change is to break apart the monolithic
>applicationContext.xml and componentContext.xml files such that each
>plugin can maintain and contribute its own configuration.
>
>In addition to breaking up the configuration we no longer use ACS
>custom AOP and it is now fully Spring AOP.
>
>Now adding/removing a plug-in is a matter of just adding a jar to the
>classpath (exception being commands.properties, I'll address that in a
>different thread).  Unfortunately this branch does not have the
>changes to package things in different RPMs.  So it would be great if
>somebody could take up the packaging effort to split out all the
>plugins into different RPMs.
>
>Darren
>
>[1]=20
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Modularize+Spring
>[2]=20
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Plug-ins%2C+Modules
>%2C+and+Extensions
>[3] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Extensions