Remoting framework eating exceptions?

[dhicks]

Hi folks,

I had this situation come up yesterday and now I've been tasked with finding a solution. We had a case where the underlying database was not active, but our client application did not display a warning to the user - it just returned with no indication, but without successfully logging them in.

I've spent the morning digging into the problem and found that the exception is being eaten by HttpInvokerServiceExporter. Well, "eaten" may not be the right word. The error is caught there and written out to whatever console or log is available, but not passed along. So there is no indication to the outside world that a problem exists other than the log file. Or is there? It's entirely possible that I'm just missing a detail that would give me what I'm looking for.

If anyone knows of a solution to this problem, please let me know.
Thanks,
David

[Juergen Hoeller]

Where exactly does HttpInvokerServiceExporter catch and log an exception, without rethrowing it to the client (or transferring it to the client in the form of a RemoteInvocationResult object)? Please give some details on the issue that you encountered!

Juergen

[dhicks]

Sorry. I neglected to post the details. I don't have that information immediately available, but I believe it's in the handleRequest() method of HttpInvokerServiceExporter. Here is the method...

public ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response)
throws IOException, ClassNotFoundException {

RemoteInvocation invocation = readRemoteInvocation(request);
RemoteInvocationResult result = invokeAndCreateResult(invocation, this.proxy);
writeRemoteInvocationResult(request, response, result);
return null;
}

You can see that the RemoteInvocationResult object returned by invokeAndCreateResult() is used to write the result, but then is not returned. I could see in my debugging that the exception was wrapped up in that result. Apparently, it was written to the console, then simply tossed out.

I hope this is helpful. If you need additional information, I'll try to recreate the stack trace and post it.

Thanks,
Dave

[Juergen Hoeller]

Well, "writeRemoteInvocationResult" serializes the RemoteInvocationResult object (that contains the exception in your case) to the HTTP response stream. That should be fine - there is no need to do anything else with the result.

HttpInvokerServiceExporter always returns null simply to indicate that it doesn't want to render a view but rather chose to handle the response itself (according to the contract of the Controller interface).

Juergen

[dhicks]

I see. And, I guess since it is a RuntimeException that's probably why my client isn't seeing it on the other side.

Thanks!

[Juergen Hoeller]

Any exception should get transferred and recreated at the client side - including RuntimeExceptions and Errors. So you should nevertheless get the exception thrown at the client side.

I guess what's really happening can only be clarified with the debugger... See what the exporter does for the affected invocation, and what exactly happens in the client-side proxy.

Juergen

[dhicks]

Yes, this is exactly the case. Once I understood that the exception was indeed being streamed back, it was a simple matter to catch it on the client side.

Thanks for the help.