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

Reply via email to