Kelven, That makes sense. I'm not a committer so I'll probably be working off my github account, but I'll base my branch off of javelin.
Darren > -------- Original Message -------- > Subject: Re: CS -> Spring > From: Kelven Yang <kelven.y...@citrix.com> > Date: Sat, August 18, 2012 7:31 pm > To: "cloudstack-dev@incubator.apache.org" > <cloudstack-dev@incubator.apache.org> > > > Darren, > > I'll start some coding on architecture refactoring work at "javelin" > branch, and I'll use Spring too. Should we share the same branch? I've > pushed the branch to the ASF repo already > > Kelven > > > On 8/18/12 6:59 PM, "Darren Shepherd" <dar...@godaddy.com> wrote: > > >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.hu...@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: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 > >> > >> > > >> > >> > > >> > >> >
