incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Darren Shepherd" <dar...@godaddy.com>
Subject RE: CS -> Spring
Date Sun, 19 Aug 2012 01:59:20 GMT
Alex,

This is definitely post-4.0.  I'm just throwing the info out there of
what I'm thinking of doing just to see if there are any major
objections.

Regarding maven, I responded on the main thread for this just now, so
refer to that.  Basically I've been waiting for a decision.  I hadn't
been following the mailing list most of the week and therefore wasn't
too sure what was up with that.

Darren




> -------- Original Message --------
> Subject: RE: CS -> Spring
> From: Alex Huang <Alex.Huang@citrix.com>
> Date: Sat, August 18, 2012 12:46 pm
> To: "cloudstack-dev@incubator.apache.org"
> <cloudstack-dev@incubator.apache.org>
> 
> 
> Darren,
> 
> 
> 
> This is not going into 4.0 release right?  
> 
> 
> 
> Also between maven and spring framework which one are you planning to do first?  The
other thread regarding build system seems to be coming to a consensus when the 4.0 release
date is pushed back.
> 
> 
> 
> --Alex
> 
> 
> 
> > -----Original Message-----
> 
> > From: Darren Shepherd [mailto:darren@godaddy.com]
> 
> > Sent: Saturday, August 18, 2012 10:16 AM
> 
> > To: cloudstack-dev@incubator.apache.org
> 
> > Subject: CS -> Spring
> 
> > 
> 
> > 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
> 
> > annotations.
> 
> > 
> 
> > 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.
> 
> > 
> 
> > Darren
> 
> > 
> 
> > 
> 
> >

Mime
View raw message