While we are refactoring CloudStack architecture, to lay out a better component oriented foundation, be open to tools that most developers are familiar with in Java community, we started to experience the usage of Apache Spring Framework, switching to Spring touches a lot of existing CloudStack codebase, however, it does not bring any business logic changes, but it does introduce changes that CloudStack developers need to be aware of.

1. CloudStack Framework components and business logic components

With old component container managed by ComponentLocator class, we don't distinguish framework components and regular components that implement varios CloudStack business logic, we started to separate framework components and business logic components, there are separated context configuration file, these two files are applicationContext.xml.in and componentContext.xml.in, following is some sample content from Javelin

applicationContext.xml.in

<beans xmlns="http://www.springframework.org/schema/beans"

  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 

  xmlns:context="http://www.springframework.org/schema/context"

  xmlns:tx="http://www.springframework.org/schema/tx" 

  xmlns:aop="http://www.springframework.org/schema/aop"

  xsi:schemaLocation="http://www.springframework.org/schema/beans

_                      http://www.springframework.org/schema/beans/spring-beans-3.0.xsd_

_                      http://www.springframework.org/schema/tx _

_                      http://www.springframework.org/schema/tx/spring-tx-3.0.xsd_

_                      http://www.springframework.org/schema/aop_

_                      http://www.springframework.org/schema/aop/spring-aop-3.0.xsd_

_                      http://www.springframework.org/schema/context_

                      http://www.springframework.org/schema/context/spring-context-3.0.xsd">                     

 

  <context:annotation-config />

 

  <context:component-scan base-package="org.apache.cloudstack, com.cloud" />

 

  <!--

    @DB support

  -->

  <aop:config proxy-target-class="true">

    <aop:aspect id="dbContextBuilder" ref="transactionContextBuilder">

        <aop:pointcut id="captureAnyMethod"

            expression="execution(* *(..))" 

        />

 

        <aop:around pointcut-ref="captureAnyMethod" method="AroundAnyMethod"/> 

    </aop:aspect>

    <aop:aspect id="actionEventInterceptorAspect" ref="actionEventInterceptor">

        <aop:pointcut id="captureEventMethod"

            expression="execution(* *(..)) and @annotation(com.cloud.event.ActionEvent)" 

        />

        <aop:around pointcut-ref="captureEventMethod" method="AroundAnyMethod"/> 

    </aop:aspect>

 

  </aop:config>

 

  <bean id="transactionContextBuilder" />

  <bean id="actionEventInterceptor" />

  

  <!--

    RPC/Async/EventBus

  -->

  <bean id="onwireRegistry"

    init-method="scan" >

    <property name="packages">

      <list>

        <value>org.apache.cloudstack.framework</value>

      </list>

    </property>

  </bean>

 

  <bean id="messageSerializer">

    <property name="onwireClassRegistry" ref="onwireRegistry" />

  </bean>

 

  <bean id="transportProvider"  init-method="initialize">

    <property name="workerPoolSize" value="5" />

    <property name="nodeId" value="Node1" />

    <property name="messageSerializer" ref="messageSerializer" />

  </bean>

  <bean id="rpcProvider" init-method="initialize">

    <constructor-arg ref="transportProvider" />

    <property name="messageSerializer" ref="messageSerializer" />

  </bean>

 

  <bean id="eventBus" class = "org.apache.cloudstack.framework.eventbus.EventBusBase" />

  <bean id="apiServlet" class = "com.cloud.api.ApiServlet" />

</beans>

Components that offer framework level services are collected in applicationContext.xml.in, these framework components usually help define the runtime environment for all other business logic components, for example, middle-ware service components that are for inter-component communication, CloudStack Database, general DB transaction management etc. CloudStack customers may have various combination of activated business logic components in a particular setup, but most of time, a same set of framework components is usually used.

componentContext.xml.in

<beans xmlns="http://www.springframework.org/schema/beans"

  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 

  xmlns:context="http://www.springframework.org/schema/context"

  xmlns:tx="http://www.springframework.org/schema/tx" 

  xmlns:aop="http://www.springframework.org/schema/aop"

  xsi:schemaLocation="http://www.springframework.org/schema/beans

                      http://www.springframework.org/schema/beans/spring-beans-3.0.xsd

                      http://www.springframework.org/schema/tx&nbsp;

                      http://www.springframework.org/schema/tx/spring-tx-3.0.xsd

                      http://www.springframework.org/schema/aop

                      http://www.springframework.org/schema/aop/spring-aop-3.0.xsd

                      http://www.springframework.org/schema/context

                      http://www.springframework.org/schema/context/spring-context-3.0.xsd">                     

  <!--

      Compose a CloudStack deployment with selected components here

  -->

  <bean id="databaseUpgradeChecker" />

  <bean id="management-server" class ="com.cloud.server.ManagementServerExtImpl" />

  <bean id="configuration-server" />

  <bean id="clusterManagerImpl" />

  <bean id="clusteredAgentManagerImpl" />

  <bean id="clusteredVirtualMachineManagerImpl" />

  <bean id="highAvailabilityManagerExtImpl" />

  <!-- bean id="bareMetalVmManagerImpl" / -->

  <bean id="userVmManagerImpl" />

  <bean id="consoleProxyManagerImpl" />

  <bean id="securityGroupManagerImpl2" />

  <bean id="premiumSecondaryStorageManagerImpl" />

  <bean id="randomlyIncreasingVMInstanceDaoImpl" /> 

  <!--

      Network Elements

  -->

  <bean id="Ovs">

    <property name="name" value="Ovs"/>

  </bean>

  <bean id="ExternalDhcpServer">

    <property name="name" value="ExternalDhcpServer"/>

  </bean>

  <bean id="BareMetal">

    <property name="name" value="BareMetal"/>

  </bean>

  <bean id="SecurityGroupProvider">

    <property name="name" value="SecurityGroupProvider"/>

  </bean>

  <bean id="VirtualRouter">

    <property name="name" value="VirtualRouter"/>

  </bean>

  <bean id="VpcVirtualRouter">

    <property name="name" value="VpcVirtualRouter"/>

  </bean>

  <bean id="NiciraNvp">

    <property name="name" value="NiciraNvp"/>

  </bean>

  ...

  ...

