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 >> >> > >> >> > >> >> >
