+1 on running the BVT on it. We've been through this one once before. Should be careful.
--Alex > -----Original Message----- > From: Kelven Yang [mailto:kelven.y...@citrix.com] > Sent: Wednesday, October 2, 2013 4:39 PM > To: dev@cloudstack.apache.org > Subject: Re: [MERGE] spring-modularization to master - Spring > Modularization > > 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.sheph...@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] > >https://cwiki.apache.org/confluence/display/CLOUDSTACK/Modularize+Sp > rin > >g > >[2] > >https://cwiki.apache.org/confluence/display/CLOUDSTACK/Plug- > ins%2C+Modu > >les > >%2C+and+Extensions > >[3] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Extensions
