In many systems, you need to use the configuration file to store configuration parameters. The configuration parameters are separate from the code mainly for convenience of modification. One common usage is to write database connection parameters (database server IP, username, password, etc.) in a configuration file, mainly that the system may replace the database, or the network may replace the IP address range, or the server IP may Change, etc.
Configuration parameters are not limited to configuration files, but also save other places, such as database alone save configuration parameters, or in memory, or in operating system environment variables, and so on. There is a ready-made reading and writing configuration data kit, which makes people feel very good.
Early profiles mainly use INI files, or similar in INI file format. This configuration file is simple, and the corresponding read and write tool class is also easy to write. Various development languages can basically find ready-made code online. Its main feature is that Key <-> value corresponds to. The INI file is a plain text file. There is not much difficulty in modifying the INI profile for the end user of the programmer. In contrast, the configuration in other formats is more difficult than INI.
Unfortunately, the Common Configuration Toolkit does not support ini format. Documentation says it supports configuration parameters:
* Properties Files
* XML Documents
* Property List files (.plist)
* JNDI
* JDBC DataSource
* System Properties
* Applet Parameters
* Servlet Parameters
Data forms are also not limited to the key <-> value form, and the CommON Configuration Toolkit also supports parameter configuration of the tree structure.
The Common Configuration toolkit system is relatively simple. A basic configuration interface defines a variety of configured operations, an AbstractConfiguration to implement all public operations from Configuration Interface, leaving an uncommon function getProperty, setProperty waits for subclass implementation. Truely actually operated DatabaseConfiguration, PropertiesConfiguration, XmlConfiguration, XmlpropertiesConfiguration, MapConfiguration, etc. are inherited from AbstractConfiguration from AbstractConfiguration. MapConfiguration is a memory-based configuration parameter read and write tool class. XMLPropertiesConfiguration is a configuration file read and write tool class based on an XML file in an imitation of Java Properties format. Is it a bit strange? Mainly because the Java Property file is originally designed to store multilingual characters, some Java programmers want to have profiles similar to INI files in Java, but there is no ready-made tool class in JDK, only with the Property file. Use. For example, log4j can use the profile of the Property format. However, this format has a big weakness, and if it contains non-ASCII characters, such as Chinese, you must write into Unicode encoding format. If the software is delivered to the user, the user needs to change a parameter, and the user has no way to change this Property file. XMLPropertiesConfiguration uses an XML format profile, which is generally encoded with UTF-8, which can be modified with software that comes with the usage operating system (such as Windows Notepad Programs), which is more convenient. The XML Property format configuration file is now much more, and an XML Property format is also defined in J2SE 5.0. The XMLPropertiesConfiguration tool class is followed by this formatting standard. Configuration interface defines the basic operations: addProperty, clear, clearProperty, containsKey, getBigDecimal, getBigInteger, getBoolean, getByte, getDouble, getFloat, getInt, getKeys, getList, getLong, getProperties, getProperty, getShort, getString, getStringArray, isEmpty, setProperty etc. Wait. It seems to be relatively complete. You can also use DataConfiguration to re-package existing Configuration, then read and write other types of configuration parameters: URL, Locale, Date, Calendar, Color, and ARRAYS for various forms of objects. The main thing for DataConfiguration is to convert these additional type data with String types while reading and writing configuration data, and finally all configuration parameters are still saved into string form.
There is another class CompositeConfiguration, you can use several configuration together, this is not common, occasionally it will be used. For example, putting the database connection parameters in the file type profile, putting the other parameters in the database is a relatively common design. If several programmers simultaneously debug programs, you may need to set the same configuration parameters in the database to different values, this time is more troublesome, you have to quarrel. At this time, you can configure the file configuration and database configuration into a combination configured CompositeConfiguration, prioritize the parameters in the file type configuration, if the file is not read in the database in the file configuration parameter. This can be solved. When you are finally updated, put all configurations in the database, leaving only the database connection configuration is placed in the file type configuration. It is worth noting that some Configuration performance is not optimized, and you may need to write a corresponding subclass to rewrite the functions such as getProperty, SetProperty. The ready-made ideas is that DatabaseConfiguration reads a database each time getProperty. If it is not in the cluster environment, you can read all configuration data once in a map, so that every time getProperty is fast.
In any case, Common Configuration is a very excellent Java toolkit. I noticed that in its development roadmap, INI format configuration plans to support in version 1.3, it should be said that INI format is not difficult, do not know why you want to put it in version 1.3 to achieve it. The version 1.3 also plans to support the Windows registry format configuration, personal feelings don't have a big place. Others some rare strange plans may be some of the universal demands that have some developers proposed. From the current development version of the bugzilla above, there is no more core BUG, which is more secure, it is recommended.
