You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Oliver Heger (JIRA)" <ji...@apache.org> on 2011/04/06 20:52:05 UTC
[jira] [Commented] (CONFIGURATION-442) SubsetConfiguration does not
properly list attributes when a delimiter is set
[ https://issues.apache.org/jira/browse/CONFIGURATION-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016484#comment-13016484 ]
Oliver Heger commented on CONFIGURATION-442:
--------------------------------------------
Is there a special reason why you instantiate the {{SubsetConfiguration}} directly rather than calling the {{subset()}} method of the configuration?
{{HirachicalConfiguration}} overrides {{subset()}} to construct a specialized hierarchical subset configuration. This configuration should return a correct iterator for its keys.
You are probably right that {{SubsetConfiguration}} does not play well with a hierarchical configuration, but this is the reason why {{HierarchicalConfiguration}} provides an alternative implementation of the {{subset()}} method. So the intended usage scenario is to call {{subset()}} on the target configuration rather than creating the {{SubsetConfiguration}} manually.
Would this solve your problem?
> SubsetConfiguration does not properly list attributes when a delimiter is set
> -----------------------------------------------------------------------------
>
> Key: CONFIGURATION-442
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-442
> Project: Commons Configuration
> Issue Type: Bug
> Affects Versions: 1.6
> Environment: all
> Reporter: Fabien Nisol
>
> imagine a XmlConfiguration like this:
> {code}
> <properties>
> <prop1>
> <prop2>
> <prop
> attr1="attr1"
> attr2="attr2"/>
> </prop2>
> </prop1>
> </properties>
> {code}
> If subset get instanciated to the end of the hierarchy, with a specific delimiter, getKeys() won't return the correct keys:
> {code}
> ...
> XMLConfiguration config = new XMLConfiguration("test/test.xml");
> Configuration subset = new SubsetConfiguration(config,"prop1.prop2.prop",".");
> ConfigurationUtils.dump(subset, System.err);
> ...
> {code}
> gives the result:
> {code}
> @attr1]=null
> @attr2]=null
> {code}
> it should give the result
> {code}
> [@attr1]=attr1
> [@attr2]=attr2
> {code}
> The wrong dump is a side effect of the wrong implementation of the _getChildKey_ method of SubsetConfiguration
> {code}
> /**
> * Return the key in the subset configuration associated to the specified
> * key in the parent configuration.
> *
> * @param key The key in the parent configuration.
> * @return the key in the context of this subset configuration
> */
> protected String getChildKey(String key)
> {
> if (!key.startsWith(prefix))
> {
> throw new IllegalArgumentException("The parent key '" + key + "' is not in the subset.");
> }
> else
> {
> String modifiedKey = null;
> if (key.length() == prefix.length())
> {
> modifiedKey = "";
> }
> else
> {
> int i = prefix.length() + (delimiter != null ? delimiter.length() : 0);
> modifiedKey = key.substring(i);
> }
> return modifiedKey;
> }
> }
> {code}
> In this code, the _else_ part is wrong. In a hierarchical configuration, the attribute delimiter is '[' and is removed here.
> I think a more correct code would be :
> {code}
> /**
> * Return the key in the subset configuration associated to the specified
> * key in the parent configuration.
> *
> * @param key The key in the parent configuration.
> * @return the key in the context of this subset configuration
> */
> protected String getChildKey(String key)
> {
> if (!key.startsWith(prefix))
> {
> throw new IllegalArgumentException("The parent key '" + key + "' is not in the subset.");
> }
> else
> {
> String modifiedKey = null;
> if (key.length() == prefix.length())
> {
> modifiedKey = "";
> }
> else
> {
> modifiedKey = key.substring(prefix.length());
> if(delimiter!=null && modifiedKey.startsWith(delimiter))
> {
> modifiedKey=modifiedKey.substring(delimiter.length());
> }
> }
> return modifiedKey;
> }
> }
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira