[jira] [Commented] (CONFIGURATION-604) combining properties which use 3+ part names discards entries as of Commons 1.6+
[ https://issues.apache.org/jira/browse/CONFIGURATION-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14614033#comment-14614033 ] Oliver Heger commented on CONFIGURATION-604: This seems to be a pretty old change since version 1.6 was released years ago. To make sure I fully understand the problem, could you please specify exactly the expected result and the actual result? (Or even better: could you transform your demo code fragment to a unit test?) combining properties which use 3+ part names discards entries as of Commons 1.6+ Key: CONFIGURATION-604 URL: https://issues.apache.org/jira/browse/CONFIGURATION-604 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.6 Reporter: N Campbell When two property files are combined using commons config 1.5, the aggregate configuration returns an expected result of 6 entries. If Commons configuration 1.6 or higher is used, the resulting set drops to which is not expected. The property names include 2, 3 or 4 part names X.Y, X.Y.Z etc and it appears that as of 1.6 if the names are arranged in 2 part, then 3 part etc that the combiner returns the expected result. There does not appear to be any release notes etc that would suggest that this isn't a defect versus an intended implementation change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CONFIGURATION-604) combining properties which use 3+ part names discards entries as of Commons 1.6+
[ https://issues.apache.org/jira/browse/CONFIGURATION-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14614045#comment-14614045 ] N Campbell commented on CONFIGURATION-604: -- Expected answer is 6 as returned when using 1.5 x.y=true x.y.simpleCase=false x.y.between=false x.y.isDistinctFrom=false x.y.comparison=true x.y.in=true Switch to 1.6+ and you get 4 x.y.simpleCase=false x.y.between=false x.y.isDistinctFrom=false x.y=true Stay with 1.6 and re-order the 2-part entry in A.properties so it appears before 3 part names (x.y=true) and you get 6 again x.y=true x.y.simpleCase=false x.y.between=false x.y.isDistinctFrom=false x.y.comparison=true x.y.in=true combining properties which use 3+ part names discards entries as of Commons 1.6+ Key: CONFIGURATION-604 URL: https://issues.apache.org/jira/browse/CONFIGURATION-604 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.6 Reporter: N Campbell When two property files are combined using commons config 1.5, the aggregate configuration returns an expected result of 6 entries. If Commons configuration 1.6 or higher is used, the resulting set drops to which is not expected. The property names include 2, 3 or 4 part names X.Y, X.Y.Z etc and it appears that as of 1.6 if the names are arranged in 2 part, then 3 part etc that the combiner returns the expected result. There does not appear to be any release notes etc that would suggest that this isn't a defect versus an intended implementation change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CONFIGURATION-604) combining properties which use 3+ part names discards entries as of Commons 1.6+
[
https://issues.apache.org/jira/browse/CONFIGURATION-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14613397#comment-14613397
]
N Campbell commented on CONFIGURATION-604:
--
Simple source
import java.util.Iterator;
import org.apache.commons.configuration.CombinedConfiguration;
import org.apache.commons.configuration.ConfigurationException;
import org.apache.commons.configuration.PropertiesConfiguration;
import org.apache.commons.configuration.tree.NodeCombiner;
import org.apache.commons.configuration.tree.OverrideCombiner;
public class CommonsIssue {
public static String propFile1 = c:\\temp\\A.properties;
public static String propFile2 = c:\\temp\\B.properties;
public static void main( String[] args ) throws ConfigurationException {
testCombindedConfig();
}
public static void testCombindedConfig() throws ConfigurationException {
NodeCombiner combiner = new OverrideCombiner();
CombinedConfiguration combinedConfig = new
CombinedConfiguration(combiner);
PropertiesConfiguration conf1 = new PropertiesConfiguration();
conf1.setDelimiterParsingDisabled(true);
conf1.setThrowExceptionOnMissing(true);
conf1.load(propFile1);
combinedConfig.addConfiguration(conf1);
PropertiesConfiguration conf2 = new PropertiesConfiguration();
conf2.setDelimiterParsingDisabled(true);
conf2.setThrowExceptionOnMissing(true);
conf2.load(propFile2);
combinedConfig.addConfiguration(conf2);
@SuppressWarnings(unchecked)
IteratorString keys = combinedConfig.getKeys();
while (keys.hasNext()) {
String key = keys.next();
System.out.println(key + = +
combinedConfig.getString(key));
}
}
}
A.properties
x.y.simpleCase=false
x.y.between=false
x.y.isDistinctFrom=false
x.y=true
B.properties
x.y=true
x.y.between=true
x.y.comparison=true
x.y.in=true
x.y.isDistinctFrom=true
x.y.simpleCase=true
combining properties which use 3+ part names discards entries as of Commons
1.6+
Key: CONFIGURATION-604
URL: https://issues.apache.org/jira/browse/CONFIGURATION-604
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.6
Reporter: N Campbell
When two property files are combined using commons config 1.5, the aggregate
configuration returns an expected result of 6 entries. If Commons
configuration 1.6 or higher is used, the resulting set drops to which is not
expected.
The property names include 2, 3 or 4 part names X.Y, X.Y.Z etc and it appears
that as of 1.6 if the names are arranged in 2 part, then 3 part etc that the
combiner returns the expected result.
There does not appear to be any release notes etc that would suggest that
this isn't a defect versus an intended implementation change.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
