I think I'd find this handy also. In rh/3, I thought marc was going to change the interceptor config. method to be like other mbeans, which would let you change this setting while jboss was running (stop interceptor, change flag, restart). However this hasn't happend yet.
david jencks On 2002.01.09 11:56:06 -0500 Richard Kilgore wrote: > 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 > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
