Versions Compared

Old Version 3

changes.mady.by.user Unknown User (kelveny)

Saved on

compared with

New Version 4

changes.mady.by.user Unknown User (kelveny)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Panel

<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> 

...

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

One of the biggest advantage of switching to Spring is that Auto-wiring in Component has now become consistent. With previous ComponentLocator, there are a lot of places that have to use run-time wiring, for example, using ComponentLocator.getManager() to wire a reference to a manager component. The reason for developers to do so is that ComponentLocator does not fully resolved dependent injection for components, so when inter-component relationship becomes complex in a large system like CloudStack, lots of hacking ways rise up inside CloudStack codebase. Although it solves the immediate needs, but it also creates a lot of confusion for developers, the more components being involved into injection business, the more the system is tightly coupled with ComponentLocator itself.

Following is an example of such hacking way, inside BaseCmd class, developer tried to resolve all the references for every used components into static variables.

Panel
Wiki Markup

public abstract class BaseCmd {

&nbsp; &nbsp; private static final Logger s_logger = Logger.getLogger(BaseCmd.class.getName());\\

&nbsp; &nbsp; public static final String USER_ERROR_MESSAGE = "Internal error executing command, please contact your system administrator";

&nbsp; &nbsp; public static final int PROGRESS_INSTANCE_CREATED = 1;\\

&nbsp; &nbsp; public static final String RESPONSE_TYPE_XML = "xml";

&nbsp; &nbsp; public static final String RESPONSE_TYPE_JSON = "json";\\

&nbsp; &nbsp; public enum CommandType {

&nbsp; &nbsp; &nbsp; &nbsp; BOOLEAN, DATE, FLOAT, INTEGER, SHORT, LIST, LONG, OBJECT, MAP, STRING, TZDATE, UUID

&nbsp; &nbsp; }\\

&nbsp; &nbsp; public static final DateFormat INPUT_FORMAT = new SimpleDateFormat("yyyy-MM-dd");

&nbsp; &nbsp; public static final DateFormat NEW_INPUT_FORMAT = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");

&nbsp; &nbsp; public static Pattern newInputDateFormat = Pattern.compile("\[\\d\]+-\[\\d\]+-\[\\d\]\+ \[\\d\]+:\[\\d\]+:\[\\d\]+");

&nbsp; &nbsp; private static final DateFormat \_outputFormat = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZ");\\

&nbsp; &nbsp; private Object \_responseObject = null;

&nbsp; &nbsp; private Map<String, String> fullUrlParams;\\

&nbsp; &nbsp; @Parameter(name = "response", type = CommandType.STRING)

&nbsp; &nbsp; private String responseType;\\

&nbsp; &nbsp; public&nbsp;static ConfigurationService \_configService;

&nbsp; &nbsp; public&nbsp;static AccountService \_accountService;

&nbsp; &nbsp; public&nbsp;static UserVmService \_userVmService;

&nbsp; &nbsp; public&nbsp;static ManagementService \_mgr;

&nbsp; &nbsp; public&nbsp;static StorageService \_storageService;

&nbsp; &nbsp; public&nbsp;static ResourceService \_resourceService;

&nbsp; &nbsp; public&nbsp;static NetworkService \_networkService;

..

..

..

}\\

With Spring, developer can now always use @Inject annotation to declare such reference. One of the top two reasons for us to try Spring experiments in Javelin, since with more complete dependency injection, it gives us a cleaner component coding practice. (the other top reason is that we have broader integration supports from many other third-party vendors, i.e., JUnit)