Tom DeBruycker wrote:
Hi,
I appoligize for the format of this posting. I was not subscribed when I
sent the original so I pasted the previous message into this one.
I have attaced a set of XML files which help describe the possible issue I
found.
Here is the configuration file which loads three XML files.
=============<snip>================
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<header>
<result>
<expressionEngine config-class="
org.apache.commons.configuration.tree.xpath.XPathExpressionEngine"/>
</result>
</header>
<xml config-name="ServerConfig3" fileName="TableSet3.xml">
<reloadingStrategy config-class="
org.apache.commons.configuration.reloading.FileChangedReloadingStrategy"
refreshDelay="2000"/>
</xml>
<xml config-name="ServerConfig1" fileName="TableSet1.xml">
<reloadingStrategy config-class="
org.apache.commons.configuration.reloading.FileChangedReloadingStrategy"
refreshDelay="2000"/>
</xml>
<xml config-name="ServerConfig2" fileName="TableSet2.xml">
<reloadingStrategy config-class="
org.apache.commons.configuration.reloading.FileChangedReloadingStrategy"
refreshDelay="2000"/>
</xml>
</configuration>
The problem is probably that configurations that are not defined in a
special section are treated as "override" configurations, i.e. the first
configuration you declare wins. Try to put the configuration
declarations inside an <additional> section (see [1]).
You might also find the section about node combiners [2] in the user's
guide helpful.
HTH
Oliver
[1]
http://jakarta.apache.org/commons/configuration/howto_configurationbuilder.html#Enhancements_of_the_configuration_definition_file
[2]
http://jakarta.apache.org/commons/configuration/howto_combinedconfiguration.html#Node_combiners
File #1
<?xml version="1.0" encoding="UTF-8"?>
<ServerConfig1>
<datagroup>
<table name="table1" permission="group-A">
Data from file 1, table 1
</table>
<table name="table2" permission="group-B">
Data from file 1, table 2
</table>
<table name="table3" permission="group-C">
Data from file 1, table 3
</table>
</datagroup>
<userperm>
<allowed rank="manager" />
</userperm>
</ServerConfig1>
File #2
<?xml version="1.0" encoding="UTF-8"?>
<ServerConfig2>
<datagroup>
<table name="table4" permission="group-D">
Data from file 2, table 4
</table>
<table name="table5" permission="group-E">
Data from file 2, table 5
</table>
<table name="table6" permission="group-F">
Data from file 2, table 6
</table>
</datagroup>
<userperm>
<allowed rank="manager" />
</userperm>
</ServerConfig2>
File #3
<?xml version="1.0" encoding="UTF-8"?>
<ServerConfig3>
<datagroup>
<table name="table7" permission="group-G">
Data from file 3, table 7
</table>
<table name="table8" permission="group-H">
Data from file 3, table 8
</table>
<table name="table9" permission="group-I">
Data from file 3, table 9
</table>
</datagroup>
<userperm>
<allowed rank="manager" />
</userperm>
</ServerConfig3>
=============<snip>================
Each XML file has a unique filename and a unique root node. The nodes
within each XML file are the same but the data is different. I use
a CombinedConfiguration to load the XML files. Because the root node is
not
retained as a key the only the first XML file is accessabel in the
CombinedConfiguration. Is this a bug or is it that a CombinedConfiguration
cannot be used for XML files which are too similar?
Thanks,
Tom DeBruycker
Tom DeBruycker wrote:
Hi,
I have a question about what seems to be the design choice to ignore the
root node of XML files when creating the keys for a configuration. It
seems
that the root node is part of what contributes to the uniqueness of the
XML
file. If the root is ignored isn't it possible that nodes could be
inadvertently combined? This could just be my lack of understanding for
the
XMLConfiguration design.
If someone would explain the design choice I would appreciate it.
Thanks in advance.
Tom
Can you give an example for what you mean by "inadvertently combined"?
I guess the original idea was just convenience: Because the root element
of a XML configuration typically is not changed during property access,
there does not seem to be much value in requiring it to be part of the
keys.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
