The response could not be parsed.

Help
2008-01-18
2013-04-25
  • Ulrich Hilger
    Ulrich Hilger
    2008-01-18

    Hi everyone,
    when I invoke a method on a tomcat server via

    XmlRpcClient client = new XmlRpcClient( "http://mydomain/trec2/apps", false );
    result = (String) client.invoke("test.test", new Object[] {"this is a test"} );

    I get the error on the client side "The response could not be parsed.". When I check the server log it shows that the request has been correctly dispatched to method test of class test which is registered as an invocation handler. The log also shows that this method is producing a response but then it seems as if the server does not put the response back to the client correctly.

    I use Java 1.6 both on the client and the server. On the server runs Tomcat on Linux.

    Any hints on what is wrong are highly appreciated.

    Thanks
    Ulrich

     
    • Greger Ohlson
      Greger Ohlson
      2008-01-20

      Hi,

      Can you please attach the full stack trace on the client side? The XmlRpcException thrown contains a nested exception with the root cause of the problem, so it is important that you include not only the XmlRpcException from the stack trace.

      It's hard to speculate what's wrong at this point. It can be problems with the payload, the connection, or something else.

      Thanks,
      Greger

       
    • Ulrich Hilger
      Ulrich Hilger
      2008-01-20

      Hi Greger,

      thank you for your fast reply. This is what I do on the client side:

            Object result = null;
            XmlRpcClient client = new XmlRpcClient( "http://www.mydomain.com/xmlrpc", false );
            if(client != null) {
                result = client.invoke("test.test", new Object[] {"this is a test"} );
            }
          return result;

      on the server side the invocation handler is properly called and produces a log entry that shows that it returns a string saying 'input was this is a test' which is what is intended and expected.

      This is the full stack trace when no particular parser is set by my application (I call the test method above as first step during login of my application so don'T worry about why the stack trace shows method com.lightdev.app.trec.client.Client.login):

      20.01.08 11:43:35   application started   INFO from com.lightdev.app.trecmgr.Manager
      20.01.08 11:43:35   not logged in   INFO from com.lightdev.app.trecmgr.Manager
      [Fatal Error] :1:1: Premature end of file.
      redstone.xmlrpc.XmlRpcException: The response could not be parsed.
          at redstone.xmlrpc.XmlRpcClient.handleResponse(Unknown Source)
          at redstone.xmlrpc.XmlRpcClient.endCall(Unknown Source)
          at redstone.xmlrpc.XmlRpcClient.invoke(Unknown Source)
          at com.lightdev.lib.redstone.Communicator.rpcExec(Communicator.java:37)
          at com.lightdev.app.trec.client.Client.login(Client.java:157)
          at com.lightdev.app.trecmgr.Manager.login(Manager.java:243)
          at com.lightdev.app.trecmgr.ui.LoginDialog.onOkBtn(LoginDialog.java:126)
          at com.lightdev.app.trecmgr.ui.ManagerDialog.actionPerformed(ManagerDialog.java:106)
          at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
          at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
          at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
          at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
          at javax.swing.AbstractButton.doClick(AbstractButton.java:357)
          at javax.swing.plaf.basic.BasicRootPaneUI$Actions.actionPerformed(BasicRootPaneUI.java:191)
          at javax.swing.SwingUtilities.notifyAction(SwingUtilities.java:1636)
          at javax.swing.JComponent.processKeyBinding(JComponent.java:2844)
          at javax.swing.KeyboardManager.fireBinding(KeyboardManager.java:267)
          at javax.swing.KeyboardManager.fireKeyboardAction(KeyboardManager.java:216)
          at javax.swing.JComponent.processKeyBindingsForAllComponents(JComponent.java:2921)
          at javax.swing.JComponent.processKeyBindings(JComponent.java:2913)
          at javax.swing.JComponent.processKeyEvent(JComponent.java:2807)
          at java.awt.Component.processEvent(Component.java:5815)
          at java.awt.Container.processEvent(Container.java:2058)
          at java.awt.Component.dispatchEventImpl(Component.java:4410)
          at java.awt.Container.dispatchEventImpl(Container.java:2116)
          at java.awt.Component.dispatchEvent(Component.java:4240)
          at java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1848)
          at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(DefaultKeyboardFocusManager.java:693)
          at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(DefaultKeyboardFocusManager.java:958)
          at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:830)
          at java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:657)
          at java.awt.Component.dispatchEventImpl(Component.java:4282)
          at java.awt.Container.dispatchEventImpl(Container.java:2116)
          at java.awt.Window.dispatchEventImpl(Window.java:2429)
          at java.awt.Component.dispatchEvent(Component.java:4240)
          at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
          at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
          at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
          at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
          at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
          at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
          at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)
      Caused by: redstone.xmlrpc.XmlRpcException: A problem occured during parsing
          at redstone.xmlrpc.XmlRpcParser.parse(Unknown Source)
          ... 42 more
      Caused by: org.xml.sax.SAXParseException: Premature end of file.
          at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1231)
          ... 43 more
      20.01.08 11:43:42   The response could not be parsed.   INFO from com.lightdev.app.trecmgr.Manager
      20.01.08 11:43:45   application terminated   INFO from com.lightdev.app.trecmgr.Manager

      And this is the full stack trace when I explicitly set the SAX parser to Apache Crimson, i.e. System.setProperty("org.xml.sax.driver","org.apache.crimson.parser.XMLReaderImpl");:

      20.01.08 11:37:34   application started   INFO from com.lightdev.app.trecmgr.Manager
      20.01.08 11:37:34   not logged in   INFO from com.lightdev.app.trecmgr.Manager
      redstone.xmlrpc.XmlRpcException: The response could not be parsed.
          at redstone.xmlrpc.XmlRpcClient.handleResponse(Unknown Source)
          at redstone.xmlrpc.XmlRpcClient.endCall(Unknown Source)
          at redstone.xmlrpc.XmlRpcClient.invoke(Unknown Source)
          at com.lightdev.lib.redstone.Communicator.rpcExec(Communicator.java:37)
          at com.lightdev.app.trec.client.Client.login(Client.java:157)
          at com.lightdev.app.trecmgr.Manager.login(Manager.java:243)
          at com.lightdev.app.trecmgr.ui.LoginDialog.onOkBtn(LoginDialog.java:126)
          at com.lightdev.app.trecmgr.ui.ManagerDialog.actionPerformed(ManagerDialog.java:106)
          at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
          at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
          at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
          at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
          at javax.swing.AbstractButton.doClick(AbstractButton.java:357)
          at javax.swing.plaf.basic.BasicRootPaneUI$Actions.actionPerformed(BasicRootPaneUI.java:191)
          at javax.swing.SwingUtilities.notifyAction(SwingUtilities.java:1636)
          at javax.swing.JComponent.processKeyBinding(JComponent.java:2844)
          at javax.swing.KeyboardManager.fireBinding(KeyboardManager.java:267)
          at javax.swing.KeyboardManager.fireKeyboardAction(KeyboardManager.java:216)
          at javax.swing.JComponent.processKeyBindingsForAllComponents(JComponent.java:2921)
          at javax.swing.JComponent.processKeyBindings(JComponent.java:2913)
          at javax.swing.JComponent.processKeyEvent(JComponent.java:2807)
          at java.awt.Component.processEvent(Component.java:5815)
          at java.awt.Container.processEvent(Container.java:2058)
          at java.awt.Component.dispatchEventImpl(Component.java:4410)
          at java.awt.Container.dispatchEventImpl(Container.java:2116)
          at java.awt.Component.dispatchEvent(Component.java:4240)
          at java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1848)
          at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(DefaultKeyboardFocusManager.java:693)
          at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(DefaultKeyboardFocusManager.java:958)
          at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:830)
          at java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:657)
          at java.awt.Component.dispatchEventImpl(Component.java:4282)
          at java.awt.Container.dispatchEventImpl(Container.java:2116)
          at java.awt.Window.dispatchEventImpl(Window.java:2429)
          at java.awt.Component.dispatchEvent(Component.java:4240)
          at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
          at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
          at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
          at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
          at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
          at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
          at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)
      Caused by: redstone.xmlrpc.XmlRpcException: A problem occured during parsing
          at redstone.xmlrpc.XmlRpcParser.parse(Unknown Source)
          ... 42 more
      Caused by: org.xml.sax.SAXParseException: Document root element is missing.
          at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3182)
          at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3170)
          at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:501)
          at org.apache.crimson.parser.Parser2.parse(Parser2.java:305)
          at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:442)
          ... 43 more
      20.01.08 11:37:43   The response could not be parsed.   INFO from com.lightdev.app.trecmgr.Manager
      20.01.08 11:37:46   application terminated   INFO from com.lightdev.app.trecmgr.Manager

      Thanks again, hope this helps...
      Ulrich

       
      • Greger Ohlson
        Greger Ohlson
        2008-01-20

        Hi,

        Thanks, the stack trace was enlightening;

        The two SAX parsers you used in your tests report

        Caused by: org.xml.sax.SAXParseException: Premature end of file.
          and
        Caused by: org.xml.sax.SAXParseException: Document root element is missing.
          respectively.

        So there appears to be something wrong with the XML payload in the HTTP response.

        Do you receive any output in the servlet log on the Tomcat (which version) side? Can you
        check that please? Although the invocation handler is onvoked properly, this means only
        that the contents of the HTTP POST was properly deserialized and dispatched on the server
        side. After that it is time to generate and serialize and HTTP response with the result
        value. I suspect something is going wrong here with the XmlRpcServlet and Tomcat.

        BTW, are you using the Redstone library on the server side as well?

        Thnks,
        Greger

         
        • Ulrich Hilger
          Ulrich Hilger
          2008-01-20

          Hi Greger,

          I use Tomcat 5.5.23 on Linux 2.6.9-023stab044.11-smp and Java 1.6.0_02-b05.

          When I call a handler that does not exist, Tomcat logs the following:

          Jan 20, 2008 11:55:22 AM redstone.xmlrpc.XmlRpcDispatcher writeError
          WARNING: The specified handler cannot be found

          *AND* in my server application's log it shows

          1/20/08 11:55:22 AM   Server.doPost response is <?xml version="1.0" encoding="UTF-8"?><methodResponse><fault><value><struct><member><name>faultCode</name><value><int>-1</int></value></member><member><name>faultString</name><value><string>The specified handler cannot be found</string></value></member></struct></value></fault></methodResponse>   FINEST from com.lightdev.app.trec.server.Server

          But when I call my existing invocation handler (class Test) the Tomcat log shows nothing and my own server applications log shows

          1/20/08 12:22:37 PM      execute method test.testpassing to handle unchanged for login/logout   INFO from com.lightdev.app.trec.server.Server
          1/20/08 12:22:37 PM      test returns with 'input was this is a test'   FINEST from com.lightdev.app.trec.server.Server
          1/20/08 12:22:37 PM   Server.doPost response is    FINEST from com.lightdev.app.trec.server.Server

          Although the test class returns a string the XmlRpcServlet seems to return an emtpy response. While it can be seen in the fault example above the XmlRpcServlet *does* return a valid (fault) response but in the test case it does not return a response. Do I have to do something more than just to return a String in my test method so that Redstone can return it properly?...

          Does that help any further?..

          Thank you
          Ulrich

           
          • Greger Ohlson
            Greger Ohlson
            2008-01-20

            Hi Ulrich,

            Hmmm... I had a look in the XmlRpcServer and XmlRpcDispatcher code to see under which circumstances this bug might appear (assuming it is in the XML-RPC library) and I've found a potential candidate;

            Inside the XmlRpcDispatcher, which is responsible for dispatching inbound requests to invocation handlers, there is a check against handlers returning null values (null can't be serialized in XML-RPC).

              // If the return value wasn't intercepted by any of the interceptors,
              // write the response using the current serlialization mechanism.
                                   
              if ( returnValue != null )
              {
                  writeValue( returnValue );
              }

            Now, if this is what's happening there are two scenarios;

            1) Although you have a printout somewhere stating that 1/20/08 12:22:37 PM      test returns with 'input was this is a test'   FINEST
            from com.lightdev.app.trec.server.Server, the handler still returns null. (i.e. a bug in the handlers which says it is returning the string
            but in fact isn't)

            2) You have an XmlRpcInvocationInterceptor registered with the server which swallows the return value (it's after() method returns null rather than forwarding out the return value that came from the interceptor).

            Do you have an XmlRpcInvocationInterceptor registered? If not, can you please send me the contents of the test() method in the Trec server?

            Thanks,
            Greger.

             
            • Ulrich Hilger
              Ulrich Hilger
              2008-01-20

              Greger,

              you are a genius! My bad, I was not aware that the InvocationInterceptor requires me to pass on the return value in the after() method. When I implemented interface InvocationInterceptor Eclipse automatically generated 'return null;' inside method after() and I simply did not replace it with 'return returnValue;'.

              It now works. You did a great job in analysing this incident. Thank you very much for your time and help in this. You were very responsive and helpful.

              Thanks again and all the best.
              Ulrich

              PS: You asked about the details: I am in the course of evaluating to implement the Redstone XML-RPC library with my TREC platform ( http://www.lightdev.com/page/104.htm ) . I currently use Apache XML-RPC but it looks as if Redstone has significant advantages such as streaming, interceptor logic and overall straightforward implementation as well as small footprint and robustness. 

              With TREC I use interceptor logic to inspect all method calls for proper session ids, method calls are passed on when they include a valid session id, and the session id is removed before the method call is passed on so that the backend method signatures do not need to know about the authentication that is happening before they are being called.

               
              • Greger Ohlson
                Greger Ohlson
                2008-01-20

                Hi Ulrich,

                Glad it works! I will consider changing the behavior of the dispatcher when interceptors return null. We have an obscure use case a while back where an interceptor wanted to completely take charge over the output writer for the response and bypass the normal response behavior, in which case returning null would achieve that. Returning null from an interceptor requires, however, that it writes something on the writer supplied to it. To quote the JavaDoc:

                     *  <p>If the interceptor returns null it means that the call was intercepted
                     *  completely and that the interceptor itself is responsible of generating
                     *  a response to the caller through the java.io.Writer in the XmlRpcInvocation.
                     *  This makes it possible to write interceptors that override the whole
                     *  serialization mechanism to return customized content for invocations.</p>

                Returning null is very rare and perhaps it would be better to disallow it altogether and generate an XmlRpcFault if interceptors or incovation handlers return null. We'll think about it.

                Good luck with your project.

                Regards,
                Greger.