Yes agreed. I've extensively tested this, but that is never enough. How do I get the BVTs ran against this. Due to the cross cutting nature of this I want to get this merged as fast as possible.
Darren > On Oct 2, 2013, at 4:43 PM, Alex Huang <alex.hu...@citrix.com> wrote: > > +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 >
