I spent much of today tracking down a NullPointerException being thrown
on the server,
but detected on the client.
After much investigation, the problem turned out to be a simple mistake
in my server-side code.
The reason that it was so difficult to track down was that in the
process of sending the NPE back
to the client via an ExceptionReply, the stack trace is lost. This
means that when printStackTrace()
is called on the reconstructed exception, you were simply getting the
following:
java.lang.NullPointerException
Not very helpful. I modified the ExceptionReply class to call
fillInStackTrace after the exception
is reconstructed. This makes it at least possible to see that the
exception was remote.
printStackTrace() now shows the following:
java.lang.NullPointerException
at
org.apache.excalibur.altrmi.common.ExceptionReply.readExternal(ExceptionReply.java:117)
at
java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1218)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:392)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:242)
at
org.apache.excalibur.altrmi.common.SerializationHelper.getInstanceFromBytes(SerializationHelper.java:94)
at
org.apache.excalibur.altrmi.client.impl.stream.ClientCustomStreamReadWriter.readReply(ClientCustomStreamReadWriter.java:98)
at
org.apache.excalibur.altrmi.client.impl.stream.ClientCustomStreamReadWriter.postRequest(ClientCustomStreamReadWriter.java:61)
at
org.apache.excalibur.altrmi.client.impl.stream.StreamInvocationHandler.handleInvocation(StreamInvocationHandler.java:131)
at
org.apache.excalibur.altrmi.client.impl.DefaultProxyHelper.processObjectRequestGettingFacade(DefaultProxyHelper.java:143)
at
AltrmiGeneratedInstrumentManagerClient_org$apache$avalon$excalibur$instrument$manager$interfaces$InstrumentDescriptor.createInstrumentSample(AltrmiGeneratedInstrumentManagerClient_org$apache$avalon$excalibur$instrument$manager$interfaces$InstrumentDes
at
org.apache.avalon.excalibur.instrument.client.InstrumentClientFrame$6.run(InstrumentClientFrame.java:438)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:160)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:399)
at
java.awt.EventDispatchThread.pumpOneEvent(EventDispatchThread.java:109)
at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:99)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
Much more useful, but this still does not tell me where in the server
code the exception was happening.
As there is no way to encode the original stack trace, would it be
possible to add some code on either
end to display these stack traces in the debug channel of a logger?
Any other ideas on how to make this work more cleanly?
Cheers,
Leif
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>