james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Knystautas <ser...@lokitech.com>
Subject Re: [James-NG] Avalon-free James proposal and reference implementation
Date Mon, 31 Jan 2005 16:17:22 GMT
Ahmed Mohombe wrote:
> Like Phoenix? If I'm not wrong, for most of the important changes I make 
> now in the james config, I still need to restart it.
> I've seen no "real hot-reloading" "out of the box" till yet.
> IMHO, instead of the so called "hot-reloading", a simple "instruction" 
> in the "James-Admin" to reload the config file (if the admin wants that 
> - cause he changed the config file") would be enough.

<snip />

> Well, IMHO there's nothing better than Log4J. Why to use another "layer" 
> since log4J does the job very well (and most of them redirect to log4j 
> anyway)?

Ah, irony.  Yes, I'm well aware that Avalon's container framework has 
not provided what James needs. :)

>>  but Digester is really too simple to handle the complexities we need 
>> (at least based on my experience using Digester).
> Hmm, I've always thought that "less is more" :). Besides, why must be 
> the configuration of JAMES complex?.

James is complex because of what it is doing, not because of the 
configuration tool, e.g., multiple socket servers, thread pools, 
listeners, scheduling, dns servers, coexisting LDAP file AND JDBC users, 
domain lists, different mail format stores, mail processors, 
blacklisting and performance monitoring, etc...

The goal is to make configuration less complex as we scale, hence the 
decision to use something like Groovy or Spring or Picocontainer, 
etc..., rather than a simple tool that becomes unmanageable as 
complexity grows.

Again, if you're only using a small piece of James, then someone could 
use Digester to manage that.

> "Divide et Impera": put the config in more than one file. A simple one 
> where most of the changes happen (this one could get a GUI/Wizard), and 
> another one(or more), that need restart of the server anyway(with 
> configs that might be very seldom changed).

I think we're talking different levels.  Basically we're heading towards 
James as a collection of PoJo's, and then we're talking about the ideal 
container for James.

My preference would be for a container that does hot-loading, supports 
splitting configuration into multiple files, and doesn't require us to 
care about what file made the change and appropriately hot-reload only 
the parts that need to be reloaded.

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

View raw message