diff --git a/src/site/xdoc/userguide/howto_reloading.xml b/src/site/xdoc/userguide/howto_reloading.xml
index 2c53b15f34..8a5d358484 100644
--- a/src/site/xdoc/userguide/howto_reloading.xml
+++ b/src/site/xdoc/userguide/howto_reloading.xml
@@ -16,8 +16,9 @@
limitations under the License.
-->
-ReloadingDetector
interface:
+
isReloadingRequired()
method is called to trigger
a check. The detector has to determine whether something has changed on
@@ -67,7 +69,6 @@
opportunity to reset itself so that new changes on the associated
configuration source can be detected.
The next component taking part in reloading is an instance of the
@@ -249,6 +250,7 @@ trigger.start();
parameters for file-based configurations and defined by the
FileBasedBuilderProperties
interface:
+
ReloadingDetectorFactory
to be used when the reloading
@@ -263,7 +265,6 @@ trigger.start();
value can be used to improve performance if there are many accesses to
a configuration builder in short intervals.So the recipe to activate reloading for a builder instance is as follows: +
ReloadingDetector
which is able to monitor
@@ -311,7 +313,6 @@ trigger.start();
of time (e.g. initiate a corresponding trigger as described earlier in
this chapter.append()
takes the configuration to be copied
as argument and adds all of its properties to the current configuration.These methods work fine if the target configuration is not a hierarchical configuration. If a hierarchical configuration is to be copied into @@ -58,6 +59,7 @@ properties of the source configuration, but the specific parent-child relations will probably be lost. If a hierarchical configuration needs to be copied, there are the following options: +
clone()
method can be used to create a copy of a
hierarchical configuration. This also works for non-hierarchical
@@ -74,7 +76,6 @@
copies the content of the specified configuration into the newly created
object.PropertiesLoaderSupport
.
This allows a configuration object to behave
+
java.util.Properties
object which can be passed on tosetProperties()
method allowing PropertyOverrideConfigurer
andPropertyPlaceholderConfigurer
to take advantage of Commons Configuration.
Previously this functionality was provided by the spring-modules-jakarta-commons library (CommonsConfigurationFactoryBean
).
As this library is no longer maintained, this is now supported directly by Commons Configuration.
If you've used this with Commons Configuration 1.x, just replace the spring-modules-jakarta-commons classname with
diff --git a/src/site/xdoc/userguide/howto_xml.xml b/src/site/xdoc/userguide/howto_xml.xml
index f39d269351..0b315a736c 100644
--- a/src/site/xdoc/userguide/howto_xml.xml
+++ b/src/site/xdoc/userguide/howto_xml.xml
@@ -16,8 +16,9 @@
limitations under the License.
-->
-
XMLBuilderProperties
interface defines settings specific to
XML configurations. This includes
+
DocumentBuilder
EntityResolver
A parameters object for an XML configuration can be obtained using
the xml()
method of a
diff --git a/src/site/xdoc/userguide/overview.xml b/src/site/xdoc/userguide/overview.xml
index a1eb3b7602..342f3f7fa7 100644
--- a/src/site/xdoc/userguide/overview.xml
+++ b/src/site/xdoc/userguide/overview.xml
@@ -16,7 +16,9 @@
limitations under the License.
-->
-
The names of these methods start with get
followed by their
data type. The getString()
method for instance will return
String values, getInt()
will operate on integers.
@@ -164,6 +167,7 @@
For manipulating properties or their values the following methods can be used: +
addProperty()
clear()
@@ -207,6 +206,7 @@ config.setListDelimiter(';'); ]]>
While this code is easy to write, there are some non-obvious problems: +
To overcome these problems, Commons Configuration uses a different approach for the creation of configuration objects based on @@ -310,11 +309,11 @@ PropertiesConfiguration config = builder.getConfiguration(); creating a combined configuration out of multiple sources: +
ConfigurationFactory
classDefaultConfigurationBuilder
class
The former has been removed. The functionality provided by
DefaultConfigurationBuilder
is still available, but the
@@ -411,6 +410,7 @@ PropertiesConfiguration config = builder.getConfiguration();
thread, there is no need for any synchronization. Typical usage modes are
reflected by different default implementations of the
Synchronizer
interface:
+
NoOpSynchronizer
does not use any synchronization at all.
@@ -420,6 +420,7 @@ PropertiesConfiguration config = builder.getConfiguration();
ReadWriteSynchronizer implements synchronization based on a
read/write lock.
Note that the default option is NoOpSynchronizer
. This means
that configuration objects are not thread-safe per default! You have to
change the synchronizer in order to make them safe for concurrent access.
@@ -444,6 +445,7 @@ PropertiesConfiguration config = builder.getConfiguration();
There are some other changes on classes with the goal to make them well-behaving citizens in a concurrent environment. This includes: +
Please refer to Configurations and
Concurrent Access for a full description of this complex topic.
diff --git a/src/site/xdoc/userguide/upgradeto2_x.xml b/src/site/xdoc/userguide/upgradeto2_x.xml
index 8f3a9154b1..6ce5115538 100644
--- a/src/site/xdoc/userguide/upgradeto2_x.xml
+++ b/src/site/xdoc/userguide/upgradeto2_x.xml
@@ -16,8 +16,9 @@
limitations under the License.
-->
-
-
+