Hi Ioan,
We use the HierarchicalConfiguration as its name implies, has some
notion of hierarchy in the configuration.
It also allows to move from XML to YAML for example (btw, I think we
should revert back from ".conf" to ".xml" to allow different
configuration formats).
Using simple properties file is possible with some fancy key naming. But
if we are only able to use those properties/preferences file, I think we
are downgrading the current powerfull solution we have we
commons-configuration.
About the OSGI option, I don't know really what this implies. I would
simply say the requirement for James that it is not needed to run in a
OSGI (Karaf...) container. OSGI Love is not mandatory for all our users.
Also, moving to something else must IMHO bring some added value such as
hot-reload, which is more a injection framework issue that a
configuration format/storage.
The best thing to do is to develop this in a branch so we don't impact
the curent code base as this will make all instable (build, working,
documentation...) for some time. Just committing such difficult parts in
trunk is not an option.
Thx, Eric
On 13/01/2013 06:35, Ioan Eugen Stan wrote:
Hello,
I've added Jean Baptiste and Robert Munteanu, who are not subscribed.
JB, Robert, feel free to not participate if you are not
interested/don't have time.
Eric, your help is needed.
I wish to refactor out commons-configuration in favor for a more OSGi
friendly option. I'm still researching a good solution and I'm also
open to suggestions. The main driver is to make it more OSGi friendly,
simplify things under the constraints defined by [a].
Commons-configuration brings a lot of commons-* dependencies which I
would like to see gone (less is more).
I have two options: java.util.prefs.Preferences [1]- [6] and OSGi
Configuration Admin [7]-[9].
Configuration admin has a simple interface but depend on one osgi
artifact, while Preferences are standard Java. Other than that they
seem to be equal with regard to features, also support what
commons-configuration has to offer. I believe support all the
restrictions defined by [a].
Thank you,
Important James Issues related to this:
[a] https://issues.apache.org/jira/browse/JAMES-495
[1]
http://docs.oracle.com/javase/1.4.2/docs/api/java/util/prefs/Preferences.html
[2]
http://docs.oracle.com/javase/1.5.0/docs/guide/preferences/index.html#prefs-other
[3] http://code.google.com/p/java-util-prefs-jdbc-backend/
[4]
http://devlearnings.wordpress.com/2010/11/12/use-java-util-prefs-preferences-instead-of-java-util-properties/
[5]
http://www.davidc.net/programming/java/java-preferences-using-file-backing-store
[6]
http://docs.oracle.com/javase/1.5.0/docs/api/java/util/prefs/Preferences.html#addNodeChangeListener(java.util.prefs.NodeChangeListener)
[7] http://www.osgi.org/javadoc/r4v42/org/osgi/service/cm/ManagedService.html
[8]
http://stackoverflow.com/questions/10225467/how-to-externalize-the-configuration-of-bundles
[9] http://felix.apache.org/site/apache-felix-config-admin.html
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
