On Fri, Jan 4, 2013 at 6:13 PM, Kelven Yang <kelven.y...@citrix.com> wrote: > I'm proposing another branch merge after API-refactoring branch, to merge > javelin branch into the main stream. Javelin branch contains a number of > architecture refactoring efforts, > > 1. Adopting Spring Framework for dependency injection of CloudStack > internal components > 2. IPC framework for inter component communications > 3. Storage subsystem refactoring > 4. CloudStack Orchestration Engine refactoring > > Majorities of the new refactoring work are independent of existing > CloudStack components, therefore merging these independent newly developed > components should not have a big impact to existing code base. The major > impact of this merge will be on #1, as it touches almost every component > in the existing code base, DAOs, Adapters, Managers, etc. In order to > seamlessly replace our existing ComponentLocator with Spring injection > framework. We've done following refactoring to existing code base. > > 1) Remove all un-necessary runtime bindings to ComponentLocator at Daos, > Managers, Adapters, etc > 2) Using standard javax @Inject to replace with customized > com.cloud.utils.component.Inject > 3) Using Spring AOP to support @DB semantics > 4) Separate component loading and initializing to avoid inter-leaving > dependencies between Spring bootstrap loader and CloudStack run-time > business logic. > 5) Move CloudStack bootstrap logic out of ComponentLocator to the > initialization process at business logic layer > > The plan of performing such merge will be, we will first pull the latest > master content into javelin branch, complete the merge at javelin branch > and commit it into master after certain level of testing. The goal is to > make existing code works as before but will drop in newly add-ons of > refactoring work. > > Kelven >
Kelven: As Chip noted earlier today[1], Javelin doesn't currently build when tests are enabled, which is troubling. [1] http://markmail.org/message/5qtvdqom4hblw2zg
