[
https://issues.apache.org/jira/browse/CONFIGURATION-670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134623#comment-16134623
]
Magno Nascimento de Azevedo Cruz edited comment on CONFIGURATION-670 at 8/21/17
1:46 AM:
-----------------------------------------------------------------------------------------
I don't think I can provide one right now with something that you can test,
because I'm creating an implementation of {{HierarchicalConfiguration}} to
support a different data format. What I can provide you is a representation of
the current state of the model presented me that inconsistency.
{code}
root
attributes : null;
children :
[0] attributes : {nodeType = LIST}; // you can ignore this attribute,
it's only used internally.
[0] children :
[0] attributes : null;
[0] children : null;;
[0] nodeName : "Color";
[0] value : "red";
[1] attributes : null;
[1] children : null;;
[1] nodeName : "Color";
[1] value : "green";
[2] attributes : null;
[2] children : null;;
[2] nodeName : "Color";
[2] value : "blue";
[0] nodeName : "favoriteColors";
[0] value : null;
nodeName : null;
value : null;
{code}
When, where {{configurationAt("favoriteColors.Color(0)", true)}} should return:
{code}
root
attributes : null;
children :
[0] attributes : null;
[0] children : null;;
[0] nodeName : "Color";
[0] value : "red";
nodeName : null;
value : null;
{code}
It's returning a configuration representing the original one, i.e., with the
tracking node pointing to the root node of the whole hierarchy.
But {{configurationAt("favoriteColors.Color(0)", false)}} returns the wanted
node correctly (as root node of the new {{HierarchicalConfiguration}}).
I think it could be achieved by having a {{HierarchicalConfiguration}}
representing the following XML properties:
{code}
<favoriteColors>
<Color>"red"<Color>
<Color>"green"<Color>
<Color>"blue"<Color>
</favoriteColors>
{code}
I'm sorry I can't provide you more information of my implementation, I didn't
know what was the response time after opening a ticket here, so I just changed
my implementation to manually resolve the keys and update the tree instead of
using {{configurationAt(key, true)}} to do it, and it's working fine by now,
but it would be good if this problem was fixed.
was (Author: magnonac97):
I don't think I can provide one right now with something that you can test,
because I'm creating an implementation of {{HierarchicalConfiguration}} to
support a different data format. What I can provide you is a representation of
the current state of the model presented me that inconsistency.
{code}
root
attributes : null;
children :
[0] attributes : {nodeType = LIST};
[0] children :
[0] attributes : null;
[0] children : null;;
[0] nodeName : "Color";
[0] value : "red";
[1] attributes : null;
[1] children : null;;
[1] nodeName : "Color";
[1] value : "green";
[2] attributes : null;
[2] children : null;;
[2] nodeName : "Color";
[2] value : "blue";
[0] nodeName : "favoriteColors";
[0] value : null;
nodeName : null;
value : null;
{code}
When, where {{configurationAt("favoriteColors.Color(0)", true)}} should return:
{code}
root
attributes : null;
children :
[0] attributes : null;
[0] children : null;;
[0] nodeName : "Color";
[0] value : "red";
nodeName : null;
value : null;
{code}
It's returning a configuration representing the original one, i.e., with the
tracking node pointing to the root node of the whole hierarchy.
But {{configurationAt("favoriteColors.Color(0)", false)}} returns the wanted
node correctly (as root node of the new {{HierarchicalConfiguration}}).
I think it could be achieved by having a {{HierarchicalConfiguration}}
representing the following XML properties:
{code}
<favoriteColors>
<Color>"red"<Color>
<Color>"green"<Color>
<Color>"blue"<Color>
</favoriteColors>
{code}
I'm sorry I can't provide you more information of my implementation, I didn't
know what was the response time after opening a ticket here, so I just changed
my implementation to manually resolve the keys and update the tree instead of
using {{configurationAt(key, true)}} to do it, and it's working fine by now,
but it would be good if this problem was fixed.
> Inconsistency with configurationAt method.
> ------------------------------------------
>
> Key: CONFIGURATION-670
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-670
> Project: Commons Configuration
> Issue Type: Bug
> Components: Expression engine
> Affects Versions: 2.1.1
> Reporter: Magno Nascimento de Azevedo Cruz
>
> After some testing, I found some inconsistency with the use of
> {{configurationAt()}}, to simplify it, this version is working correctly,
> returning the {{HierarchicalConfiguration}} pointing to the right property:
> {code:java}
> config.configurationAt("property.indexedProperty(0)", false);
> {code}
> While this version, instead of returning a {{HierarchicalConfiguration}} with
> the root tracking node pointing to {{indexedProperty(0)}}, it returns the
> tracking node pointing to the root of the whole tree of properties.
> {code:java}
> config.configurationAt("property.indexedProperty(0)", true);
> {code}
> I'm trying to implement a support to a new format called
> [SURF|https://urf.io/surf/] created by GlobalMentor, but I didn't override
> this method, so I think it's coming from the original implementation.
> More informations may be found at
> [https://globalmentor.atlassian.net/browse/URF-34].
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
