It's actually really easy to turn this off. If you look at the last commit of the branch you'll see what changes to turn it on. So you can just reverse that one commit to disable it.
I'd rather merge this and then do the BVTs on master if possible. I really want to get this committed. Every time somebody changes a spring config file I have to keep making the corresponding changes. It seems like people are gearing up and developing stuff right now for 4.3. So the longer we wait the more headache it is for everyone. Again, if we find out this is a complete disaster, I can just flip some config settings and were back to the old style. I had to keep compatibility with the old style as Awsapi and usage still use it. Darren > On Oct 2, 2013, at 5:42 PM, Darren Shepherd <darren.s.sheph...@gmail.com> > wrote: > > 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 >>
