Re: Configuration API

[Stefano Bagnara <ap...@bago.org>]

Noel J. Bergman wrote:
> So I would move to use Jakarta Commons Configuration for JAMES, rather than
> the Avalon configuration, for both JAMES and the Mailet API (caveat: Danny
> suggests that we have our own, similar, configuration API in Mailet, and use
> Commons Configuration for the implementation).  That was already on the
> Avalon roadmap before the projected imploded.
> 
> 	--- Noel

Why? What are the advantages of this step?
We also talked about OSGi: OSGi has its own preference framework.

IMHO while we are under phoenix it does not bring us any new advantage 
to introduce commons-configuration.

That said, I'm against a "move to commons configuration" as is.

Once we have a roadmap where the move to commons configuration is 
clearly the right way or once I already see at least one new feature we 
can add to james because of the move to commons-configuration I will be 
more happy to be +1 to this idea.

I would be +1 for anything that could give us:
1) Import/Export of configurations
2) On the fly reconfiguration apis
3) JNDI *AND* XML persistence
4) Automatic JMX management
5) a GUI (GUI framework) to manage the configuration.
6) read/write configuration (bidirectional): the changes made on-the-fly 
shuld be persisted for the following reboots.

Now the thing more near to this requirements is probably the eclipse 
preferences framework.

Please note that we had a discussion that somehow, like most of our 
discussions, ended in nothing done and you can find some references here:

JAMES-495 is an issue I created to track the analysis of this issue and
"RE: [jira] Commented: (JAMES-495) Decide how to replace Avalon 
Configuration" is a long thread where we talked about this stuff.

http://issues.apache.org/jira/browse/JAMES-495
http://www.mail-archive.com/server-dev@james.apache.org/msg07272.html

If you search the archives near that thread you will find more.

So, what I'm saying is not that I'm against commons-configuration, but 
not now without an anaysis of what is the goal/roadmap and what are the 
advantages of introducing commons-configuration.

About the idea of introducing our own interfaces over the configuration 
I'm -1 now: Avalon Configuration interfaces are simple, commons 
configuration interfaces too.. I would introduce a new custom 
configuration only if an already existing one is not enough for us and I 
would think twice because it would means that we're going to write our 
own configuration framework.

Stefano


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