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