james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Perry" <d.pe...@netcase.co.uk>
Subject RE: SpringJames vs. JamesNG
Date Thu, 31 Mar 2005 15:10:57 GMT
> > [...]
> > The Spring framework's Java-Bean approach is IMO a way better
> > solution to the POJO-ification issue.
> >
> > Now I have started to convert James into POJO's the Spring
> > way (only James.java so far), but as I stated above I hate
> > doing things over, so let us take a vote. Is it going to be
> > SpringJames or JamesNG.
> >
> > I will start with a +1 for SpringJames.
>
> You should better define the roadmap for what you are calling SpringJames.
>
> Making "setter driven dependency injection" POJO's from the current
> components and inject cornerstone components?

I've used both setter and constructor dependency injection.  I much prefer
the constructor approach:
-All dependencies are in one place - the constructor - this causes bloat,
but makes maintenence easier as it's only one method.
-Consequestly all dependencies are supplied in one go, and as the whole
constructor must be filled, all dependencies must be filled, where as SDI
relies on all methods being called. This makes no real difference when a
container is creating the class, but it makes it easier to use a component
from code - you can immediatly see what you must provide.

I have never used spring, so i cant comment on the 'spring approach'. But i
have used nanocontainer/picocontainer, and i love them.  Lightweight and
very simple to use. I havnt used groovy as i never needed the complexity - i
stuck to xml.  But looking at the examples, groovy gives a much more
powerful method of assembling the system.

>
> I've looked at JamesNG sources and I found it is a completely new project:
> pratically no code in common with james.

I intend to look into this when i get a chance!

> I'm not a committer but I think that the person that will have the time to
> do this major change should take a few hour to update the issue site and
> apply old patches BEFORE major updates.

+1

> I also think that a 2.2.1 release should be made available BEFORE
> any major
> update.

Yep. Though i would like to see more patches commited, and a new rc first.

Daniel.


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message