CS -> Spring

2012-08-18 Thread Darren Shepherd
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 runtime
and not compile.

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






RE: CS -> Spring

2012-08-18 Thread Alex Huang
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 runtime and not
> compile.
> 
> 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
> 
> 
> 



RE: [DISCUSS] Please choose: The build system to use for 4.0

2012-08-18 Thread Darren Shepherd
All,

So I have maven fully functional.  I sent an email regarding this but
being that it wasn't on this thread so it probably went un-noticed.  So
below is basically a copy of that.

If you want to get an idea of what maven would look like for CS, what
I've done is on the "maven"
branch at https://github.com/ibuildthecloud/incubator-cloudstack.git

I had to setup a custom repo to put all the non-oss libraries that don't
exist in the central maven repo. To build just do "mvn -s
m2-settings.xml"

That settings file will create a local repo (not use ~/.m2/repository)
because I was testing that all dependencies are coming from where I
expected and not polluted by other maven stuff I do.

Its a multi module project so you can do things like "mvn -s m2-settings
-am -pl server" to just build the server portion (or core, or one of the
tons of plugins).  I also tested that the build works with maven 2 and
maven 3
and that the Eclipse M2E plugin works with it too.

I would love it if a maven god could review what I've done.  If we're
all good with maven I'll gladly take this to full completion and start
submitting patches.  Post 4.0 we can always improve (and I'm sure we
will), but I feel I know what's the bare minimum need to get this out
the door and I can do that (plus whatever nice to haves I can squeek
in).

Regarding the dev environment setup.  We can do this with whatever
little amount of impact we want.  Once you have the maven pom's you just
install Eclipse M2E (thats an eclipse foundation project) and then say
"Import Existing Maven Projects" and then magic ensues.  The M2E plugin
works pretty darn well.  It also has the great benefit that you can stop
checking in .classpath and .project files in the your version control
because the pom.xml has all the metadata Eclipse M2E needs to create a
project.   So my preferred approach would be to checkin the pom's and
then delete the .classpath and .project files from git and have
developers re-import their projects into eclipse.  If people don't like
that I can use some magic with the mvn depenendency:copy-dependencies to
recreate the same structure as whats in deps today to make the eclipse
projects still work.  But I would grudgingly do that work as I would
rather we just move forward with a standard maven layout.  Gotta learn
sometime and I don't think its all that difficult.

Regarding the ant tasks, I want to keep backwards compatibilty so that
the main ant tasks still work but just internally call maven and not
javac/jar directly.

So I vote we just let me do this and I'll get 'er done.

Darren



>  Original Message 
> Subject: RE: [DISCUSS] Please choose: The build system to use for 4.0
> From: Ewan Mellor 
> Date: Fri, August 17, 2012 2:22 pm
> To: "cloudstack-dev@incubator.apache.org"
> 
> 
> 
> Well, all our packages are going to be public, of course.  That shouldn't be 
> a problem!
> 
> Ewan.
> 
> > -Original Message-
> > From: Marcus Sorensen [mailto:shadow...@gmail.com]
> > Sent: 17 August 2012 14:19
> > To: cloudstack-dev@incubator.apache.org
> > Subject: Re: [DISCUSS] Please choose: The build system to use for 4.0
> > 
> > I'm totally fine with a switch, my only concern was around when it's done.
> > Aside from just implementing the build bits in the git repo (sounds like 
> > there
> > are resources for this), I picture there being a bit of work on every
> > developer's part to switch their dev environments. This might be as simple 
> > as
> > a few package installs, but on at least one occasion when I was building
> > something via Maven I had to spend the better part of an afternoon going
> > back and forth with the network/systems guys because Maven needed to
> > download some components and the applicable systems by default are
> > internal-access only. It's things like that where I worry about switching 
> > build
> > systems when people are under a crunch to complete 4.0.
> > 
> > On Fri, Aug 17, 2012 at 2:04 PM, Ewan Mellor 
> > wrote:
> > > OK, so we've got offers of effort on Maven from Darren, Hugo, plus review
> > help from Olivier and Alex.  Maven gets +1 from me, Alex, and Brett too.
> > >
> > > On the Ant side we've got +1 from Chip ("based on timeline"), Wido,
> > Marcus, and Mice.  David has his deps-ctrl branch, but no-one has offered to
> > finish the job.
> > >
> > > We have consensus that the release is going to slip by at least 3 weeks 
> > > (2 at
> > the front and one at the end), which gives us four weeks total to get the
> > build system done and debugged (i.e. between now and final release
> > candidate on Sep 14).
> > >
> > > With that extra time, does that change anyone's opinion?  It would be nice
> > to get consensus on this issue, otherwise we're going to have to put it to a
> > vote.
> > >
> > > Thanks,
> > >
> > > Ewan.
> > >
> > >
> > >> -Original Message-
> > >> From: akaras...@gmail.com [mailto:akaras...@gmail.com] On Behalf Of
> > >> Alex Karasulu
> > >> Sent: 17 August 2012 03

RE: CS -> Spring

2012-08-18 Thread Darren Shepherd
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 
> Date: Sat, August 18, 2012 12:46 pm
> To: "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 runtime and not
> 
> > compile.
> 
> > 
> 
> > 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 o

