Java 配置框架

If your hardcoded values are just simple key-value pairs, you should look at java.util.Properties. It's a lot simpler than xml, easier to use, and mind-numbingly trivial to implement.

If you are working with Java and the data you are storing or retrieving from disk is modeled as a key value pair (which it sounds like it is in your case), then I really can't imagine a better solution.

I have used properties files for simple configuration of small packages in a bigger project, and as a more global configuration for a whole project, and I have never had problems with it.

Of course this has the huge benefit of not requiring any 3rd party libraries to utilize.

I tend to use java.util.Properties (or similar classes in other languages and frameworks) wrapped in an application-specific configuration class most of the time, but I am very interested in alternatives or variations on this. Especially since things can become a bit tricky if graphical configuration dialogs or multiple views on the configuration data is involved.

Unfortunately I don't have any experience with specific libraries for Java (except with the ones I have written myself), but any pointers would be appreciated.

Update

OK. That wasn't entirely true, three is the Spring Java Configuration Project.

I wrote about this a couple of weeks ago and came to the conclusion that XML is one of the most widely used notations.

Is it the best? I don't think so, I really like JSON, but the tooling is still not up to XML so I guess we have to wait and see.

Commons Configuration

We're using this. Properties files alone are much easier to handle, but if you need to represent more complex data commons configuration can do this and read your properties files as well.

If you aren't doing anything complicated I'd stick to properites files.

Apache Commons Configuration works great. It supports having the configuration stored in a wide range of formats on the backend including properties, XML, JNDI, and more. It is easy to use and to extend. To get the most flexibility out of it use a factory to get the configuration and just use the Configuration interface after that.

Two feature of Commons Configuration that differentiate it over a straight Properties file is that it support automatic conversion to common types (int, float, String arrays) and it supports property substitution:

server.host=myHost
server.url=http://${server.host}/somePath

If you want to do something advanced (and typesafe), you might want to take a look at this: http://www.ibm.com/developerworks/java/library/j-configint/index.html

Properties files a very simple, if you need something more functional, you could format some of your configuration files as Java classes. These can be placed in a different package/module and can be pre-compiled or loaded at runtime with a library like BeanShell.

Note: In the simplest case (pre-compiled) you don't need any additional libraries.

Regarding the suggestions to use java.util.Properties - starting in jdk 1.5, the Preferences API (java.util.prefs) appears to be the preferred alternative to using the Properties API.

Reasons: increased scalability, back-end neutrality, ect.

Here are various options:

• java.util.Properties
• java.util.prefs.Preferences (since Java 5)
• Commons Configuration
• jConfig
• JFig
• Carbon's Configuration Service

You might want to read Comparison of Commons Configuration With JFig and JConfig and Configuring your Applications using JFig for some feedback from various users.

Personally, I've used jConfig and it was a good experience.

You can try YamlBeans. This way you write whatever classes you want to hold your config data, then you can automatically write and read them to and from YAML.

YAML is a human readable data format. It has more expressive power than java.util.Properties. You can have lists, maps, anchors, typed data, etc.

Please take a look at this URL: http://issues.apache.org/jira/browse/CONFIGURATION-394

The Configuration framework which we're looking for it is something on top of Apache Commons Configuration and must support Concurrency Issues, JMX issues and most of stores(e.g .properties file, .xml files or PreferencesAPI).

What weblogic team provides on 'Administration Console' is intersting which through it you can have transactional(atomic) updates on configurations so that are registered listeners be notified.

The Apache guys insist that this project is out of scopes of Commons Configuration, maybe!

I've attached a simple configuration framework, take look please.

I just posted a brief bit of code about using Spring's ClassPathResource as an alternative to IoC. ClassPathResource permits you to place property files anywhere on the classpath (e.g., all in one place, or as peers to the code they configure. My example just uses java.util.Properties, so you can use the plaintext "name=value" style or its XML format.

You could have a look at newly announced tools4j-config whose mission statement is to allow you to easily handle configuration at runtime.

the Intelligent Parameter Utilization Tool (InPUT, page) allows to externalize almost any (hard coded) decision as a parameter into an XML based configuration file. It has been initiated in early 2012 as a response to the perceived deficiencies in existing configuration tools with respect to generality, and separation of concerns.

InPUT is probably more powerful than most use cases require, as it allows for the programming language independent formulation of experimental data (input - output), with features such as the definition of complex descriptor to class mappings, or randomized configuration spawning and validation based on predefined value ranges (for test and research, e.g. Monte Carlo simulations). You can define parameters with sub parameters, relative restrictions on parameter values (numerical param a > param b) etc. .

Its still in beta, but rather stable, I use it for my research, for the configuration and documentation of experiments, and for teaching purposes. Once it is available for other languages (C++ adapter in the pipe), other researchers/practitioners can reuse the descriptors running their implementations of the same algorithms in C++ (using the code mapping concept). That way, experimental results can be validated/programs can be migrated more easily. The documentation is still in working process, but a couple of examples are available on the page. InPUT is open source software.

For those interested, the Conceptual Research Paper.