You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Soren Hilmer <so...@tietoenator.com> on 2005/03/31 16:23:22 UTC
SpringJames vs. JamesNG
Hi all,
Serge recently posted a mail to server-user saying that a container switch was
a minor concern of ours (or at least something to that extent).
I disagree on this, I believe that we have to make a decission on the
container issue, to both keep existing comitters interested and possible
attract new skilled people.
The container issue is by far the one thing that is keeping myself from doing
commits into James. I hate doing something today and having to redo it all
over in a month or two.
I tried to follow the discussion on JamesNG a while back, but as I at that
time had little knowledge of neither Groovy nor Spring, I did not comment.
I have now done some reading on the two subjects and believe that Spring is
the way to go for James. My main concern on JamesNG (I know this is not
Groovy related) is the CDI principle IMO this principle leads to constructor
bloat if you want to have some properties with default values, and I believe
we do.
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.
--Søren
--
Søren Hilmer, M.Sc.
R&D manager Phone: +45 72 30 64 00
TietoEnator IT+ A/S Fax: +45 72 30 64 40
Ved Lunden 12 Direct: +45 72 30 64 57
DK-8230 Åbyhøj Email: soren.hilmer <at> tietoenator.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
James as a distributed enterprise application suite
Posted by Juan Carlos Murillo <mu...@inet.co.cr>.
After reading the thread on container replacements I must say that I
have worked with Spring and it is an excellent unobtrusive container
that completely decouples your components, without introducing any
strange looking construct into your classes. It's very noninvasive. I
think the move to POJOs is a wise one that flows with the current
industry's inclinations.
Spring however, like other containers, assumes that the application is
not distributed. There are reasons to think that James as a central
server, with protocol specific subservers, is a very good candidate for
becoming a distributed application. From the enterprise level this
would be a really valuable enhancement as it would allow you to deploy
several smtp servers, for example, in separate machines, without
impacting the performance of, say, the POP or eventually IMAP servers.
This would also allow for building a central management console
(possibly web) that would control the server farm or cluster farm. You
could do load balancing with a set up like this, for high demand
scenarios. You could also have redundancy of services where the
independent server nodes consume from a queue.
In my mind this would mean that James would become an application in
itself, with the STMP, POP, NNTP, etc, becoming separate applications.
These applications could potentially run on a single machine or be
distributed. They would communicate through a Message Queue mechanism
using JMS standards, thus allowing guaranteed delivery.
Such an architecture would require a rethinking of the internal
dependencies, which could not be managed by Spring in a distributed
fashion. Hence, Spring would have to be a per application solution for
local dependencies, and some services would have to be centralized and
offered through a service locator pattern using the JMS bus.
The reason i bring this up is because it could potentially be a big plus
for the Enterprise aspect of James, but if a major refactoring is done
without planning for this type of decoupling, it will be too expensive
to try to propose it after the fact.
Any comments greatly appreciated,
--
Juan Carlos Murillo <mu...@inet.co.cr>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: SpringJames vs. JamesNG
Posted by Ahmed Mohombe <am...@yahoo.com>.
> I will start with a +1 for SpringJames.
:), well, first read Hani's must have opinion on containers:
http://www.jroller.com/page/fate/?anchor=picocontainer_tagnuts_from_a_thousand
Ahmed.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: SpringJames vs. JamesNG
Posted by ap...@bago.org.
> Someone asked for a road-map:
> 1. POJOification
> 2. Possibly taking ownership over a few Phoenix things
> [...]
> But I see this as done in concert, as you probably need to do
> 2. while doing 1.
Here is a count of package dependency from the current svn 2_1_fcs branch
(pls note that I grouped class import into packages for a better overview):
32 import org.apache.avalon.cornerstone.services.connection.*
10 import
org.apache.avalon.cornerstone.services.datasource.DataSourceSelector;
24 import org.apache.avalon.cornerstone.services.scheduler.*;
4 import org.apache.avalon.cornerstone.services.sockets.*;
30 import org.apache.avalon.cornerstone.services.store.*;
8 import org.apache.avalon.cornerstone.services.threads.ThreadManager;
2 import org.apache.avalon.excalibur.collections.ListUtils;
14 import org.apache.avalon.excalibur.datasource.DataSourceComponent;
24 import org.apache.avalon.excalibur.io.*;
74 import org.apache.avalon.excalibur.pool.*;
22 import org.apache.avalon.excalibur.thread.*;
108 import org.apache.avalon.framework.activity.*;
2 import org.apache.avalon.framework.CascadingRuntimeException;
186 import org.apache.avalon.framework.component.*;
262 import org.apache.avalon.framework.configuration.*;
4 import org.apache.avalon.framework.container.ContainerUtil;
76 import org.apache.avalon.framework.context.Context;
112 import org.apache.avalon.framework.logger.*;
22 import org.apache.avalon.framework.service.*;
2 import org.apache.avalon.phoenix.BlockContext;
2 import org.apache.commons.dbcp.BasicDataSource;
2 import org.apache.commons.net.pop3.POP3Client;
2 import org.apache.commons.net.pop3.POP3MessageInfo;
6 import org.apache.excalibur.threadcontext.ThreadContext;
What dependencies would you like to remove?
What should be included in james?
What should be ported to geronimo's or other container services?
I think that POJOification is really a simple task compared to this
analysis.
I don't know much about avalon stuff so I can't understand what should be
removed to avoid too much dependency on not mantained code.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: SpringJames vs. JamesNG
Posted by Soren Hilmer <so...@tietoenator.com>.
On Thursday 31 March 2005 17:59, Serge Knystautas wrote:
> Soren Hilmer wrote:
> > Serge recently posted a mail to server-user saying that a container
> > switch was a minor concern of ours (or at least something to that
> > extent).
> > I disagree on this, I believe that we have to make a decission on the
> > container issue, to both keep existing comitters interested and possible
> > attract new skilled people.
>
> I'll restate since it must have been unclear... WHICH new container we
> move to is not important at this phase of development since we have to
> change our current code to a bunch of POJOs.
Ahh, we agree then!
>
> > The container issue is by far the one thing that is keeping myself from
> > doing commits into James. I hate doing something today and having to redo
> > it all over in a month or two.
>
> I'm in the same camp.
>
> > I tried to follow the discussion on JamesNG a while back, but as I at
> > that time had little knowledge of neither Groovy nor Spring, I did not
> > comment.
> >
> > I have now done some reading on the two subjects and believe that Spring
> > is the way to go for James. My main concern on JamesNG (I know this is
> > not Groovy related) is the CDI principle IMO this principle leads to
> > constructor bloat if you want to have some properties with default
> > values, and I believe we do.
> > The Spring framework's Java-Bean approach is IMO a way better solution to
> > the POJO-ification issue.
>
> How are you seeing JavaBean != POJO? I've always used them as
> synonymous, except JavaBean's also has weird setter propertyeditor API
> for setAsText stuff.
No, I see (as you) JavaBean==POJO, but CDI!=JavaBean. And I prefer using the
JavaBean approach instead of CDI.
My concern is that CDI does not facilitate optional properties very well.
If you have some POJO, with just 2 optional properties that will lead to 4
constructors!! This is what I call constructor bloat.
>
> > 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.
>
> Could you explain what the differences are?
The difference is CDI vs. JavaBean, just that.
Someone asked for a road-map:
1. POJOification
2. Possibly taking ownership over a few Phoenix things
3. Making a SpringConfiguration which does the same as our current
configuration.
4. Test
5. Celebrate
But I see this as done in concert, as you probably need to do 2. while doing
1.
And doing 3. afterwards is probably too tiresome.
--Søren
--
Søren Hilmer, M.Sc.
R&D manager Phone: +45 72 30 64 00
TietoEnator IT+ A/S Fax: +45 72 30 64 02
Ved Lunden 12 Direct: +45 72 30 64 57
DK-8230 Åbyhøj Email: soren.hilmer <at> tietoenator.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: SpringJames vs. JamesNG
Posted by Serge Knystautas <se...@lokitech.com>.
Soren Hilmer wrote:
> Serge recently posted a mail to server-user saying that a container switch was
> a minor concern of ours (or at least something to that extent).
> I disagree on this, I believe that we have to make a decission on the
> container issue, to both keep existing comitters interested and possible
> attract new skilled people.
I'll restate since it must have been unclear... WHICH new container we
move to is not important at this phase of development since we have to
change our current code to a bunch of POJOs.
> The container issue is by far the one thing that is keeping myself from doing
> commits into James. I hate doing something today and having to redo it all
> over in a month or two.
I'm in the same camp.
> I tried to follow the discussion on JamesNG a while back, but as I at that
> time had little knowledge of neither Groovy nor Spring, I did not comment.
>
> I have now done some reading on the two subjects and believe that Spring is
> the way to go for James. My main concern on JamesNG (I know this is not
> Groovy related) is the CDI principle IMO this principle leads to constructor
> bloat if you want to have some properties with default values, and I believe
> we do.
> The Spring framework's Java-Bean approach is IMO a way better solution to the
> POJO-ification issue.
How are you seeing JavaBean != POJO? I've always used them as
synonymous, except JavaBean's also has weird setter propertyeditor API
for setAsText stuff.
> 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.
Could you explain what the differences are?
--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: SpringJames vs. JamesNG
Posted by Stefano Bagnara <io...@bago.org>.
> [...]
> 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 looked at JamesNG sources and I found it is a completely new project:
pratically no code in common with james.
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.
I also think that a 2.2.1 release should be made available BEFORE any major
update.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org