incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Darren Shepherd" <>
Subject CS -> Spring
Date Sat, 18 Aug 2012 17:16:16 GMT
I'm going to be starting the effort of moving CloudStack to be Spring
managed as this is an absolute must for me (and my day job).  I wanted
to share some of the high level points and the scope as I see it today.

Moving to Spring should not impact much code (except swapping
annotations in a lot of places) as the CS code base is already written
in a IoC/DI style (kudos to past developers who put that in place). 
Here's some of the ground rules I've use with Spring in the past and
will be applying to this effort.

1. "If you import org.springframework you've done something wrong." -
You should have no code dependency on Spring itself (including
annotations!).  The only place code dependency makes sense is in
bootstrap/initialization code and extending container features like
custom namespace handlers and what not.  If there is any compile time
dependency on spring it should be a separate spring specific module so
that other modules have Spring dependencies as <scope>runtime</scope>
and not <scope>compile</scope>.

2. JSR250 and JSR330 should be used for annotations.  So specifically
this means using the standard @Inject, @PostConstruct, @PreDestroy

3. Autowiring by type can/should be used.  If there is no unique
dependencies, named dependencies can be specified with the standard
@Resource annotation, or @Qualifier (following JSR330) should be used.

4. Component scanning should not be used - This means no auto discovery
of beans using the @Named (@Bean for the spring specific annotation)
annotation.  This is typically a controversial point.  A lot of people
like component scanning as you can avoid registering beans in XML (and
everybody hates XML).  The problem with component scanning is that for
large projects with a lot of developers it tends to be too much magic
and confuses most developers when debugging.  At runtime a component
gets injected and they have no clue where it came from or what it is. 
So still using XML to register beans is very helpful for people to
understand the system.  Additionally its annoying when one want to not
register a bean and than means removing it from the classpath
(typically, I'm sure their are other hooks)

5. Spring is not the center of the world! - Just because we use Spring
IoC doesn't mean that every other spring framework (Spring-WS, Spring
Securiy, Spring Integration, etc) is somehow the best choice for the
project.  Spring based frameworks need to be evaluated on their own
merits and not only on the fact that it's name starts with "Spring".

The scope of changes will mostly be around the ComponentLocator.  The
ComponentLocator currently does instantiation, lifecycle, configuration
injecting, AOP, and probably some other stuff.  So all of these feature
already exist in Spring in some fashion.  So I'll be dissecting the
ComponentLocator and removing functionality that Spring will do.  I'm
still toying with what to do with the Manager and Adapter interfaces as
these primarily just define lifecycle methods.  Spring will apply
lifecycle to all beans (using the normal @PostConstruct, @PreDestroy) so
those interface methods don't provide much value.  The configure()
method can also be done in a more generic fashion also.  So Adapter and
Manager may just become marker interfaces.

Moving to Spring also starts laying the foundation for a simpler
component and plugin model.  With Spring we can easily get to the point
where somebody builds a plug-in as a jar and puts it on the classpath
and Spring finds it and registers it as a plugin.  I have plenty of
thoughts around this, but I'll leave that for later.


View raw message