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:dar...@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 > > >
