Now I remember ... We haven�t got a problem with this since all our application exceptions are derived from a top-level BusinessServiceException that prints a string-snapshot from the backtrace. That snapshot is taken if either printed or serialised ... The respective code comes even from me. Silly Christoph. In the meantime, I�m so used to that feature that I took it for granted ...
Furthermore, we log any such exception not catched by the application such that you can find the traces in a file, if needed (not many customers that are happy with a stacktrace popup, I can tell you ;-) LogInterceptor can do such a thing for you, I think. CGJ -----Urspr�ngliche Nachricht----- Von: Richard Kilgore [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 9. Januar 2002 17:56 An: Jung , Dr. Christoph Cc: 'Jboss-Development ([EMAIL PROTECTED])' Betreff: Re: [JBoss-dev] Re: preserve exception backtrace for client On Wed, Jan 09, 2002 at 01:29:30PM +0100, Jung , Dr. Christoph wrote: > Hi Richard ... > > AFAIK, if you serialise an exception, the stacktrace is serialised, > too. So I do not understand your point ... > > CGJ No, this is a pretty well-known obstacle in debugging RMI apps. The backtrace member of Throwable is transient, so what you get back on the client side doesn't tell you anything about where the error occurred. I suppose that in most cases, diagnosing the error on the server side is the solution, but there are two cases where this does not work out: 1. the error is some unexpected exception, possibly a run-time NullPointerException or the like. 2. knowledge of the fact that a given exception represents a true error condition requires knowledge that only the client possesses, so the server app does not print a stack trace (this happens). In either case you have to add extra error checking to the server-side app (often stuff that you're going to want to either remove after you're done, or switch off), re-compile, re-deploy, etc. (or use a server-side debugger -- which I don't have setup and I'd think would be a pain). But if you could just toggle a flag in jboss.conf or jboss.jcml somewhere to have stack traces preserved, then in most cases, you probably won't have to do anything extra except restart jboss and run your test again to diagnose it. - rick > -----Urspr?ngliche Nachricht----- > Von: Richard Kilgore [mailto:[EMAIL PROTECTED]] > Gesendet: Mittwoch, 9. Januar 2002 05:47 > An: JBoss Development > Betreff: [JBoss-dev] Re: preserve exception backtrace for client > > > Does anyone have any input on this? I can't seem to get any responses > on this mailing list. Is what I have proposed ill-conceived, or out > of turn or something? > > I need to do it for my own purposes, but thought it might be useful to > others as well, since it seems like a pretty general need, so I > figured I'd post it. Is there something wrong with the idea, or is it > just that no one has an opinion about it? > > Somebody make me feel like I'm not talking to a wall, please! > > - rick > > On Mon, Jan 07, 2002 at 09:34:27PM -0800, [EMAIL PROTECTED] > wrote: > > Feature Requests item #500727, was opened at 2002-01-07 21:34 You > > can > > respond by visiting: > > http://sourceforge.net/tracker/?func=detail&atid=376688&aid=500727&gro > > up_id=22866 > > > > Category: JBossServer > > Group: v2.4.x > > Status: Open > > Priority: 5 > > Submitted By: Richard Kilgore (richard-kilgore) > > Assigned to: Nobody/Anonymous (nobody) > > Summary: preserve exception backtrace for client > > > > Initial Comment: > > I would like to add the functionality to wrap an > > exception (well, a Throwable I guess) thrown by > > a user application on the server, and save the > > exception's stack trace to a string before it is > > marshaled and sent back to the client. > > > > The server-side part of this could be an Interceptor > > that can be loaded or not. The client side is tricky, though. I > > could of course just throw a wrapper class derived from > > RemoteException and the printStackTrace() method could be overridden > > to print a composite message that includes the original stack trace. > > > > But if I want to provide normal J2EE behavior, I > > think I want to throw the same type of exception > > that was thrown on the server, right? If that is the > > case, I might be able to use introspection to set the private > > backtrace object to an appropriate object. But this will require a > > little bit of code to be added to the RMI proxy object, which is > > less clean than the modular, easily (de)selectable Interceptor used > > on the server. > > > > Does anyone have any suggestions? > > > > > > Also, I need to have my changes work with version > > 2.4.3, because my clients at work are stuck on a > > 2.2 JVM (WebSphere 3.5). But should any patches I > > create for use by the community be against 2.4.4 or > > 3.0? > > > > - rick -- Richard Kilgore [EMAIL PROTECTED] _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
