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