Noel J. Bergman ÐÐÑÐÑ:
In general, I like Alexander's enthusiasm and ideas. Specific comments to
follow.
We actually use relatively little from Avalon other than lifecycle and
configuration, both of which we could (and should in the latter case)
replace. What little else we use from Avalon can be
My earlier post was obviously much too long :-)
The James server current design for handling multiple domains is shaky both
in a "single domain" config and "multiple domain" config.
In a single domain config, if a user configures Fetchmail to include a
default domain then that domain needs to be
Noel J. Bergman wrote:
We actually use relatively little from Avalon other than lifecycle and
configuration, both of which we could (and should in the latter case)
replace. What little else we use from Avalon can be replaced by equivalents
from Jakarta Commons, or developed locally (user and messa
On Tue, 1 Feb 2005 08:34:54 -0500, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> In general, I like Alexander's enthusiasm and ideas.
+1
> With respect to Groovy, I see that fitting into a startup role, and we
> should be open to seeing multiple technologies able to fill that role.
+1
> It sho
In general, I like Alexander's enthusiasm and ideas. Specific comments to
follow.
We actually use relatively little from Avalon other than lifecycle and
configuration, both of which we could (and should in the latter case)
replace. What little else we use from Avalon can be replaced by equivalen
On Mon, 31 Jan 2005 09:06:53 -0800, Steve Short <[EMAIL PROTECTED]> wrote:
>
> FWIW I was playing with Spring and James a while ago as a learning
> exercise and got all of James running in Spring with no code changes to
> James or Avalon components.
Thats good news. It is what the theory lets us
