james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernd Fondermann" <bernd.fonderm...@googlemail.com>
Subject Re: James deployed as plugin on Geronimo!
Date Sun, 04 Feb 2007 20:20:57 GMT
On 2/4/07, robert burrell donkin <robertburrelldonkin@gmail.com> wrote:
> On 2/3/07, David Woldrich <dave@woldrich.com> wrote:
> >  So, Spring would be the officially supported platform -
> > the only one that the core James team needs to be savvy with, but by no
> > means would Spring be the only container that could host James.  Sounds
> > like what's going to be hot next year will just be all hot air, so
> > picking Spring is probably an ok decision.
>
> pheonix is an advanced and mature IoC container of the second
> generation. it runs the standalone application very well but requires
> custom adapters for other environments.
>
> spring is a third generation container and had the benefit of learning
> from drawbacks of the first and second generation containers but it's
> not as mature. switching from a mature container that's know to work
> well with james to spring would be risky and IMO it would be a poor
> trade.

No need to switch. We could provide an initial spring-based
distribution side-by-side the current phoenix-based ones quite easily,
based on the work in the spring-integration branch. Some developers
even use this code to run James out of Eclipse, AFAIK.

<off-topic>
Robert, where did you get that notion of first, second, third
generation containers from?
I am very interested in the specific definitions for some researches I
am doing ATM.
</off-topic>

> IMHO the biggest structural issue that james development has at the
> moment is not choice of container but a lack of modularization.

+1

> it is too much work to move all the current code base to POJOs. we
> need to be able to port code gradually.

For what it's worth, this was my initial motivation to start writing
unit tests: To be able to make refactorings on the "component
architecture" and being able to take that all apart and reassemble.
At the time we have enough of these, those refactoring will be totally
painless ;-)

  Bernd

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