Page History

...

CloudStack management server contains a collection of various components, components usually come with 4 different flavors, common framework components, manager components, adapter components and DAO components. After In post-deploy time, CloudStack allows experienced customer to compose a customized setup through editing of configuration files. For CloudStack OSS (OpenSource) distribution, developers provides default configuration in applicationContext.xml.in and componentContext.xml.in, while for non-OSS distribution, the configuration will be provided in applicationContext.xml.in and nonossComponentContext.xml.in.

For all components that are mandatory and shared among both OSS distribution and non-OSS distribution, they should be declared in applicationContext.xml.in. Optional components, depends on whether or not they are specific to OSS or non-OSS distribution, they can appear in applicationContextin componentContext.xml.in *and *componentContextin and nonossComponentContext.xml.in, * * either in one of the two files or the both files.

If a certain component has different configuration for OSS and non-OSS distribution, it should go both to applicationContext.xml.in *and *componentContextin and noncomponentContext.xml.in.

Use following flow to determine where your newly developed component should go

if (component is mandatory to OSS/non-OSS ) {


    if( component shares common configuration in both OSS and non-OSS distributions ) {
        put it in applicationContext.xml.in
    } else {
        put it in both componentContext.xml and nonossComponentContext.xml.in
    }


} else {


    // optional component
    if(component is for OSS only)
        put it in componentContext.xml
    else
        put it in nonossComponentContext.xml

}

...

Spring component is nothing more than a Java POJO(Plain Old Java Object) object, once you've determined which file the component declaration should go using the flow at above. declaring it is fairly simple. Following gives an example

...

Following is an example of such hacking way, inside BaseCmd class, developer tried to resolve all the references for every used components in all sub-classes into static variables at  BaseCmd. It basically means that, when you add a new Command class to the system, you will have to remember to do something about your new service at BaseCmd class

...

With Spring, developer can now always use @Inject annotation to declare such reference, and most importantly, inject these references only when they are needed at individual Command class, so that each Command class can become more independent to each other. This is one of the top two reasons for us to try Spring, it can give us a cleaner component coding practice. (the other top reason is that we have broader integration support from many other third-party vendors).

...

Although we've tried the best to cut the relationship to a component container inside component code, we still have very few places in framework components that need to be aware of existence of the component container, to avoid any strong binding to a particular container like Spring, we introduced a class called ComponentContext, it is responsible to bridge CloudStack component with a chosen component container (for now, it is Spring). 

...