[jira] [Comment Edited] (CONFIGURATION-670) Inconsistency with configurationAt method.

["Magno Nascimento de Azevedo Cruz (JIRA)" <ji...@apache.org>]

    [ 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:40 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};
        [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, 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)