HttpInvoker and exception stack traces

[vmarcinko]

Hi.

I exposed my service layer on server side with HttpInvoker and client can really call this layer using it's interface without knowing it is remote.

Everything works fine except I noticed that when exception is thrown on server side (service), it is propagated to remote client as it should, but with one minor difference - exception stack trace shows me method call hierarchy which led to exception on the server side, and I cannot see anywhere client side info in it, as it would be normal if remoting is not present.
How can I find out things like - which class executed this remote call? I can properly see what caused the exception inside service layer, but not where it has been called on client side.
Is it suposed to be this way ?

-Vjeran

[gpoirier]

The thing is, if you want to guarantee having the same exception class, without knowledge of the actual class at compile time, you have to use serialization to re-create it, which means it will have the server's stacktrace. However, using AOP, you could add an advice to log all the exceptions thrown by the remote proxy (or probably just exceptions that extend RuntimeException/Error).

[aaime]

Hum... I think logging the client stack should be the default behaviour, I mean, it's difficult to debug a client application if you don't know how you managed to call the remote service...

[aaime]

Oh, I've looked into adding exception logging, and it seems not complicated, yet it's not very convenient.

Adding logging to a bean like TransactionProxyFactoryBean is easy, just add a preInterceptor, whilst doing the same with HttpInvokerProxyFactoryBean is not as convenient, since there is no way to setup pre/post interceptors.
This means that I'll have to wrap it into a ProxyFactoryBean that will apply the logging advices, right?

[oliverhutchison]

Wrong.

It's actualy very simple just create a subclass of HttpInvokerProxyFactoryBean that overrides recreateRemoteInvocationResult(RemoteInvocationRes ult result) along these lines:

	protected Object recreateRemoteInvocationResult(RemoteInvocationResult result) throws Throwable {
		try {
			return super.recreateRemoteInvocationResult(result);
		} 
		catch(Throwable t) {
			logThatRemoteMethodThrewException(t);
			throw t;
		}
	}

HTH

Ollie

[aaime]

Oliver, thank you, this helps :-). I'll use your solution.

Yet, it's quite evident that this solution requires some knowledge of the inner workings of the remoting package. The problem seems common enough to deserve a more explicit and documented solution, in my opinion.
Should I fill a request for enhancement on the bug tracker?

[aaime]

I've tried it, but unfortunately it didn't work as I expected, but that's my fault.
I forgot that I'm spinning off all remote invocation using Spin, so logging the stack trace in HttpInvokerProxyFactoryBean does not help, only provides a stack trace in the thread that Spin creates to manage the remote invocation while feeding events for the user interface.

I've discovered I can add an interceptor to Spin, and with this one I can get out the real client side stack trace, the one that tells me which event handler/action triggered the remote invocation.

By the way, Spin seems a good candidate for inclusion in the AOP framework... maybe the rich client project already uses it as such, I don't know.