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. [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
