Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 63111 invoked from network); 29 Apr 2002 18:03:36 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 29 Apr 2002 18:03:36 -0000 Received: (qmail 27152 invoked by uid 97); 29 Apr 2002 18:02:58 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 27109 invoked by uid 97); 29 Apr 2002 18:02:57 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 27017 invoked from network); 29 Apr 2002 18:02:56 -0000 Message-ID: <3CCD8A96.1050200@tanukisoftware.com> Date: Tue, 30 Apr 2002 03:01:58 +0900 From: Leif Mortenson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, ja MIME-Version: 1.0 To: Avalon Developers List Subject: Re: Alrrmi: ExceptionReply - lack of a stack trace. References: <3CCC26B4.4000702@tanukisoftware.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Peter Royal wrote: >On Sunday 28 April 2002 12:43 pm, Leif Mortenson wrote: > > >>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 >> >> > >I believe this is a general problem when serializing exceptions, the >stacktrace is transient. > > > >>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? >> >> > >Actually JDK 1.4 fixes this for RMI, which means it should be possible for >altrmi. > >My current solution is to do a manual version of what you describe on the >server side, but making in automagic in altrmi would be excellent. > > > >>Any other ideas on how to make this work more cleanly? >> >> > >Another technique that I've seen is to capture the stack trace to a string on >the server and then serialize the string. There was some code I found to do >that (it actually broke the stacktrace up into classes) but I can't find it >atm via google. > I was thinking about this some more. I have a suggested solution, but it is a bit "hacky".. :-/ Server side: 1) serialize the Throwable to a byte array. 2) capture the output of printStackTrace() including line feeds into another byte array. 3) replace the original message of the Throwable with the entire stack trace including message. 4) send the modified serialized Throwable off to the client. Client side: 1) Deserialize the patched Throwable into a new Throwable instance. 2) call fillInStackTrace on the Throwable. Now, when you call printStackTrace, you will see the stack trace on the server followed by the stacktrace on the client. This would give all the information needed. Problem is that when you call getMessage on the client, you will get a message which includes the server-side stack trace. Question is this worth it to make the stack trace useful? Thoughts? Leif -- To unsubscribe, e-mail: For additional commands, e-mail: