[jira] [Commented] (GEODE-6808) Backward compatibility broken in DistributedSystemMXBean.queryData

["Juan José Ramos Cassella (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GEODE-6808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16848824#comment-16848824 ] 

Juan José Ramos Cassella commented on GEODE-6808:
-------------------------------------------------

The lack of type within the {{JSON}} result only happens for to primitive types, we're already instructing the {{Jackson ObjectMapper}} to include the type during the serialisation:

{code:title=AbstractJSONFormatter.java|borderStyle=solid}
public AbstractJSONFormatter(int maxCollectionElements, int serializationDepth, boolean generateTypeInformation) {
...
    // This constructor parameter is always true.
    if (generateTypeInformation) {
      // add type information (Jackson has no way to force it to do this for all values)
      mapper.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL);
    }
...
}
{code}

The {{NON_FINAL}} documentation, however, states that it's not applied for primitive types:

{code:title=ObjectMapper.java|borderStyle=solid}
        /**
         * Value that means that default typing will be used for
         * all non-final types, with exception of small number of
         * "natural" types (String, Boolean, Integer, Double), which
         * can be correctly inferred from JSON; as well as for
         * all arrays of non-final types.
         *<p>
         * Since 2.4, this does NOT apply to {@link TreeNode} and its subtypes.
         */
        NON_FINAL
{code}


> Backward compatibility broken in DistributedSystemMXBean.queryData
> ------------------------------------------------------------------
>
>                 Key: GEODE-6808
>                 URL: https://issues.apache.org/jira/browse/GEODE-6808
>             Project: Geode
>          Issue Type: Bug
>          Components: jmx, pulse, querying
>            Reporter: Juan José Ramos Cassella
>            Priority: Major
>
> As part of thee efforts to remove {{TypedJson}} and move from {{org.json}} to {{Jackson}} between {{1.8.0}} and {{1.9.0}}, the {{JSON}} string returned by the {{QueryDataFunction}} doesn't include the object type anymore within the array (at least for primitive types). The old version used to return results in the form {{\{"result":[["java.lang.String","v"],["java.lang.String","b"]]}\}}, while the new one uses {{\{"result":["v", "b"]\}}}.
> This function is used through {{DistributedSystemMXBean.queryData}}, so any user executing queries through {{JMX}} and relying on the [documented representation|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/management/DistributedSystemMXBean.html#queryData-java.lang.String-java.lang.String-int-] to parse the results will fail as soon as they upgrade to {{1.9.0}}.
> Several parsing methods within {{DataBrowser.js}} *still use these deleted types* as well to create an internal representation that is later used to show the results in {{HTML}} so, starting with {{1.9.0}}, the query results are always shown as empty.
> {code:javascript}
> // This function creates complete result panel html
> function createHtmlForQueryResults(){
>   var memberResults = responseResult.result;
>   if(memberResults.length > 0){
>     if(memberResults[0].member != undefined || memberResults[0].member != null){
>       //console.log("member wise results found..");      
>       for(var i=0; i<memberResults.length; i++){
>         //console.log(memberResults[i].member);
>         $('#memberAccordion').append(createHtmlForMember(memberResults[i]));
>       }
>     }else{
>       //console.log("cluster level results found..");
>       var accordionContentHtml = "";
>       accordionContentHtml = createClusterAccordionContentHtml(memberResults);
>       var resultHtml = "<div class=\"accordion-content2\">"+ accordionContentHtml +"</div>";
>       $('#memberAccordion').append(resultHtml);
>     }
>   }else{
>     $('#memberAccordion').append("<span> No Results Found...</span>");
>   }
> }
> {code}
> We need to either re-factor the entire parsing logic to use the new format, or revert the changes to keep using the old format.
> Cheers.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)