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: [VOTE] Move spring-deployment module to TRUNK
Date Thu, 11 Oct 2007 05:04:43 GMT
On 10/10/07, Stefano Bagnara <apache@bago.org> wrote:
> Bernd Fondermann ha scritto:
> > On 10/8/07, Noel J. Bergman <noel@devtech.com> wrote:
> >> I will go on record that I oppose a move to Spring, and have said so on
> >> multiple occassions.  However, I do not oppose optional support for Spring.
> >
> > The Phoenix deployment will live on. All the users having their own
> > components and whatever customizations will be supported. For new
> > users starting to use James there is no fundamental advantage chosing
> > one deployment over the other. Except if they already have Spring
> > components (or POJOs) they'd like to integrate with.
> It will take a bit for spring to catch up with all the features our user
> may currently use in our phoenix deployment.

That's right. At the same time it offers, IMHO, ease-of-use and
integration capabilities the phoenix deployment does not provide.

> The spring deploymnet will need the scripts for unix and windows, the
> wrappers to run it as a service, it will need the integration with
> Commons Daemon.


> As an example of phoenix advanced components, phoenix provides a
> Beanshell based kernel that you can access with a console to manage the
> container and the contained applications dynamically.

Phoenix is a very mature and capable container. Spring cannot
supersede every possible feature of Phoenix or any other technology.
And I am not saying that Spring is equivalent to Phoenix in every
single example you gave. But nevertheless, I'd like to give some
references where everybody interested might start reading...

for scripting and BeanShell support, see Spring Reference Chapter 24. esp. 24.3.

> Phoenix has an HTTP adaptor on the ServiceManager that allow you to
> access the JMX services via web.

see Spring Reference Chapters 17.4 and 20.

> Phoenix supports classloader isolations between multiple applications
> deployed inside it

Spring does not offer that, AFAIK, but if you already have separate
classloaders, you can have one BeanFactory for each. So it does not
offer classloader isolation, but supports it.

> Not everything in this list will make me veto a proposal to use spring
> as our main deployment and forget about phoenix, but some of them are
> important, and this was mainly to make it clear that spring is not the
> panacea.

Alright. My basic idea behind the spring-deployment is /choice/, to
offer our users new ways to integrate James with their own or third
party software.
Pheonix-deployment module will live on as long as someone is maintaining it.
At least I myself will never propose to deprecate it.

> OT: In almost an year we didn't add anything SMTP/POP3 related
> neither improved our support for mailets (this is not a critic to you or
> your cool spring module, but something our PMC should take into account)

yes, but I don't see the protocols as the only important part of the
server. working at the fundamental architecture and making it more
manageable will also open up new opportunities to innovate in the
protocol section. Service interfaces could also be improved. For
example, with the new modularized project layout we could have two
SMTP implementations side-by-side, one proven, one experimental - just
like we seem to have two different deployments.
I'm not an expert on mail protocols, so I'll work on other parts of the project.


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

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

View raw message