No announcement yet.
  • Filter
  • Time
Clear All
new posts

    12.0p Java exception on ListGrid.exportData() or wrong operation binding used

    Hi Isomorphic,

    I have a problem in my application (v12.0p_2020-03-11) when I explicitly name "fetch" as operationId to use in an exportData() call.
    Here this happens on the server side:

    16:54:53.564 [https-openssl-nio-443-exec-8] ERROR com.lmscompany.lms.server.LMSIDACall - com.lmscompany.lms.server.LMSIDACall top-level exception
    java.lang.ClassCastException: java.lang.String cannot be cast to java.util.Map
        at com.isomorphic.rpc.RPCManager.completeResponse( ~[isomorphic_core_rpc.jar:?]
        at com.isomorphic.rpc.RPCManager.send( ~[isomorphic_core_rpc.jar:?]
        at com.isomorphic.servlet.IDACall.processRPCTransaction( ~[isomorphic_core_rpc.jar:?]
        at com.lmscompany.lms.server.LMSIDACall.processRequest( [classes/:?]
        at com.isomorphic.servlet.IDACall._processRequest( [isomorphic_core_rpc.jar:?]
        at com.isomorphic.servlet.IDACall.doPost( [isomorphic_core_rpc.jar:?]
        at javax.servlet.http.HttpServlet.service( [servlet-api.jar:?]
        at com.isomorphic.servlet.BaseServlet.service( [isomorphic_core_rpc.jar:?]
        at javax.servlet.http.HttpServlet.service( [servlet-api.jar:?]
    Important note: I do not have an explicit operationBinding like this:
            <operationBinding operationType="fetch" operationId="fetch" />

    Something strange also happens in the showcase sample (v12.0p_2020-04-12), where with operationId: "fetch" in the normal request, the JSON-export operationBinding is used serverside (resulting in a downloaded file named "Results.json").
    This might be related, although I'm not sure:
        ID: "countryList",
        width:500, height:250, top:70, alternateRecordStyles:true,
        dataSource: worldDSExport,
        autoFetchData: true,
            {name:"countryName", title:"Country"},
            {name:"capital", title:"Capital"},
            {name:"continent", title:"Continent"},
            {name:"independence", title:"Nationhood", width:100},
            {name:"population", title:"Population"}
        showFilterEditor: true
        ID: "exportForm",
        fields: [
            { name: "exportType", title: "Export Type", type:"select", width:"*",
                defaultToFirstOption: true,
                valueMap: {
                    "csv" : "CSV" ,
                    "xml" : "XML",
                    "json" : "JSON",
                    "xls" : "XLS (Excel97)",
                    "ooxml" : "OOXML (Excel2007)"
            { name: "showInWindow", title: "Show in Window", type: "boolean", align:"left" }
       ID: "exportButton",
       title: "Export",
       left: 320,
       click: function () {
           var exportAs = exportForm.getField("exportType").getValue();
           var showInWindow = exportForm.getField("showInWindow").getValue();
           if (exportAs == "json") {
               // JSON exports are server-side only, so use the OperationBinding on the DataSource
               countryList.exportData({ operationId: "customJSONExport",
                   exportDisplay: showInWindow ? "window" : "download"});
           } else {
               // exportAs is not JSON, so we can set that with requestProperties
               countryList.exportData({ exportAs: exportAs, operationId: "fetch",
                   exportDisplay: showInWindow ? "window" : "download"
    Best regards

    Not sure if you're saying that there is a problem with exportData() when you have specified an operationId in your request properties and that operationId is not defined, or if this is only a problem when the operationId is "fetch" and it also is not defined? In passing, we would not recommend using an operationId of "fetch" because it is vague and likely to be misunderstood. That said, our in local testing, we do not see the results you are seeing: explicitly setting the operationId on an exportData() call to "fetch" when no such operation is defined, causes it to fall back to the default operation as you would expect, leaving this message in the log:

    === 2020-04-17 17:26:06,894 [ec-9] WARN  DataSourceDMI - [test35] DataSource exportCountryDS: received a request to execute an operation of type 'fetch' named 'fetch', but this operation is not defined on the dataSource.  Falling back to default behavior for operationType 'fetch'


      Hi Isomorphic,

      I think this exception was created by coincidence - I don't have an operationId="fetch" in my .ds.xml, but called it like that because of an error.

      But you do see the strange JSON export in the sample (v12.0p_2020-05-03) as well? All you need to do is to run it like in #1 and hit export.
      It should default to the default fetch (that is not in the .ds.xml of the sample), but instead it seems to use customJSONExport.
      It also seems that this is only happening for some exports (CSV, XLS) and not others (XML, OOXML)

      Also, for JSON my download (Chromium 81) is named "Results.json" instead of "Results.txt" as configured in the .ds.xml, but this might be Chromium doing something special for this mime type.

      Best regards


        How are you determining that it is running the customJSONExport operation? Testing the code you posted locally with a CSV export, we see the DataSourceDMI message referred to in our last post, but no indication that it is running customJSONExport instead.

        On the other hand, it does rename the requested export file to add a .json extension even though the actual content is CSV. We see why this is happening, and are looking into the best way to deal with it. Just to be clear, however, this is very much an edge case: it only happens if you specify an operationId, and there is no operationBinding with that operationId, and there is a different operation of the same operationType on the same DataSource.


          Hi Isomorphic,

          sorry, the downloaded file has indeed CSV content, but it's named "Results.json".

          Best regards