1. #1
    Sencha Premium Member
    Join Date
    Oct 2011
    Location
    Duluth, MN
    Posts
    126
    Answers
    2
    Vote Rating
    4
    badgerb1 is on a distinguished road

      0  

    Default Unanswered: Ext Direct exception issue

    Unanswered: Ext Direct exception issue


    I'm working with Ext Direct and I think I've found a bug. When an exception is sent back from the server, the callback handler sends event.getResult() as the "response" parameter to the process response function. Then the processResponse function calls setException(operation, response). Since the event.result is null, and that is what is getting put into the response parameter, setException get's null for the response. Then in setException, it tries to do a getMessage() from the response passed in and throws a null reference error and fails completely.

    I attempted to return an object that has a message field in it as the result, but that doesn't work either since the system is trying to call the getMessage() function on the returned result.

    To trace this through, the error occurs at line 40153 in the touch-all-debug.js
    Code:
    setException: function(operation, response) {
            operation.setException(response.getMessage());
        },


    which is called from line 32358
    Code:
    
               me.setException(operation, response);


    response is set from line 40142 where the response parameter comes from event.getResult()
    Code:
    createRequestCallback: function(request, operation, callback, scope) {
            var me = this;
    
    
            return function(data, event) {
                me.processResponse(event.getStatus(), operation, request, event.getResult(), callback, scope);
            };
        },
    and event is the individual Ext Direct responses from line 50646
    Code:
    for (ln = events.length; i < ln; ++i) {
                    event = events[i];
                    transaction = me.getTransaction(event);
                    me.fireEvent('data', me, event);
                    if (transaction) {
                        me.runCallback(transaction, event, true);
                        Ext.direct.Manager.removeTransaction(transaction);
                    }
                }
    Not sure at this point how to fix this as the trace runs pretty deep. Easy to test though just have the Ext.Direct server return an exception type response. I don't think there's any way to return a json result that will work as an exception.

    Example response json that causes error
    [{"action":"MobileServices","message":"id to load is required for loading; nested exception is java.lang.IllegalArgumentException: id to load is required for loading","method":"createDevice","result":{"message":"id to load is required for loading; nested exception is java.lang.IllegalArgumentException: id to load is required for loading"},"tid":2,"type":"exception"},{"action":"MobileServices","message":"id to load is required for loading; nested exception is java.lang.IllegalArgumentException: id to load is required for loading","method":"createDevice","result":{"message":"id to load is required for loading; nested exception is java.lang.IllegalArgumentException: id to load is required for loading"},"tid":3,"type":"exception"}]

    Sorry for being so long winded it's kind of complex and I'm hoping I described it well enough.

    Thanks
    Bob




  2. #2
    Sencha User
    Join Date
    Mar 2012
    Location
    Eindhoven, Netherlands
    Posts
    32
    Vote Rating
    2
    jeroenwalter is on a distinguished road

      0  

    Default


    I too have encountered this bug.
    It seems to me that the entire ext.direct library has some serious issues with returned exceptions and with invalid JSON responses (e.g. a php error).

    I'm still trying to come up with a workable solution, but I think that the Sencha Team should perform some serious tests of ext.direct.

  3. #3
    Sencha User mallowtek's Avatar
    Join Date
    Jul 2012
    Location
    paris
    Posts
    2
    Vote Rating
    0
    mallowtek is on a distinguished road

      0  

    Default same issue

    same issue


    I've got the same badgerb1 issue. Same causes, same consequences ?

    Anybody found a tweek excluding catching events instead of exception as I want to keep same ext.direct code for both extjs and sencha touch client.

    Ex direct is simple but not well documented. Perhaps Sencha could open a doc section for it, with sample for exception handling.
    french webdev expert - startx.fr

  4. #4
    Sencha Premium Member
    Join Date
    Oct 2012
    Location
    Brisbane, QLD, Australia
    Posts
    45
    Vote Rating
    3
    ampro is on a distinguished road

      0  

    Exclamation


    I now have a Siesta unit test that is reproducing this exception bug. I've had a dig through the code and come up with a fix for Sencha Touch/ExtJS. It's not pretty but I don't see any other way.

    The docs ...

    Ext-direct-RemotingProvider.actions states that the callback from a direct RPC include an event argument (e) from which you can get the exception message via event.getMessage() and the success/failure status via event.getStatus(). This is only place that I can find that documents the schema of the event
    object when an exception occurs.

    Touch 2.1.1 (A slightly different but equivalent code sample is documented in ExtJS 4.1.3)
    Code:
    TestAction.multiply(
        2, 4, // pass two arguments to server, so specify len=2
        // callback function after the server is called
        //     result: the result returned by the server
        //     e: Ext.direct.RemotingEvent object
        function(result, e) {
            var t = e.getTransaction();
            var action = t.action; // server side Class called
            var method = t.method; // server side method called
            if (e.getStatus()) {
                var answer = Ext.encode(result); // 8
            } else {
                var msg = e.getMessage(); // failure message
            }
        }
    );
    The bug ...

    Code:
    Ext.define('Ext.data.proxy.Direct', {
        extend: 'Ext.data.proxy.Server',
        alternateClassName: 'Ext.data.DirectProxy',
        alias: 'proxy.direct',
        requires: ['Ext.direct.Manager'],
        ....
        createRequestCallback: function(request, operation, callback, scope) {
            var me = this;
            return function(data, event) {
                me.processResponse(
                  event.getStatus(), operation, request, event.getResult() /* => response */, callback, scope);
            };
        },
    
        // @inheritdoc
        setException: function(operation, response) {
              ///  BUG: message => event.getResult().getMessage()  - but  should be event.getMessage()
            operation.setException(response.getMessage()); 
        },
        ....
    }
    The fix ...

    In Direct.createRequestCallback() we need replace ...
    Code:
        me.processResponse(event.getStatus(), operation, request, event.getResult(), callback, scope);
    with ...
    Code:
       me.processResponse(event.getStatus(), operation, request, event, callback, scope);
    ... so we can later perform response.getMessage() and obtain event.getMessage().

    This would also make it look much like the other calls to processResponse() ...

    Code:
    data\proxy\Ajax.js(329):
     me.processResponse(success, operation, request, response, callback, scope);
    data\proxy\JsonP.js(229): 
    me.processResponse(success, operation, request, response, callback, scope);
    Looking at the existing code below for Server.processResponse() ...

    We need to ensure that the behavior for other proxies is unchanged but that this call ...
    Code:
    resultSet = reader.process(response);
    becomes ...
    Code:
    resultSet = reader.process(response.getResult());
    ... but only for the Direct proxy.

    So I propose that it become ...
    Code:
        resultSet = reader.process(me.getResponseResult(response));
    Where Server.getResponseResult(response) is a noop that just returns response and is inherited by other proxies while Direct.getResponseResult(reponse) returns response.getResult()

    The only other behavioral issue is the calls to ...
    Code:
    me.fireEvent('exception', this, response, operation);
    .. but I suspect that they were sending the wrong response value as well and that this change will fix them too.

    Finally there also a call to
    Code:
        this.fireEvent('exception', this, response, operation);
    that I suspect should be
    Code:
        me.fireEvent('exception', this, response, operation);
    The Direct proxy also needs a missing a unit test case that would have picked this up.

    Code:
    data\proxy\Server.js(222): 
        processResponse: function(success, operation, request, response, callback, scope) {
            var me = this,
                action = operation.getAction(),
                reader, resultSet;
    
    
            if (success === true) {
                reader = me.getReader();
    
    
                try {
                    resultSet = reader.process(response);  
                } catch(e) {
                    operation.setException(e.message);
    
    
                    me.fireEvent('exception', this, response, operation);
                    return;
                }
    
    
                // This could happen if the model was configured using metaData
                if (!operation.getModel()) {
                    operation.setModel(this.getModel());
                }
    
    
                if (operation.process(action, resultSet, request, response) === false) {
                    this.fireEvent('exception', this, response, operation);
                }
            } else {
                me.setException(operation, response);
                /**
                 * @event exception
                 * Fires when the server returns an exception
                 * @param {Ext.data.proxy.Proxy} this
                 * @param {Object} response The response from the AJAX request
                 * @param {Ext.data.Operation} operation The operation that triggered request
                 */
                me.fireEvent('exception', this, response, operation);
            }
    
    
            //this callback is the one that was passed to the 'read' or 'write' function above
            if (typeof callback == 'function') {
                callback.call(scope || me, operation);
            }
    
    
            me.afterRequest(request, success);
        },

  5. #5
    Sencha User
    Join Date
    Mar 2007
    Location
    Haarlem, Netherlands
    Posts
    1,243
    Answers
    28
    Vote Rating
    10
    TommyMaintz will become famous soon enough TommyMaintz will become famous soon enough

      0  

    Default


    Thank you ampro for the extensive debugging and testing you have done on this. I have incorporated your proposed fixes into the codebase for Touch 2.2.1.

    Best,
    Tommy

Turkiyenin en sevilen filmlerinin yer aldigi xnxx internet sitemiz olan ve porn sex tarzi bir site olan mobil porno izle sitemiz gercekten dillere destan bir durumda herkesin sevdigi bir site olarak tarihe gececege benziyor. Sitenin en belirgin ozelliklerinden birisi de Turkiyede gercekten kaliteli ve muntazam, duzenli porno izle siteleri olmamasidir. Bu yuzden iste. Ayrica en net goruntu kalitesine sahip adresinde yayinlanmaktadir. Mesela diğer sitelerimizden bahsedecek olursak, en iyi hd porno video arşivine sahip bir siteyiz. "The Best anal porn videos and slut anus, big asses movies set..." hd porno faketaxi