</beans> 

2. How to declare to be a CloudStack component

In Spring term, CloudStack uses both singleton components and prototype components, Spring component is nothing else more than a Java POJO object, you can either declare it with @Component annotation or in <bean> declaration in applicationContext.xml or componentContext.xml. CloudStack uses a lot of singleton components, for example, managers, DAOs, following is an example of such components

*@Component*

@Local(value=ClusterDao.class)

public class ClusterDaoImpl extends GenericDaoBase<ClusterVO, Long> implements ClusterDao {\\

&nbsp; &nbsp; protected final SearchBuilder<ClusterVO> PodSearch;

&nbsp; &nbsp; protected final SearchBuilder<ClusterVO> HyTypeWithoutGuidSearch;

&nbsp; &nbsp; protected final SearchBuilder<ClusterVO> AvailHyperSearch;

&nbsp; &nbsp; protected final SearchBuilder<ClusterVO> ZoneSearch;

&nbsp; &nbsp; protected final SearchBuilder<ClusterVO> ZoneHyTypeSearch;\\

&nbsp; &nbsp; private static final String GET_POD_CLUSTER_MAP_PREFIX = "SELECT pod_id, id FROM cloud.cluster WHERE cluster.id IN( ";

&nbsp; &nbsp; private static final String GET_POD_CLUSTER_MAP_SUFFIX = " )";

&nbsp; &nbsp; *@Inject*

&nbsp; &nbsp; protected HostPodDao \_hostPodDao;\\

&nbsp; &nbsp; public ClusterDaoImpl() {

&nbsp; &nbsp; &nbsp; &nbsp; super();\\

&nbsp; &nbsp; &nbsp; &nbsp; HyTypeWithoutGuidSearch = createSearchBuilder();

&nbsp; &nbsp; &nbsp; &nbsp; HyTypeWithoutGuidSearch.and("hypervisorType", HyTypeWithoutGuidSearch.entity().getHypervisorType(), SearchCriteria.Op.EQ);

&nbsp; &nbsp; &nbsp; &nbsp; HyTypeWithoutGuidSearch.and("guid", HyTypeWithoutGuidSearch.entity().getGuid(), SearchCriteria.Op.NULL);

&nbsp; &nbsp; &nbsp; &nbsp; HyTypeWithoutGuidSearch.done();\\

&nbsp; &nbsp; &nbsp; &nbsp; ZoneHyTypeSearch = createSearchBuilder();

&nbsp; &nbsp; &nbsp; &nbsp; ZoneHyTypeSearch.and("hypervisorType", ZoneHyTypeSearch.entity().getHypervisorType(), SearchCriteria.Op.EQ);

&nbsp; &nbsp; &nbsp; &nbsp; ZoneHyTypeSearch.and("dataCenterId", ZoneHyTypeSearch.entity().getDataCenterId(), SearchCriteria.Op.EQ);

&nbsp; &nbsp; &nbsp; &nbsp; ZoneHyTypeSearch.done();\\

&nbsp; &nbsp; &nbsp; &nbsp; PodSearch = createSearchBuilder();

&nbsp; &nbsp; &nbsp; &nbsp; PodSearch.and("pod", PodSearch.entity().getPodId(), SearchCriteria.Op.EQ);

&nbsp; &nbsp; &nbsp; &nbsp; PodSearch.and("name", PodSearch.entity().getName(), SearchCriteria.Op.EQ);

&nbsp; &nbsp; &nbsp; &nbsp; PodSearch.done();\\

&nbsp; &nbsp; &nbsp; &nbsp; ZoneSearch = createSearchBuilder();

&nbsp; &nbsp; &nbsp; &nbsp; ZoneSearch.and("dataCenterId", ZoneSearch.entity().getDataCenterId(), SearchCriteria.Op.EQ);

&nbsp; &nbsp; &nbsp; &nbsp; ZoneSearch.groupBy(ZoneSearch.entity().getHypervisorType());

&nbsp; &nbsp; &nbsp; &nbsp; ZoneSearch.done();\\

&nbsp; &nbsp; &nbsp; &nbsp; AvailHyperSearch = createSearchBuilder();

&nbsp; &nbsp; &nbsp; &nbsp; AvailHyperSearch.and("zoneId", AvailHyperSearch.entity().getDataCenterId(), SearchCriteria.Op.EQ);

&nbsp; &nbsp; &nbsp; &nbsp; AvailHyperSearch.select(null, Func.DISTINCT, AvailHyperSearch.entity().getHypervisorType());

&nbsp; &nbsp; &nbsp; &nbsp; AvailHyperSearch.done();

&nbsp; &nbsp; }

...

...

...

}\\

For most of low-level built-in components like DAOs, in Javelin practice, we use @Component annotation, since it saves us a lot of typing and can take advantage of Eclipse IDE's powerful refactoring and type-infer feature to help us coding. However, if you are developing high level components and you want to give flexibility for customer to choose to compose a particular CloudStack deployment, declare in componentContext.xml would be a better choice.

3. Auto-wiring