Introduction to Apache Jakarta common configuration

In many systems, configuration files are used to store configuration parameters. Configuration parameters are proposed separately from the code for convenience of modification. A common usage is to write database connection parameters (Database Server IP address, user name, password, and so on) in a configuration file. This is mainly because the system may change the database, or the network may change the IP address range, or the Server IP address may change.
　　
Configuration parameters are not limited to configuration files, but can also be stored in other places. For example, the database saves configuration parameters in a single table, in memory, or in operating system environment variables. There is a ready-made read/write configuration data toolkit, which makes people feel very good.
　　
Early configuration files mainly use INI files, or are similar to ini files. The configuration file format is simple, and the corresponding read/write tool classes are also easy to write. the ready-made code can be found on the Internet in various development languages. Its main feature is key <--> value. The INI file is a plain text file. for end users who are not programmers, it is not difficult to modify the ini configuration file. In comparison, configurations in other formats are more difficult than those in ini.

Unfortunately, the common configuration toolkit does not support the INI format. The document says that it supports the following configuration parameter sources:
* Properties files
* XML documents
* Property list files (. plist)
* JNDI
* JDBC datasource
* System Properties
* Applet Parameters
* Servlet Parameters

The data format is not limited to the key <--> value format. The common configuration toolkit also supports parameter configuration in the tree structure.

The common configuration toolkit system is relatively simple. A basic configuration interface defines various common configuration operations. A abstractconfiguration implements all common operations from the configuration interface, leaving an ununiversal function getproperty, and setproperty waits for the subclass to be implemented. The databaseconfiguration, propertiesconfiguration, xmlconfiguration, xmlpropertiesconfiguration, and mapconfiguration that are actually operated are inherited from abstractconfiguration. Mapconfiguration is a configuration parameter read/write tool class based on memory operations, while xmlpropertiesconfiguration is a configuration file read/write tool class that imitates Java properties format based on XML files. A little weird, right? This is mainly because the Java property file was originally designed to store multilingual strings. Some Java programmers want to have configuration files similar to ini files in Java, but there is no ready-made tool class in JDK, only the property file can be used together. For example, log4j can use the property configuration file. However, configuration files in this format have a major weakness. If they contain non-ASCII characters, such as Chinese characters, they must be written in Unicode encoding format. If the software is delivered to the user, the user needs to change a parameter, and the user cannot change the property file. Xmlpropertiesconfiguration uses the XML format configuration file, generally uses UTF-8 encoding, this file can be modified with commonly used operating system software (such as Windows Notepad program), so more convenient. The XML property format configuration file is now used a lot. In j2se 5.0, an XML property format is also defined. The xmlpropertiesconfiguration tool class follows this format standard.

Configuration interface defines some basic operations: addproperty, clear, clearproperty, containskey, getbigdecimal, getbiginteger, getboolean, getbyte, getdouble, getfloat, getint, getkeys, getlist, getlong, getproperties, getproperty, getshort, getstring, getstringarray, isempty, and setproperty. It looks quite complete. You can also use dataconfiguration to rewrap the existing configuration, and then read and write other types of configuration parameters: URL, locale, date, calendar, color, and lists and arrays of various forms of objects. The main task of dataconfiguration is to convert these extra types of data and the string type when reading and writing configuration data, and finally save all configuration parameters as strings.

There is another class compositeconfiguration, which can be used together. This is uncommon and occasionally used. For example, it is a common design to place database connection parameters in a file configuration file and other system parameters in a database. If several programmers debug the program at the same time, they may need to set the same configuration parameter in the database to a different value. This is a tough time to argue. In this case, you can combine the file configuration and database configuration into a compositeconfiguration to read the parameters in the file configuration first. If the file configuration parameters do not exist, the database parameters are read. This will solve the problem. When the system is finally delivered, all the configurations are placed in the database, leaving only the database connection configuration in the file configuration.

It is worth noting that some configuration performance is not optimized enough. You may need to write a subclass to rewrite functions such as getproperty and setproperty. The existing idea is that databaseconfiguration reads the database every time getproperty is read. If it is not in the cluster environment, you can read all the configuration data once and put it in a map, so that getproperty is much faster each time.

In any case, common configuration is an excellent Java toolkit. I noticed that in roadmap development, the INI format configuration plan is supported in version 1.3. It should be said that the INI format is not difficult. I don't know why it can be implemented only in version 1.3. Version 1.3 also plans to support the configuration of the Windows registry format. I personally think it is of no great use. Some other strange plans may be some less common requirements put forward by some developers. From the current development version of Bugzilla, there are no core bugs, which are reassuring and worthy of recommendation.