[jboss-user] [Remoting] - Re: Exception propagation using servlet transport

[ron.sigal@jboss.com]

Hi guys,

"seanmmcc" wrote : 
  | So I think the round trip is working correctly.
  | 

Cool.  Like Lenny says on "Law and Order", "Sorry, we have to ask."  :)

"dpfelten" wrote : 
  | The code that gets invoked in ServletServerInvoker is the following:
  | 
  | 
  |   | try
  |   |          {
  |   |             // call transport on the subclass, get the result to handback
  |   |             invocationResponse = invoke(invocationRequest);
  |   |          }
  |   |          catch(Throwable ex)
  |   |          {
  |   |             log.debug("Error thrown calling invoke on server invoker.", ex);
  |   |             invocationResponse = null;
  |   |             response.sendError(500, "Error processing invocation request.  " + ex.getMessage());
  |   |          }	
  |   | 
  | 

Dave, are you sure about that?  You're showing the ServletServerInvoker method


  |    public void processRequest(HttpServletRequest request, HttpServletResponse response)
  |    throws ServletException, IOException
  | 

but, in fact, that method is never called in Remoting.  Instead, org.jboss.remoting.transport.servlet.web.ServerInvokerServlet.processRequest() calls the ServletServerInvoker method


  |    public byte[] processRequest(HttpServletRequest request, byte[] requestByte,
  |                                 HttpServletResponse response)
  |          throws ServletException, IOException
  | 

which has the code


  |          try
  |          {
  |             // call transport on the subclass, get the result to handback
  |             invocationResponse = invoke(invocationRequest);
  |          }
  |          catch(Throwable ex)
  |          {
  |             log.debug("Error thrown calling invoke on server invoker.", ex);
  |             invocationResponse = ex;
  |             
  |             if (checkForExceptionReturn(metadata))
  |             {
  |                String sessionId = invocationRequest.getSessionId();
  |                ServletThrowable st = new ServletThrowable(ex);
  |                invocationResponse = new InvocationResponse(sessionId, st, true, null);
  |             }
  |             else
  |             {
  |                isError = true;
  |             }
  |          }
  | 

Here, checkForExceptionReturn() looks for the presence of the "return-exception" parameter in the metadata map.  I had to reread the code for a while to figure out how that parameter gets into the metadata map, and it happens in the lines


  |       Map urlParams = request.getParameterMap();
  |       metadata.putAll(urlParams);
  | 

where ServletRequest.getParameterMap() gets parameters from the query string, at the end of the InvokerLocator.  If you look at the rest of ServletServerInvoker, you'll see that the InvocationResponse wrapping the ServletThrowable gets returned as a normal response.

On the other hand, if "return-exception" ISN'T set to true, you would get the variable "isError" set to true, which eventually results in


  |             if(isError)
  |             {
  |                response.sendError(500, "Error occurred processing invocation request. ");
  |             }
  | 

getting executed.  So, I think that's the first thing to look for.  In particular, check the client-bind-url entry in your jboss.xml file.

Now, on the client side, 

"dpfelten" wrote : 
  | On the client, we can see in HTTPClientInvoker.useHttpURLConnection, this condition happening:
  | 
  |   | if(result instanceof String)
  |   |                   {
  |   |                      // this is a html error page displayed by web server, need to conver to excepti
  |   | on
  |   |                      WebServerError ex = new WebServerError((String)result);
  |   |                      return ex;
  |   |                   }
  |   | 
  | 

is strange.  This code should be accessible only if "NoThrowOnError" is set to "true" in the invocation metadata map, which shouldn't be happening.  However, make sure that "NoThrowOnError" is removed.

Ok, I've been testing Remoting and it looks like, if things are properly configured, the exception throwing mechanism works the way it should.  So I think we're back to figuring out what's wrong with the configuration.

To be continued ...

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189648#4189648

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189648