Re: [DOCS] Cloudbridge needs new documentation

2012-08-18 Thread sebgoa
Hi Jessica et al,

I migrated the S3 wiki page to the new wiki, the S3 doc is now at:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/S3+API+in+CloudStack

I put a redirect on the old page, I don't know if someone can actually lock the 
edit.

Next,  I will work on migrating the pdf info into publican (hopefully 
tomorrow), using the content from CP and cross checking with what was in the 
old cloudbridge guide.

-sebastien


On Aug 16, 2012, at 6:49 AM, Jessica Tomechak wrote:

> Sebastien/Alex/et al: Thanks very much for noticing these questions. Please
> see:
> 
> 
> http://bugs.cloudstack.org/browse/CS-15604
> 
> 
> The EC2 content from CP, as well as the rest of the Installation Guide,
> still needs to be moved to publican, as this bug states. We need to create
> an Apache CloudStack version of this Citrix guide:
> 
> 
> 
> http://support.citrix.com/article/CTX133611
> 
> 
> 
> First step: if the CloudStack team can determine right now which parts of
> the Citrix guide won’t apply, we can avoid even porting those sections to
> the Apache repo. Productivity win. Would someone like to volunteer to
> compile such a list and add it as a comment to the bug CS-15604?
> 
> 
> And would someone in the email exchange below be volunteering to convert
> the old cloudbridge content to publican-friendly docbook XML?
> 
> 
> Also: Love the [DOCS] subject line tag.
> 
> 
> Jessica T.
> CloudStack Tech Pubs
> 
> -Original Message-
>> From: Alex Huang [mailto:alex.hu...@citrix.com]
>> Sent: Tuesday, August 14, 2012 3:02 PM
>> To: cloudstack-dev@incubator.apache.org
>> Cc: Ewan Mellor
>> Subject: RE: [DOCS] Cloudbridge needs new documentation
>> 
>> The point is still valid though.  Even though there's information, there
>> needs to be official doc.  I think we should file this as a bug for the 4.0
>> release.  Ewan?
>> 
>> --Alex
>> 
>>> -Original Message-
>>> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
>>> Sent: Tuesday, August 14, 2012 2:39 PM
>>> To: CloudStack DeveloperList
>>> Subject: Re: [DOCS] Cloudbridge needs new documentation
>>> 
>>> S3 information is documented here:
>>> http://wiki.cloudstack.org/display/RelOps/S3+API+in+CloudStack
>>> 
>>> 
>>> 
>>> On 8/14/12 1:57 PM, "Prachi Damle"  wrote:
>>> 
 The slides cover pretty much everything that is documented in the CP
 install guide for enabling EC2. The CP install guide covers all the
 APIs that are supported via EC2 Soap.
 So whatever CP install guide mentions can be used for 4.0 docs as well.
 
 I am not sure about S3 documentation.
 
 Thanks,
 Prachi
 -Original Message-
 From: sebgoa [mailto:run...@gmail.com]
 Sent: Tuesday, August 14, 2012 1:20 PM
 To: cloudstack-dev@incubator.apache.org
 Subject: [DOCS] Cloudbridge needs new documentation
 
 Hi everyone,
 
 I have been looking at what used to be cloudbridge and is now an
 integral part of CS.
 
 The old documentation for cloudbridge is at:
 http://docs.cloudstack.org/@api/deki/files/165/CloudBridgeGuide.pdf
 
 It does not seem to have been moved to /docs in publican format.
 
 The "new" documentation is quite different and will be close (or
 equal) to the cloudplatform docs at:
 http://support.citrix.com/servlet/KbServlet/download/31038-102-684646
 /C
 lou
 dPlatform3.0.3_3.0.4InstallGuide.pdf
 For cloudbridge from p.153 to p.163 which includes a listing of the
 supported ec2 commands.
 
 Neither of these have information about S3.
 
 I put some slides up about how I believe things need to be configured
 to get EC2 working:
 http://www.slideshare.net/sebastiengoasguen/cloudstack-ec2-
>>> configuratio
 n
 
 What do you all think should be in the docs or not ? Has anyone been
 looking at this ?
 Can we take what's in the CP doc and move it straight to publican ?
 
 Also what about S3 ? I don't think there is any documentation about
 it yet, and it may not be production ready yet.
 
 Thoughts,
 
 -Sebastien
 
 
 -Sebastien Goasguen
 Cloud Computing Evangelist, Citrix EMEA
 
 
 
 
>> 
>> 

-Sebastien Goasguen
Cloud Computing Evangelist, Citrix EMEA






Re: CS -> Spring

2012-08-18 Thread Kelven Yang
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"  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 
>> Date: Sat, August 18, 2012 12:46 pm
>> To: "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 runtime and not
>> 
>> > compile.
>> 
>> > 
>> 
>> > 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 @PostConstruc

RE: CS -> Spring

2012-08-18 Thread Darren Shepherd
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 
> Date: Sat, August 18, 2012 7:31 pm
> To: "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"  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 
> >> Date: Sat, August 18, 2012 12:46 pm
> >> To: "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 runtime and not
> >> 
> >> > compile.
> >> 
> >> > 
> >> 
> >> > 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