Author: oheger
Date: Mon Aug 13 19:59:11 2018
New Revision: 1837978
URL: http://svn.apache.org/viewvc?rev=1837978&view=rev
Log:
[CONFIGURATION-710] Fixes for typos in user guides.
Thanks to thc202 for the patch.
Modified:
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_basicfeatures.xml
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_beans.xml
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_builders.xml
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_combinedbuilder.xml
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_combinedconfiguration.xml
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_concurrency.xml
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_events.xml
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_filebased.xml
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_hierarchical.xml
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_multitenant.xml
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_properties.xml
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_reloading.xml
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_xml.xml
commons/proper/configuration/trunk/src/site/xdoc/userguide/quick_start.xml
commons/proper/configuration/trunk/src/site/xdoc/userguide/upgradeto2_0.xml
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_basicfeatures.xml
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_beans.xml
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_combinedconfiguration.xml
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_configurationbuilder.xml
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_events.xml
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_filebased.xml
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_multitenant.xml
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_properties.xml
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_xml.xml
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/overview.xml
Modified:
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_basicfeatures.xml
URL:
http://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_basicfeatures.xml?rev=1837978&r1=1837977&r2=1837978&view=diff
==============================================================================
---
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_basicfeatures.xml
(original)
+++
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_basicfeatures.xml
Mon Aug 13 19:59:11 2018
@@ -338,7 +338,7 @@ interpolator.registerLookup("echo", new
<code>Lookup</code> objects as values. This map can then be passed to the
<code>setPrefixLookup()</code> method of a parameters object for the
builder. Note that the lookups for the default prefixes are added
- explicitly; ommitting a lookup would remove support for the corresponding
+ explicitly; omitting a lookup would remove support for the corresponding
prefix:
</p>
<source><![CDATA[
@@ -360,7 +360,7 @@ PropertiesConfiguration config = builder
<subsection name="Using Expressions">
<p>
- In addition to the simple lookup mechanisms previously described,
Commond Configuration
+ In addition to the simple lookup mechanisms previously described,
Commons Configuration
provides <code>ExprLookup</code> which uses <a
href="http://commons.apache.org/jexl";>Apache
Commons Jexl</a> to allow expressions to be resolved wherever a
StrLookup is allowed. This
example shows an alternate way of obtaining a system property if the
ExprLookup is
Modified:
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_beans.xml
URL:
http://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_beans.xml?rev=1837978&r1=1837977&r2=1837978&view=diff
==============================================================================
--- commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_beans.xml
(original)
+++ commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_beans.xml
Mon Aug 13 19:59:11 2018
@@ -268,7 +268,7 @@ public class WindowStyleDefinition
In order to create an instance of <code>WindowStyleDefinition</code>,
we have to pass the foreground and background colors and a standard
font to the constructor. The colors are simple strings while a font is
- again a complex object. The following code fragement shows the complete
+ again a complex object. The following code fragment shows the complete
bean declaration for this scenario:
</p>
<source><![CDATA[
@@ -451,7 +451,7 @@ public class MyBean
class already an instance exists. If this is the case, it is directly
returned. Otherwise we call the inherited <code>createBean()</code>
method
and store its result in the map. (Note that this implementation is a
bit
- simplicistic. A real world implementation would also have to take
+ simplistic. A real world implementation would also have to take
initialization parameters into account and use a more sophisticated
approach to deal with concurrency issues. But for the purpose of an
example it should be good enough). Here is the code:
Modified:
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_builders.xml
URL:
http://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_builders.xml?rev=1837978&r1=1837977&r2=1837978&view=diff
==============================================================================
---
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_builders.xml
(original)
+++
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_builders.xml
Mon Aug 13 19:59:11 2018
@@ -165,7 +165,7 @@ PropertiesConfiguration config = builder
parameter objects for special <code>Configuration</code> classes. On
the objects returned by these methods fluent <code>set</code> methods can
be invoked in order to set the single properties. As an example consider
- the following code fragement which defines some properties for an
+ the following code fragment which defines some properties for an
<code>XMLConfiguration</code>:
</p>
<source><![CDATA[
@@ -229,7 +229,7 @@ XMLBuilderParams xmlParams = params.xml(
<td><code>hierarchical()</code></td>
<td><code><a
href="../apidocs/org/apache/commons/configuration2/builder/fluent/HierarchicalBuilderParameters.html">
HierarchicalBuilderParameters</a></code></td>
- <td>Here special parameters common to all hierarchical configuratios
are
+ <td>Here special parameters common to all hierarchical configurations
are
defined, for instance the expression engine.</td>
</tr>
<tr>
@@ -311,7 +311,7 @@ XMLBuilderParams xmlParams = params.xml(
already shown how an instance of the
<code><a
href="../apidocs/org/apache/commons/configuration2/builder/fluent/Parameters.html">
Parameters</a></code> class is used to create initialization parameter
- objects for various types of configuration sources. In addtion to the
+ objects for various types of configuration sources. In addition to the
methods for creating these objects, <code>Parameters</code> also deals
with default values for them. The mechanisms are as follows:
</p>
@@ -397,9 +397,9 @@ params.registerDefaultsHandler(Propertie
This registration of defaults handlers could be done in the startup phase
of an application. The <code>Parameters</code> class is thread-safe, so
an application can create and configure a single instance and use it
- accross all modules to create parameter objects. The actual functionality
+ across all modules to create parameter objects. The actual functionality
of managing and invoking <code>DefaultParametersHandler</code> objects is
- implememented by the
+ implemented by the
<code><a
href="../apidocs/org/apache/commons/configuration2/builder/DefaultParametersHandler.html">
DefaultParametersManager</a></code> class - <code>Parameters</code> just
delegates to a wrapped instance. In some usage scenarios it may make
sense
Modified:
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_combinedbuilder.xml
URL:
http://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_combinedbuilder.xml?rev=1837978&r1=1837977&r2=1837978&view=diff
==============================================================================
---
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_combinedbuilder.xml
(original)
+++
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_combinedbuilder.xml
Mon Aug 13 19:59:11 2018
@@ -33,7 +33,7 @@
files each of which is related to a specific sub-domain. This makes it
easier for users or administrators to adapt specific configuration
settings. However, rather than reading multiple files and dealing with
- multiple <code>Configuration</code> objects, an application propably
+ multiple <code>Configuration</code> objects, an application probably
prefers a combined view on its configuration data. <em>Commons
Configuration</em> supports this use case with a special configuration
builder implementation:
@@ -177,7 +177,7 @@ CombinedConfiguration config = builder.g
Just defining the configuration definition file
via a file-based parameters object is a special case. Internally, a
builder
for an <code>XMLConfiguration</code> object is constructed which is then
- used to load and interprete the definition file. This should be
appropriate
+ used to load and interpret the definition file. This should be
appropriate
for many cases. A drawback of this method is that there is no way to set
additional initialization parameters for the
<code>CombinedConfigurationBuilder</code>. For this purpose, a special
@@ -254,7 +254,7 @@ CombinedConfigurationBuilder builder = c
Using <code>CombinedConfigurationBuilder</code> to collect configuration
sources does not make much sense if there is only a single source to be
loaded. So let's add another one to the example definition file used
- before! This time we will embedd a XML file: <em>gui.xml</em> which is
+ before! This time we will embed a XML file: <em>gui.xml</em> which is
shown in the next listing:
</p>
<source><![CDATA[
@@ -312,7 +312,7 @@ CombinedConfigurationBuilder builder = c
settings in another. Then in the configuration definition file the file
with the user settings is included first and after that the file with the
default values. The application code that queries these settings does not
- have to bother whether a property was overriden by the user.
<code>CombinedConfigurationBuilder</code>
+ have to bother whether a property was overridden by the user.
<code>CombinedConfigurationBuilder</code>
takes care that properties defined in the first file (the user file) are
found; other properties which the user has not changed will still be
returned from the second file (the defaults file).
@@ -396,7 +396,7 @@ CombinedConfigurationBuilder builder = c
<p>
In an earlier section about the configuration definition file for
<code>CombinedConfigurationBuilder</code> it was stated that
configuration
- files included first can override properties in configuraton files
+ files included first can override properties in configuration files
included later, and an example use case for this behaviour was given.
There
may be cases when there are other requirements.
</p>
@@ -500,11 +500,11 @@ CombinedConfigurationBuilder builder = c
this section are treated as if they were children of the root element,
i.e.
properties in the included configuration sources override properties in
sources included later. So the <code><override></code> tags could
have
- been ommitted, but for the sake of clearity it is recommended to use them
+ been omitted, but for the sake of clarity it is recommended to use them
if there is also an <code><additional></code> section.
</p>
<p>
- It is the <code><additonal></code> section that introduces a new
behaviour.
+ It is the <code><additional></code> section that introduces a new
behaviour.
All configuration sources listed here are combined to a union
configuration.
In our example we have put two <code>xml</code> elements in this area
that load the available files with database table definitions. The syntax
@@ -514,7 +514,7 @@ CombinedConfigurationBuilder builder = c
configuration where the included properties are to be added. Here it is
set
for the second element to the value <em>tables</em>. This is because the
file starts with a <code><table></code> element, but to be
compatible
- with the other table definition file it should be accessable under the
key
+ with the other table definition file it should be accessible under the
key
<code>tables.table</code>.
</p>
<p>
@@ -526,7 +526,7 @@ CombinedConfigurationBuilder builder = c
</p>
<p>
Note that it is also possible to override properties defined in an
- <code>additonal</code> section. This can be done by placing a
configuration
+ <code>additional</code> section. This can be done by placing a
configuration
source in the <code>override</code> section that defines properties that
are also defined in one of the sources listed in the
<code>additional</code>
section. The example does not make use of that. Note also that the order
of
@@ -923,7 +923,7 @@ CombinedConfigurationBuilder builder = c
document type definition or a schema defining exactly the structure of a
configuration definition file. Frankly, the answer is no. This is due to
the fact that the format is extensible. As will be shown below, it is
- possible to register your own tags in order to embedd custom
configuration
+ possible to register your own tags in order to embed custom configuration
sources.
</p>
</subsection>
@@ -955,7 +955,7 @@ CombinedConfigurationBuilder builder = c
<code><a
href="../apidocs/org/apache/commons/configuration2/reloading/ReloadingController.html">
ReloadingController</a></code> that can be used to trigger reloading
checks. (Please refer to the chapter about <a
href="howto_reloading.html">reloading</a>
- for a detailed describtion of the reloading implementation in <em>Commons
+ for a detailed description of the reloading implementation in <em>Commons
Configuration</em> and the components involved.)
</p>
<p>
@@ -1367,7 +1367,7 @@ CombinedConfiguration config = builder.g
complex; multiple parameter objects have to be dealt with.
</p>
<p>
- A more lite-weight alternative is the ability of a combined configuration
+ A more lightweight alternative is the ability of a combined configuration
builder to inherit its parameters to the child configurations created by
it. This feature is enabled by default and it works as follows: Whenever
a parameter object for a child configuration source is created, it is
Modified:
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_combinedconfiguration.xml
URL:
http://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_combinedconfiguration.xml?rev=1837978&r1=1837977&r2=1837978&view=diff
==============================================================================
---
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_combinedconfiguration.xml
(original)
+++
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_combinedconfiguration.xml
Mon Aug 13 19:59:11 2018
@@ -36,7 +36,7 @@
</p>
<p>
<ul>
- <li>A <code>CombinedConfiguration</code> is a truely
+ <li>A <code>CombinedConfiguration</code> is a truly
<a href="howto_xml.html#Hierarchical properties">hierarchical
configuration</a>. This means that all the enhanced facilities
provided by <code>HierarchicalConfiguration</code> (e.g. expression
@@ -215,7 +215,7 @@
node is necessary only in situations where there is ambiguity. If in one
of our example configuration sources multiple tables had been defined,
the
node combiner would have concluded itself that <code>table</code> is a
list
- node and would have acted correspondigly.
+ node and would have acted correspondingly.
</p>
<p>
The examples that follow are provided to further illustrate the
differences
Modified:
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_concurrency.xml
URL:
http://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_concurrency.xml?rev=1837978&r1=1837977&r2=1837978&view=diff
==============================================================================
---
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_concurrency.xml
(original)
+++
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_concurrency.xml
Mon Aug 13 19:59:11 2018
@@ -313,7 +313,7 @@ finally
<code>Synchronizer</code> object. However, the builders dealing with
affected classes are implemented in a way that they take care about these
special cases and perform extra initialization steps which make write
- locks for later read operations unneccessary.
+ locks for later read operations unnecessary.
</p>
<p>
For instance, the builder for combined configurations explicitly accesses
Modified:
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_events.xml
URL:
http://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_events.xml?rev=1837978&r1=1837977&r2=1837978&view=diff
==============================================================================
--- commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_events.xml
(original)
+++ commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_events.xml
Mon Aug 13 19:59:11 2018
@@ -150,7 +150,7 @@
generic type. For instance, it would be called for an event of type
<code>ConfigurationEvent.ADD_PROPERTY</code>. In contrast, if a specific
event type is used for the event listener registration, only events of
- this type trigger this listener. The following code fragement shows how
+ this type trigger this listener. The following code fragment shows how
an event listener is registered at a configuration object for a specific
event type:
</p>
@@ -352,7 +352,7 @@ config.clearProperty("removedProperty");
<li><strong>ConfigurationErrorEvent.READ</strong> A sub type
indicating
that the error occurred while reading a property.</li>
<li><strong>ConfigurationErrorEvent.WRITE</strong> A sub type
- indicating that the error occured on an update operation. In this
+ indicating that the error occurred on an update operation. In this
case, an additional property of the event can be used to find out
which operation was performed: <code>errorOperationType</code>
returns an <code>EventType</code> object corresponding to the failed
@@ -406,7 +406,7 @@ config.clearProperty("removedProperty");
that a <a href="howto_reloading.html">reloading configuration
builder</a>
is used. When a need for a reload is detected the managed configuration
is replaced by a new instance. Event listener registrations directly
- done at the old instance are no longer active. In contranst, for event
+ done at the old instance are no longer active. In contrast, for event
listener registrations done via the configuration builder, the builder
ensures that all listeners are automatically added to a newly created
configuration instance and removed from an obsolete instance.</li>
@@ -509,7 +509,7 @@ builder.addEventListener(ConfigurationBu
listeners are correctly registered and unregistered. In section
<a href="#Configuration_Update_Events">Configuration Update Events</a>
we created a simple configuration event listener which just logged
- occuring update events. We can now show how this listener is
+ occurring update events. We can now show how this listener is
registered via the configuration builder:
</p>
<source><![CDATA[
Modified:
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_filebased.xml
URL:
http://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_filebased.xml?rev=1837978&r1=1837977&r2=1837978&view=diff
==============================================================================
---
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_filebased.xml
(original)
+++
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_filebased.xml
Mon Aug 13 19:59:11 2018
@@ -152,7 +152,7 @@ catch(ConfigurationException cex)
<code>FileBasedConfigurationBuilder</code> offers functionality for
automatically saving changes on its managed configuration. This can
be used to ensure that every modification of a configuration object is
- immideately written to disk. This feature is enabled via the
+ immediately written to disk. This feature is enabled via the
<code>setAutoSave()</code> method as shown in the following example:
</p>
<source><![CDATA[
@@ -370,7 +370,7 @@ FileHandler handler = new FileHandler(co
// Load another configuration source, for instance from a relative path
handler.load("user.properties");
-// Store the resulting configuguration in a new file
+// Store the resulting configuration in a new file
File out = new File("union.properties");
handler.save(out);
]]></source>
Modified:
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_hierarchical.xml
URL:
http://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_hierarchical.xml?rev=1837978&r1=1837977&r2=1837978&view=diff
==============================================================================
---
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_hierarchical.xml
(original)
+++
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_hierarchical.xml
Mon Aug 13 19:59:11 2018
@@ -96,7 +96,7 @@
<a href="howto_filebased.html">file-based</a> configuration classes
a <code><a
href="../apidocs/org/apache/commons/configuration2/builder/FileBasedConfigurationBuilder.html">
FileBasedConfigurationBuilder</a></code> is used for reading the source
- file as shown in the following code fragement:
+ file as shown in the following code fragment:
</p>
<source><![CDATA[
Parameters params = new Parameters();
@@ -594,7 +594,7 @@ config.addProperty("tables.table.fields.
<code>first</code> and <code>test</code>.)
</p>
<p>
- If we want a different behavior, we must explicitely tell
+ If we want a different behavior, we must explicitly tell
<code>addProperty()</code> what to do. In our example with the
new field our intension was to create a new branch for the
<code>field</code> part in the key, so that a new <code>field</code>
@@ -690,7 +690,7 @@ int testVal = config.getInt("test..value
String complex = config.getString("test..complex.test..sub..element");
]]></source>
<p>
- Note the duplicated dots whereever the dot does not act as
+ Note the duplicated dots wherever the dot does not act as
delimiter. This way it is possible to access properties containing
dots in arbitrary combination. However, as you can see, the
escaping can be confusing sometimes. So if you have a choice,
Modified:
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_multitenant.xml
URL:
http://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_multitenant.xml?rev=1837978&r1=1837977&r2=1837978&view=diff
==============================================================================
---
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_multitenant.xml
(original)
+++
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_multitenant.xml
Mon Aug 13 19:59:11 2018
@@ -31,7 +31,7 @@
that each client has its own unique configuration. The easiest
approach to enable an application to be multi-tenant is for it
to not really be aware of it at all. This requires that the
- configuration framework takes on some of the responsility for
+ configuration framework takes on some of the responsibility for
making the application work correctly.
</p>
<p>
@@ -218,7 +218,7 @@ XMLConfiguration config = builder.getCon
<subsection name="PatternSubtreeConfigurationWrapper">
<p>
Applications are often composed of many components each of which
need their
- own configuration. This can be accomodated by having a configuration
file
+ own configuration. This can be accommodated by having a
configuration file
per component, but this can make things hard to manage when there
are many
clients and many components. A second approach is to combine them
into
a single configuration file. However, this either means the
subcomponent
Modified:
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_properties.xml
URL:
http://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_properties.xml?rev=1837978&r1=1837977&r2=1837978&view=diff
==============================================================================
---
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_properties.xml
(original)
+++
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_properties.xml
Mon Aug 13 19:59:11 2018
@@ -264,7 +264,7 @@ config.dirs = \\\\\\\\share1,\\\\\\\\sha
way of defining a list: just use the same key multiple times. In this
case no additional escaping of backslashes (beyond the usual
duplicating
required by properties files) is needed because there is no list
- delimter character involved. Using this syntax the list of network
+ delimiter character involved. Using this syntax the list of network
shares looks like the following:
</p>
<source><![CDATA[
@@ -315,7 +315,7 @@ config.dirs = \\\\share2
<li><code>setBlancLinesBefore()</code><br/>
This methods allows defining the number of empty lines to be written
before the specified property. It can be used, for instance, to
- devide the properties file into multiple logical sections.</li>
+ divide the properties file into multiple logical sections.</li>
<li><code>setSingleLine()</code><br/>
If a property has multiple values, with <code>setSingleLine()</code> it
can be specified that all these values should be written into a single
Modified:
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_reloading.xml
URL:
http://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_reloading.xml?rev=1837978&r1=1837977&r2=1837978&view=diff
==============================================================================
---
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_reloading.xml
(original)
+++
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_reloading.xml
Mon Aug 13 19:59:11 2018
@@ -226,7 +226,7 @@ trigger.start();
from there every time configuration data is needed.
</p>
<p>
- Users familar with older versions of <em>Commons Configuration</em> will
+ Users familiar with older versions of <em>Commons Configuration</em> will
notice that this is a fundamental change compared to the old reloading
implementation. In the old implementation a reload could happen at any
time on a configuration the application was operating on. This had the
Modified:
commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_xml.xml
URL:
http://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_xml.xml?rev=1837978&r1=1837977&r2=1837978&view=diff
==============================================================================
--- commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_xml.xml
(original)
+++ commons/proper/configuration/trunk/src/site/xdoc/userguide/howto_xml.xml
Mon Aug 13 19:59:11 2018
@@ -124,7 +124,7 @@ XMLConfiguration config = builder.getCon
DefaultEntityResolver</a></code> class. This implementation is
initialized
by calling the <code>registerEntityId()</code> method with the
public IDs of the entities to be retrieved and their corresponding
- local URLs. Then the instance is passed to the configuation
builder's
+ local URLs. Then the instance is passed to the configuration
builder's
initialization parameters. As an example, consider that the DTD
file for
our example document is stored on the class path. We can register
it
at <code>XMLConfiguration</code> using the following code:
@@ -165,7 +165,7 @@ XMLConfiguration config = builder.getCon
<p>
<a
href="http://xml.apache.org/commons/components/resolver/resolver-article.html#s.whats.wrong";>XML
Entity and URI Resolvers</a> describes using a set of catalog
files to
- resolve enitities. <em>Commons Configuration</em> provides support
for
+ resolve entities. <em>Commons Configuration</em> provides support
for
this Catalog Resolver through its own
<code><a
href="../apidocs/org/apache/commons/configuration2/resolver/CatalogResolver.html">
CatalogResolver</a></code> class.
@@ -221,7 +221,7 @@ XMLConfiguration config = builder.getCon
where they are not. <code>XMLConfiguration</code> provides two
extension mechanisms
that should provide applications with all the flexibility they may
need. The first, registering a custom Entity Resolver has already
been
- discussed in the preceeding section. The second is that
<code>XMLConfiguration</code>
+ discussed in the preceding section. The second is that
<code>XMLConfiguration</code>
provides a generic way of setting up the XML parser to use: A
preconfigured
<code>DocumentBuilder</code> object can be passed to the
initialization parameters of the configuration builder.
Modified:
commons/proper/configuration/trunk/src/site/xdoc/userguide/quick_start.xml
URL:
http://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/site/xdoc/userguide/quick_start.xml?rev=1837978&r1=1837977&r2=1837978&view=diff
==============================================================================
--- commons/proper/configuration/trunk/src/site/xdoc/userguide/quick_start.xml
(original)
+++ commons/proper/configuration/trunk/src/site/xdoc/userguide/quick_start.xml
Mon Aug 13 19:59:11 2018
@@ -163,7 +163,7 @@ String stage = config.getString("process
List<String> paths = config.getList(String.class, "processing.paths.path");
]]></source>
<p>
- The keys for properties are generated by concatening the possibly nested
+ The keys for properties are generated by concatenating the possibly
nested
tag names in the XML document (ignoring the root element). For
attributes,
there is a special syntax as shown for the <em>stage</em> property.
Because the <em>path</em> element appears multiple times it actually
@@ -217,7 +217,7 @@ config.addProperty("database.type", "pro
<p>
After a configuration has been manipulated, it should probably be saved
again to make the changes persistent. Otherwise, the changes are only in
- memory. If configurations are to be changed, it is preferrable to obtain
+ memory. If configurations are to be changed, it is preferable to obtain
them via a different mechanism: a <em>configuration builder</em>.
Builders are the most powerful and flexible way to construct
configurations. They support many settings that impact the way the
@@ -241,7 +241,7 @@ try
// obtain the configuration
FileBasedConfigurationBuilder<XMLConfiguration> builder =
configs.xmlBuilder("paths.xml");
XMLConfiguration config = builder.getConfiguration();
-
+
// update property
config.addProperty("newProperty", "newValue");
Modified:
commons/proper/configuration/trunk/src/site/xdoc/userguide/upgradeto2_0.xml
URL:
http://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/site/xdoc/userguide/upgradeto2_0.xml?rev=1837978&r1=1837977&r2=1837978&view=diff
==============================================================================
--- commons/proper/configuration/trunk/src/site/xdoc/userguide/upgradeto2_0.xml
(original)
+++ commons/proper/configuration/trunk/src/site/xdoc/userguide/upgradeto2_0.xml
Mon Aug 13 19:59:11 2018
@@ -56,7 +56,7 @@
changes to some of the problematic concepts or even replaced them by
alternative approaches. This has lead to an ambivalent situation: On one
hand, you will recognize many similarities to the old version - classes
- with familar names that continue to do what they have done before. On
+ with familiar names that continue to do what they have done before. On
the other hand, completely new approaches have been introduced; in the
affected areas <em>Commons Configuration</em> 2.0 will look like a
completely new product rather than a plain upgrade.
@@ -90,7 +90,7 @@
is real trouble: The class path then contains classes with identical
names in different versions - results will be unpredictable! The change
of the package name solves this problem because the new version can now
- co-exist with an old version without interfering. The very first step
+ coexist with an old version without interfering. The very first step
you have to when migrating to version 2.0 is to reorganize your imports
to adapt them to the new package name. Modern IDEs will support you with
this task.
@@ -109,7 +109,7 @@
]]></source>
<p>
So for Maven version 2.0 is a completely different artifact. This
- allows a peaceful co-existence of <em>Commons Configuration</em> 1.x and
+ allows a peaceful coexistence of <em>Commons Configuration</em> 1.x and
2.0 in the dependency set of a project.
</p>
</subsection>
@@ -408,7 +408,7 @@ PropertiesConfiguration config = builder
when executing operations on this configuration. By changing the
synchronizer, an application can adapt the locking behavior to its
specific
needs. For instance, if a configuration is only accessed by a single
- thread, there is no need for any synchronization. Typcical usage modes
are
+ thread, there is no need for any synchronization. Typical usage modes are
reflected by different default implementations of the
<code>Synchronizer</code> interface:
<ul>
@@ -431,7 +431,7 @@ PropertiesConfiguration config = builder
configuration data by multiple threads. Access to a builder is always
thread-safe. By shifting the responsibility for reloading operations from
the configuration to the builder, the need for intensive locking on each
- property access could be eleminated.
+ property access could be eliminated.
</p>
<p>
Hierarchical configurations derived from
Modified:
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_basicfeatures.xml
URL:
http://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_basicfeatures.xml?rev=1837978&r1=1837977&r2=1837978&view=diff
==============================================================================
---
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_basicfeatures.xml
(original)
+++
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_basicfeatures.xml
Mon Aug 13 19:59:11 2018
@@ -98,7 +98,7 @@ long longValue = config.getLong("NonExis
to these methods can be a list or an array resulting in a property
with multiple values. If the property value is a string, it is checked
whether it contains the <em>list delimiter character</em>. If this is
- the case, the string is splitted, and its single parts are added one
+ the case, the string is split, and its single parts are added one
by one. The list delimiter character is the comma by default. It is
also taken into account when the configuration source is loaded
(i.e. string values of properties will be checked whether they contain
@@ -347,7 +347,7 @@ user.file = ${expr:System.getProperty("u
</lookups>
</header>
<override>
- <xml fileName="${expr:$[sys:basePath] +
+ <xml fileName="${expr:$[sys:basePath] +
String.lowercase(net.localHost.hostName) +
'/testMultiConfiguration_default.xml'}"
config-name="defaultConfig" delimiterParsingDisabled="true">
</xml>
Modified:
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_beans.xml
URL:
http://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_beans.xml?rev=1837978&r1=1837977&r2=1837978&view=diff
==============================================================================
---
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_beans.xml
(original)
+++
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_beans.xml
Mon Aug 13 19:59:11 2018
@@ -95,7 +95,7 @@
provided, which in many cases can be used out of the box.
</p>
</subsection>
-
+
<subsection name="An Example">
<p>
After this theory let's get into practice using an example. Consider a
@@ -122,13 +122,13 @@ public class DefaultWindowManager implem
private boolean resizable;
// do windows have a close button?
private boolean closable;
-
+
// Default size of new windows
private int defaultWidth;
private int defaultHeight;
-
+
WindowStyleDefinition styleDefinition;
-
+
// getters and setters ommitted, also the WindowManager methods
}
]]></source>
@@ -204,7 +204,7 @@ WindowManager wm = (WindowManager) BeanH
will be thrown.
</p>
</subsection>
-
+
<subsection name="Extending the Basic Mechanism">
<p>
As was pointed out in the introduction of this chapter support for
creating
@@ -278,7 +278,7 @@ WindowManager wm = (WindowManager) BeanH
class already an instance exists. If this is the case, it is directly
returned. Otherwise we call the inherited <code>createBean()</code>
method
and store its result in the map. (Note that this implementation is a
bit
- simplicistic; a real world implementation would also have to take the
+ simplistic; a real world implementation would also have to take the
initialization parameters into account. But for the purpose of an
example
it should be good enough). Here is the code:
</p>
@@ -287,13 +287,13 @@ public class SingletonBeanFactory extend
{
/** A map for the so far created instances.*/
private Map beans;
-
+
public SingletonBeanFactory()
{
super();
beans = new HashMap();
}
-
+
// Creates the bean. Checks if already an instance exists.
public synchronized Object createBean(Class beanClass, BeanDeclaration
decl,
Object param) throws Exception
Modified:
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_combinedconfiguration.xml
URL:
http://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_combinedconfiguration.xml?rev=1837978&r1=1837977&r2=1837978&view=diff
==============================================================================
---
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_combinedconfiguration.xml
(original)
+++
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_combinedconfiguration.xml
Mon Aug 13 19:59:11 2018
@@ -35,7 +35,7 @@
</p>
<p>
<ul>
- <li>A <code>CombinedConfiguration</code> is a truely
+ <li>A <code>CombinedConfiguration</code> is a truly
<a href="howto_xml.html#Hierarchical properties">hierarchical
configuration</a>. This means that all the enhanced facilities
provided by <code>HierarchicalConfiguration</code> (e.g. expression
@@ -76,7 +76,7 @@
to re-construct the view.
</p>
</subsection>
-
+
<subsection name="Node combiners">
<p>
A <em>node combiner</em> is an object of a class that inherits from the
@@ -215,7 +215,7 @@
node is necessary only in situations where there is ambiguity. If in one
of our example configuration sources multiple tables had been defined,
the
node combiner would have concluded itself that <code>table</code> is a
list
- node and would have acted correspondigly.
+ node and would have acted correspondingly.
</p>
<p>
The examples the follow are provided to further illustrate the
differences
@@ -717,7 +717,7 @@ cc.addConfiguration(conf2);
configuration
</p>
</subsection>
-
+
<subsection name="Dealing with changes">
<p>
There is nothing that prevents you from updating a combined
configuration,
@@ -729,7 +729,7 @@ cc.addConfiguration(conf2);
<p>
Typical node combiners work by copying parts of the node structures of
the source configurations into the target structure and linking them
- togehter using special link nodes. So updates of the combined node
structure
+ together using special link nodes. So updates of the combined node
structure
will either effect nodes from one of the contained configuration (then
the changes are directly visible in this configuration) or one of the
link
nodes (then they cannot really be saved).
@@ -747,7 +747,7 @@ cc.addConfiguration(conf2);
<p>
Because of that it is recommended that changes are not done at the
combined configuration, but only at contained configurations. This way
- the correct configuration to be updated can unambigously be identified.
+ the correct configuration to be updated can unambiguously be identified.
Obtaining the configuration to be updated from the combined configuration
is easy when it was given a name.
</p>
Modified:
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_configurationbuilder.xml
URL:
http://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_configurationbuilder.xml?rev=1837978&r1=1837977&r2=1837978&view=diff
==============================================================================
---
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_configurationbuilder.xml
(original)
+++
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_configurationbuilder.xml
Mon Aug 13 19:59:11 2018
@@ -118,7 +118,7 @@ Configuration config = builder.getConfig
<p>
Using <code>DefaultConfigurationBuilder</code> to collect configuration
sources does not make much sense if there is only a single source to be
- loaded. So let's add another one! This time we will embedd a XML file:
+ loaded. So let's add another one! This time we will embed a XML file:
<em>gui.xml</em> which is shown in the next listing:
</p>
<source><![CDATA[
@@ -137,7 +137,7 @@ Configuration config = builder.getConfig
To make this XML document part of our global configuration we have to
modify our configuration definition file to also include the new file.
For
XML documents the element <code><xml></code> can be used so that we
- ave now:
+ have now:
</p>
<source><![CDATA[
<?xml version="1.0" encoding="ISO-8859-1" ?>
@@ -176,7 +176,7 @@ Configuration config = builder.getConfig
settings in another. Then in the configuration definition file the file
with the user settings is included first and after that the file with the
default values. The application code that queries these settings needs no
- be aware whether a property was overriden by the user.
<code>DefaultConfigurationBuilder</code>
+ be aware whether a property was overridden by the user.
<code>DefaultConfigurationBuilder</code>
takes care that properties defined in the first file (the user file) are
found; other properties which the user has not changed will still be
returned from the second file (the defaults file).
@@ -230,7 +230,7 @@ Configuration config = builder.getConfig
<p>
In an earlier section about the configuration definition file for
<code>DefaultConfigurationBuilder</code> it was stated that configuration
- files included first can override properties in configuraton files
+ files included first can override properties in configuration files
included later, and an example use case for this behaviour was given.
There
may be cases when there are other requirements.
</p>
@@ -333,11 +333,11 @@ Configuration config = builder.getConfig
this section are treated as if they were children of the root element,
i.e.
properties in the included configuration sources override properties in
sources included later. So the <code><override></code> tags could
have
- been ommitted, but for the sake of clearity it is recommended to use them
+ been omitted, but for the sake of clearity it is recommended to use them
if there is also an <code><additional></code> section.
</p>
<p>
- It is the <code><additonal></code> section that introduces a new
behaviour.
+ It is the <code><additional></code> section that introduces a new
behaviour.
All configuration sources listed here are combined to a union
configuration.
In our example we have put two <code>xml</code> elements in this area
that load the available files with database table definitions. The syntax
@@ -347,7 +347,7 @@ Configuration config = builder.getConfig
configuration where the included properties are to be added. Here it is
set
for the second element to the value <em>tables</em>. This is because the
file starts with a <code><table></code> element, but to be
compatible
- with the other table definition file it should be accessable under the
key
+ with the other table definition file it should be accessible under the
key
<code>tables.table</code>.
</p>
<p>
@@ -359,7 +359,7 @@ Configuration config = builder.getConfig
</p>
<p>
Note that it is also possible to override properties defined in an
- <code>additonal</code> section. This can be done by placing a
configuration
+ <code>additional</code> section. This can be done by placing a
configuration
source in the <code>override</code> section that defines properties that
are also defined in one of the sources listed in the
<code>additional</code>
section. The example does not make use of that. Note also that the order
of
@@ -685,7 +685,7 @@ Configuration config = builder.getConfig
document type definition or a schema defining exactly the structure of a
configuration definition file. Frankly, the answer is no. This is due to
the fact that the format is extensible. As will be shown below, it is
- possible to register yout own tags in order to embedd custom
configuration
+ possible to register yout own tags in order to embed custom configuration
sources.
</p>
</subsection>
@@ -803,7 +803,7 @@ Configuration tab1Config = ccAdd.getConf
Configuration tab2Config = ccAdd.getConfiguration("tab2");
]]></source>
</subsection>
-
+
<subsection name="Extending the configuration definition file format">
<p>
If you have written a custom configuration class, you might want to
Modified:
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_events.xml
URL:
http://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_events.xml?rev=1837978&r1=1837977&r2=1837978&view=diff
==============================================================================
---
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_events.xml
(original)
+++
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_events.xml
Mon Aug 13 19:59:11 2018
@@ -48,7 +48,7 @@
modified.</li>
<li>The event's type. This is a numeric value that corresponds to
constant declarations in concrete configuration classes. It describes
- what exactly has happended.</li>
+ what exactly has happened.</li>
<li>If available, the name of the property whose modification caused
the
event.</li>
<li>If available, the value of the property that caused this
event.</li>
@@ -195,7 +195,7 @@ public class ConfigurationLogListener
// remains unchanged, see above
...
}
-
+
<b>public void configurationError(ConfigurationErrorEvent event)
{
System.out.println("An internal error occurred!");
Modified:
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_filebased.xml
URL:
http://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_filebased.xml?rev=1837978&r1=1837977&r2=1837978&view=diff
==============================================================================
---
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_filebased.xml
(original)
+++
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_filebased.xml
Mon Aug 13 19:59:11 2018
@@ -63,7 +63,7 @@
</p>
<p>
While a <code>File</code> or a URL uniquely identify a file, the
- situation is a bit ambigous when only a base path and a file name
are
+ situation is a bit ambiguous when only a base path and a file name
are
set. These can be arbitrary strings (even full URLs) whose exact
meaning must be detected when the file is loaded. For this purpose
file-based configurations perform the following checks (in this
@@ -104,7 +104,7 @@
be aware of two things:
<ol>
<li>They do not change the configuration's file name. To do this
- you have to explicitely call one of the setter methods.</li>
+ you have to explicitly call one of the setter methods.</li>
<li>The <code>load()</code> methods do not empty the
configuration before new data is loaded. This makes it easy to
construct union configurations by simply calling
<code>load()</code>
@@ -154,7 +154,7 @@ config.save("usergui.backup.properties);
<subsection name="Automatic Saving">
<p>
If you want to ensure that every modification of a configuration
- object is immideately written to disk, you can enable the automatic
+ object is immediately written to disk, you can enable the automatic
saving mode. This is done through the <code>setAutoSave()</code>
method as shown in the following example:
</p>
Modified:
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_multitenant.xml
URL:
http://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_multitenant.xml?rev=1837978&r1=1837977&r2=1837978&view=diff
==============================================================================
---
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_multitenant.xml
(original)
+++
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_multitenant.xml
Mon Aug 13 19:59:11 2018
@@ -31,7 +31,7 @@
that each client have its own unique configuration. The simplest
approach to enable an application to be multi-tenant is for it
to not really be aware of it at all. This requires that the
- configuration framework take on some of the responsility for
+ configuration framework take on some of the responsibility for
making the application work correctly.
</p>
<p>
@@ -51,7 +51,7 @@
on each call to a method in the class. The configuration file will
then
be located using the resolved pattern and a new XMLConfiguration
will be created and cached for subsequent requests. The
ExpressionEngine,
- ReloadingStrategy and listeners will be propogated to each of the
+ ReloadingStrategy and listeners will be propagated to each of the
created configurations.
</p>
<p>
@@ -120,7 +120,7 @@
<subsection name="PatternSubtreeConfigurationWrapper">
<p>
Applications are often composed of many components each of which
need their
- own configuration. This can be accomodated by having a configuration
file
+ own configuration. This can be accommodated by having a
configuration file
per component, but this can make things hard to manage when there
are many
clients and many components. A second approach is to combine them
into
a single configuration file. However, this either means the
subcomponent
Modified:
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_properties.xml
URL:
http://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_properties.xml?rev=1837978&r1=1837977&r2=1837978&view=diff
==============================================================================
---
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_properties.xml
(original)
+++
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_properties.xml
Mon Aug 13 19:59:11 2018
@@ -29,7 +29,7 @@
<p>
Properties files are a popular mean of configuring applications. Of
course Commons Configuration
supports this format and enhances significantly the basic
<code>java.util.Properties</code> class.
- This section introduces the features of the
+ This section introduces the features of the
<code><a
href="../javadocs/v1.10/apidocs/org/apache/commons/configuration/PropertiesConfiguration.html">PropertiesConfiguration</a></code>
class.
Note that <code>PropertiesConfiguration</code> is a very typical
example
for an implementation of the <code>Configuration</code> interface and
@@ -243,7 +243,7 @@ config.dirs = \\\\\\\\share1,\\\\\\\\sha
way of defining a list: just use the same key multiple times. In this
case no additional escaping of backslashes (beyond the usual
duplicating
required by properties files) is needed because there is no list
- delimter character involved. Using this syntax the list of network
+ delimiter character involved. Using this syntax the list of network
shares looks like the following:
</p>
<source><![CDATA[
@@ -285,7 +285,7 @@ config.dirs = \\\\share2
<li><code>setBlancLinesBefore()</code><br/>
This methods allows defining the number of empty lines to be written
before the specified property. It can be used, for instance, to
- devide the properties file into multiple logical sections.</li>
+ divide the properties file into multiple logical sections.</li>
<li><code>setSingleLine()</code><br/>
If a property has multiple values, with <code>setSingleLine()</code> it
can be specified that all these values should be written into a single
@@ -383,7 +383,7 @@ public class WhitespacePropertiesReader
{
super(in, delimiter);
}
-
+
/**
* Special algorithm for parsing properties keys with whitespace. This
* method is called for each non-comment line read from the properties
Modified:
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_xml.xml
URL:
http://svn.apache.org/viewvc/commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_xml.xml?rev=1837978&r1=1837977&r2=1837978&view=diff
==============================================================================
---
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_xml.xml
(original)
+++
commons/proper/configuration/trunk/src/site/xdoc/userguide_v1.10/howto_xml.xml
Mon Aug 13 19:59:11 2018
@@ -84,10 +84,10 @@
]]></source>
<p>
(As becomes obvious, this tutorial does not
bother with good
- design of XML documents, the example file
should rather
+ design of XML documents, the example file
should rather
demonstrate the different ways of accessing
properties.)
To access the data stored in this document it
must be loaded
- by <code>XMLConfiguration</code>. Like other
+ by <code>XMLConfiguration</code>. Like other
<a href="howto_filebased.html">file based</a>
configuration classes <code>XMLConfiguration</code> supports
many ways of specifying the file to process. One way is to
@@ -405,7 +405,7 @@ List<Object> ... // further calls for ot
very handy when processing list-like structures:
</p>
<source><![CDATA[
-List<HierarchicalConfiguration> fields =
+List<HierarchicalConfiguration> fields =
config.configurationsAt("tables.table(0).fields.field");
for(HierarchicalConfiguration sub : fields)
{
@@ -518,7 +518,7 @@ config.addProperty("tables.table.fields.
<code>first</code> and <code>test</code>.)
</p>
<p>
- If we want a different behavior, we must
explicitely tell
+ If we want a different behavior, we must
explicitly tell
<code>addProperty()</code> what to do. In our
example with the
new field our intension was to create a new
branch for the
<code>field</code> part in the key, so that a
new <code>field</code>
@@ -612,7 +612,7 @@ int testVal = config.getInt("test..value
String complex = config.getString("test..complex.test..sub..element");
]]></source>
<p>
- Note the duplicated dots whereever the dot does not act as
+ Note the duplicated dots wherever the dot does not act as
delimiter. This way it is possible to access properties
containing
dots in arbitrary combination. However, as you can see, the
escaping can be confusing sometimes. So if you have a choice,
@@ -656,7 +656,7 @@ String complex = config.getString("test.
stick to this approach in the 1.x series though.
</p>
<p>
- In the next major release the handling of lists will propably
be
+ In the next major release the handling of lists will probably
be
reworked. Therefore it is recommended not to use this feature.
You are save if you disable it immediately after the creation
of
an <code>XMLConfiguration</code> object (and before a file is
@@ -721,7 +721,7 @@ config.load("config.xml");
a custom expression engine the syntax of all hierarchical
configuration
objects can be altered at once.
</p>
-
+
<subsection name="The default expression engine">
<p>
The syntax described so far for property keys of hierarchical
@@ -742,7 +742,7 @@ config.load("config.xml");
<code>DefaultExpressionEngine</code> class. But it can do a
little bit more for you: it defines a bunch of properties,
which can be used to customize most tokens that can appear in a
- valid property key. You prefer curly brackets over paranthesis
+ valid property key. You prefer curly brackets over parenthesis
as index markers? You find the duplicated dot as escaped
property delimiter counter-intuitive? Well, simply go ahead and
change it! The following example shows how the syntax of a
@@ -792,7 +792,7 @@ Object value = config.getProperty("table
// name can either be a child node of table or an attribute
]]></source>
</subsection>
-
+
<subsection name="The XPATH expression engine">
<p>
The expression language provided by the
<code>DefaultExpressionEngine</code>
@@ -1091,7 +1091,7 @@ config.load();
<p>
<a
href="http://xml.apache.org/commons/components/resolver/resolver-article.html#s.whats.wrong";>XML
Entity and URI Resolvers</a> describes using a set of catalog
files to
- resolve enitities. Commons Configuration provides support for
+ resolve entities. Commons Configuration provides support for
this Catalog Resolver through its own CatalogResolver class.
</p>
<source><