Issue 4013: Usage of ExceptionDetailMessage service context (java-rtf) Source: (Mr. Simon C. Nash, ) Nature: Uncategorized Issue Severity: Summary: The interop RTF resolved issue 3405 by adding a new service context called ExceptionDetailMessage. The usage of this service context was left to language mappings to define. We need to define this usage for Java. Writing the service context: There are a few possibilities that come to mind: 1) The result of calling getMessage() on the exception. 2) The result of calling toString() on the exception. 3) The result of calling printStackTrace(PrintWriter) on the exception. I'm inclined to think that option 3 is best, since the callee's stack trace is often very valuable debugging information. Reading the service context: The wstring from the service context should become the Java error message in the unmarshalled exception object. Resolution: issue has been resolved, see ptc/01-10-20 Revised Text: Actions taken: November 1, 2000: received issue April 18, 2002: closed issue Discussion: End of Annotations:===== Date: Wed, 01 Nov 2000 23:17:49 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: issues@omg.org CC: java-rtf@omg.org Subject: Usage of ExceptionDetailMessage service context Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: )P2e9eXWd9VCKe9a0M!! The interop RTF resolved issue 3405 by adding a new service context called ExceptionDetailMessage. The usage of this service context was left to language mappings to define. We need to define this usage for Java. Writing the service context: There are a few possibilities that come to mind: 1) The result of calling getMessage() on the exception. 2) The result of calling toString() on the exception. 3) The result of calling printStackTrace(PrintWriter) on the exception. I'm inclined to think that option 3 is best, since the callee's stack trace is often very valuable debugging information. Reading the service context: The wstring from the service context should become the Java error message in the unmarshalled exception object. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Thu, 02 Nov 2000 14:02:46 +0000 From: Eoghan Glynn X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Simon Nash CC: issues@omg.org, java-rtf@omg.org Subject: Re: Usage of ExceptionDetailMessage service context References: <3A00A49D.1B4E7550@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Y]2!!Lp[d90H&e9-Mo!! Hi Simon, If memory serves, the original intent of the interop issue was just to allow the SystemException reason string (which effectively becomes the java.lang.RuntimeException detail message) be encoded on the wire in an exceptional reply. However given that the language mapping was left open, I would agree that providing the exception stack trace (option #3) in addition would be a useful diagnostic aid. The only concern I'd have is that a exception raised on a cascaded invocation would become a bit overloaded with mutliple stack traces - i.e. A calls B calls C calls D which raises exception E => once E is delivered to A, E.printStaceTrace() will include 4 stack traces. I'm also a little unclear on how the ExceptionDetailMessage service context would work with user exceptions (assuming your intention is to use this mechanism for user exceptions as well as system exceptions, given that the service context may be passed with USER_EXCEPTION and SYSTEM_EXCEPTION replies). In the case of streams-based stubs, an org.omg.CORBA.portable.ApplicationException encapsulating the exception type ID and an input stream containing the exception data would be thrown back to the stub, which instaniates the appropriate user exception type via the helper class - i.e. there's no mechanism to pass up the detail message. In the case of the DII-based stubs, a similar argument applies to the org.omg.CORBA.UnknownUserException. Am I missing something here, or would we need to modify these wrapper classes or the user exception helper classes or the stubs to accomodate this? On the server side there also seems to be an issue with streams-based skeletons which simply catch a user exception, encoding it onto the output stream returned by org.omg.CORBA.portable.ResponseHandler.createExceptionReply() without any reference to the detail message - in fact I'd expect in many ORB implementations the reply service context list would already be encoded on the stream returned from createExceptionReply(), so there would not be an opportunity to add an ExceptionDetailMessage at this stage. Should we limit usage of this service context to SystemExceptions? Regards, Eoghan Glynn. Orbix2000/Java Engineering Team. Simon Nash wrote: > > The interop RTF resolved issue 3405 by adding a new service context called > ExceptionDetailMessage. The usage of this service context was > left to language mappings to define. We need to define this usage for Java. > > Writing the service context: > > There are a few possibilities that come to mind: > 1) The result of calling getMessage() on the exception. > 2) The result of calling toString() on the exception. > 3) The result of calling printStackTrace(PrintWriter) on the exception. > > I'm inclined to think that option 3 is best, since the callee's stack trace > is often very valuable debugging information. > > Reading the service context: > > The wstring from the service context should become the Java error message > in the unmarshalled exception object. > > Simon > -- > Simon C Nash, Technology Architect, IBM Java Technology Centre > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Sun, 05 Nov 2000 18:19:34 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Eoghan Glynn CC: java-rtf@omg.org Subject: Re: Usage of ExceptionDetailMessage service context References: <3A00A49D.1B4E7550@hursley.ibm.com> <3A017406.215FC385@iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: &d>!!^<[d96$M!!S~@e9 Eoghan, Eoghan Glynn wrote: > > Hi Simon, > > If memory serves, the original intent of the interop issue was just to > allow the SystemException reason string (which effectively becomes the > java.lang.RuntimeException detail message) be encoded on the wire in an > exceptional reply. However given that the language mapping was left > open, I would agree that providing the exception stack trace (option #3) > in addition would be a useful diagnostic aid. The only concern I'd have > is that a exception raised on a cascaded invocation would become a bit > overloaded with mutliple stack traces - i.e. A calls B calls C calls D > which raises exception E => once E is delivered to A, > E.printStaceTrace() will include 4 stack traces. > I agree that we should try to avoid this, since only the original stack trace is likely to contain useful debugging information. I think the ORB that creates the ExceptionDetailMessage service context should detect that the detail message already contains a stack trace and avoid appending a second one. This could be done by having the ORB add some marker (e.g., a leading ">") to the wstring in the ExceptionDetailMessage service context. The ORB would only put the stack trace into the service context if this marker isn't already present in the exception's detail message. > I'm also a little unclear on how the ExceptionDetailMessage service > context would work with user exceptions (assuming your intention is > to > use this mechanism for user exceptions as well as system exceptions, > given that the service context may be passed with USER_EXCEPTION and > SYSTEM_EXCEPTION replies). In the case of streams-based stubs, an > org.omg.CORBA.portable.ApplicationException encapsulating the > exception > type ID and an input stream containing the exception data would be > thrown back to the stub, which instaniates the appropriate user > exception type via the helper class - i.e. there's no mechanism to > pass > up the detail message. In the case of the DII-based stubs, a similar > argument applies to the org.omg.CORBA.UnknownUserException. Am I > missing > something here, or would we need to modify these wrapper classes or > the > user exception helper classes or the stubs to accomodate this? > You are right that this is a problem. However, there is a partial > solution. The detail message can be passed back to stream-based stubs by > creating a subclass of ApplicationException that takes a detailMessage on its > constructor and overrides getMessage() to return this detailMessage. This would > allow stream-based stubs to call getMessage() on the ApplicationException > and use the returned string (if any) to set the detailMessage in the user exception that they throw back to the application. Existing stubs > would just ignore the new detailMessage, and new ones would only pick it up > if the ORB had set it. It isn't even necessary to standardize the name > of the new subclass of ApplicationException that does this, since the stubs > only have to call the Throwable.getMessage() method on the > ApplicationException. However, it might be more straightforward to make this a standard > class. Unfortunately, this doesn't work for DII stubs since UnknownUserException is for no obvious reason declared final. So DII stubs will never pass this message back. I'd be willing to make this a limitation of using DII stubs. > On the server side there also seems to be an issue with streams-based > skeletons which simply catch a user exception, encoding it onto the > output stream returned by > org.omg.CORBA.portable.ResponseHandler.createExceptionReply() without > any reference to the detail message - in fact I'd expect in many ORB > implementations the reply service context list would already be encoded > on the stream returned from createExceptionReply(), so there would not > be an opportunity to add an ExceptionDetailMessage at this stage. > This is somewhat harder to deal with. Ideally there would be an overloaded getExceptionReply(userException) method which would create the necessary service context. This could be defined in a new interface ResponseHandler2 (actual name TBD) which extends ResponseHandler, since ResponseHandler is "locked in" to the JDK core. Skeletons that support passing back a detailMessage would check if the passed-in ResponseHandler is an instanceof ResponseHandler2. If so, they would call ResponseHandler2.getExceptionReply(userException) and if not, they would call ResponseHandler.getExceptionReply(). ORBs that support this mechanism would pass the skeleton's invoke() method an object that implements the new ResponseHandler2 interface. > Should we limit usage of this service context to SystemExceptions? > It is simpler to do this, but I think the approach I have suggested >above is workable, upwards compatible, and not too difficult to implement. >What do you think? Simon > Regards, > Eoghan Glynn. > > Orbix2000/Java Engineering Team. > > Simon Nash wrote: > > > > The interop RTF resolved issue 3405 by adding a new service > context called > > ExceptionDetailMessage. The usage of this service context was > > left to language mappings to define. We need to define this usage > for Java. > > > > Writing the service context: > > > > There are a few possibilities that come to mind: > > 1) The result of calling getMessage() on the exception. > > 2) The result of calling toString() on the exception. > > 3) The result of calling printStackTrace(PrintWriter) on the > exception. > > > > I'm inclined to think that option 3 is best, since the callee's > stack trace > > is often very valuable debugging information. > > > > Reading the service context: > > > > The wstring from the service context should become the Java error > message > > in the unmarshalled exception object. > > > > Simon > > -- > > Simon C Nash, Technology Architect, IBM Java Technology Centre > > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Mon, 06 Nov 2000 10:47:32 -0800 From: "Vijaykumar Natarajan" X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Simon Nash CC: Eoghan Glynn , java-rtf@omg.org Subject: Re: Usage of ExceptionDetailMessage service context References: <3A00A49D.1B4E7550@hursley.ibm.com> <3A017406.215FC385@iona.com> <3A05A4B6.D85035C3@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: WO!"!,$_!!&a>e9~+]d9 Hi all, Simon Nash wrote: > Eoghan, > > Eoghan Glynn wrote: > > > > Hi Simon, > > > > If memory serves, the original intent of the interop issue was >just to > > allow the SystemException reason string (which effectively becomes >the > > java.lang.RuntimeException detail message) be encoded on the wire >in an > > exceptional reply. However given that the language mapping was >left > > open, I would agree that providing the exception stack trace >(option #3) > > in addition would be a useful diagnostic aid. The only concern I'd >have > > is that a exception raised on a cascaded invocation would become a >bit > > overloaded with mutliple stack traces - i.e. A calls B calls C >calls D > > which raises exception E => once E is delivered to A, > > E.printStaceTrace() will include 4 stack traces. > > > I agree that we should try to avoid this, since only the original >stack trace > is likely to contain useful debugging information. I think the ORB >that creates > the ExceptionDetailMessage service context should detect that the >detail message > already contains a stack trace and avoid appending a second one. >This could be > done by having the ORB add some marker (e.g., a leading ">") to the >wstring in > the ExceptionDetailMessage service context. The ORB would only put >the stack > trace into the service context if this marker isn't already present >in the > exception's detail message. I totally disagree. Since this is a feature that enables the debugging information to be avaiable on the client side and there is really nothing useful that can be done with the error message except printing it out, it makes most sense to provide all the stack traces appended because that accurately represents the picture of what actually happened. Yes it would be a little heavy but not having it retracts from the value added by the stack trace. > > I'm also a little unclear on how the ExceptionDetailMessage service > > context would work with user exceptions (assuming your intention is to > > use this mechanism for user exceptions as well as system exceptions, > > given that the service context may be passed with USER_EXCEPTION and > > SYSTEM_EXCEPTION replies). In the case of streams-based stubs, an > > org.omg.CORBA.portable.ApplicationException encapsulating the exception > > type ID and an input stream containing the exception data would be > > thrown back to the stub, which instaniates the appropriate user > > exception type via the helper class - i.e. there's no mechanism to pass > > up the detail message. In the case of the DII-based stubs, a similar > > argument applies to the org.omg.CORBA.UnknownUserException. Am I missing > > something here, or would we need to modify these wrapper classes or the > > user exception helper classes or the stubs to accomodate this? > > > You are right that this is a problem. However, there is a partial solution. > The detail message can be passed back to stream-based stubs by creating a > subclass of ApplicationException that takes a detailMessage on its constructor > and overrides getMessage() to return this detailMessage. This would allow > stream-based stubs to call getMessage() on the ApplicationException and > use the returned string (if any) to set the detailMessage in the user > exception that they throw back to the application. Existing stubs would > just ignore the new detailMessage, and new ones would only pick it up if > the ORB had set it. It isn't even necessary to standardize the name of the > new subclass of ApplicationException that does this, since the stubs only > have to call the Throwable.getMessage() method on the ApplicationException. > However, it might be more straightforward to make this a standard class. > > Unfortunately, this doesn't work for DII stubs since UnknownUserException is > for no obvious reason declared final. So DII stubs will never pass this > message back. I'd be willing to make this a limitation of using DII stubs. I am not too keen on overloading the use of this in the case of standard System/User exceptions as they have well defined semantics defined either by the spec or by the user application respectively. The case of Unknown is special as it is the only means of communicating a very wide variety of exceptions on the server side, with no user control possible on the server side. As for the message travelling up, to the user, the use of it for ServerErrors and ServerExceptions is easily achieved by setting the message on the ServerError and ServerException exceptions themselves. However, the case for RuntimeException is harder because the stubs throw the original exception unmarshaled from the stream and there is no opportunity to replace the string message in that exception. Passing the message back in UnknownUserException for DII is still fine, because the java RTF just passed the resolution to provide a constructor w/ a String message. > > > > > On the server side there also seems to be an issue with >streams-based > > skeletons which simply catch a user exception, encoding it onto >the > > output stream returned by > > org.omg.CORBA.portable.ResponseHandler.createExceptionReply() >without > > any reference to the detail message - in fact I'd expect in many >ORB > > implementations the reply service context list would already be >encoded > > on the stream returned from createExceptionReply(), so there would >not > > be an opportunity to add an ExceptionDetailMessage at this stage. > > > This is somewhat harder to deal with. Ideally there would be an >overloaded > getExceptionReply(userException) method which would create the >necessary > service context. This could be defined in a new interface >ResponseHandler2 > (actual name TBD) which extends ResponseHandler, since >ResponseHandler is > "locked in" to the JDK core. > > Skeletons that support passing back a detailMessage would check if >the > passed-in ResponseHandler is an instanceof ResponseHandler2. If so, >they > would call ResponseHandler2.getExceptionReply(userException) and if >not, > they would call ResponseHandler.getExceptionReply(). > > ORBs that support this mechanism would pass the skeleton's invoke() >method > an object that implements the new ResponseHandler2 interface. > > > Should we limit usage of this service context to SystemExceptions? > > > It is simpler to do this, but I think the approach I have suggested >above is > workable, upwards compatible, and not too difficult to implement. >What do > you think? My feeling is to restrict this to only CORBA::UNKNOWN or at most to SystemExceptions. Thanks, Vijay Date: Mon, 06 Nov 2000 19:20:02 +0000 From: Eoghan Glynn X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Simon Nash CC: java-rtf@omg.org Subject: Re: Usage of ExceptionDetailMessage service context References: <3A00A49D.1B4E7550@hursley.ibm.com> <3A017406.215FC385@iona.com> <3A05A4B6.D85035C3@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ~_ld94/$!!Lahd9!Rnd9 Hi Simon, Extending the org.omg.CORBA.portable classes in the fashion you suggest is workable, but strikes me as over-kill, as the user exceptions may always be defined to carry any context/diagnostic information that the app requires. Its the case of system exceptions (or worse, Java exceptions wrapped in UNKNOWN) where the developer/administrator really needs help in determining what's going on. So I'd be of a mind to restrict the usage of the service context to system exceptions only. Regards, Eoghan Glynn. Orbix2000/Java Engineering Team. Simon Nash wrote: > > Eoghan, > > Eoghan Glynn wrote: > > > > Hi Simon, > > > > If memory serves, the original intent of the interop issue was just to > > allow the SystemException reason string (which effectively becomes the > > java.lang.RuntimeException detail message) be encoded on the wire in an > > exceptional reply. However given that the language mapping was left > > open, I would agree that providing the exception stack trace (option #3) > > in addition would be a useful diagnostic aid. The only concern I'd have > > is that a exception raised on a cascaded invocation would become a bit > > overloaded with mutliple stack traces - i.e. A calls B calls C calls D > > which raises exception E => once E is delivered to A, > > E.printStaceTrace() will include 4 stack traces. > > > I agree that we should try to avoid this, since only the original stack trace > is likely to contain useful debugging information. I think the ORB that creates > the ExceptionDetailMessage service context should detect that the detail message > already contains a stack trace and avoid appending a second one. This could be > done by having the ORB add some marker (e.g., a leading ">") to the wstring in > the ExceptionDetailMessage service context. The ORB would only put the stack > trace into the service context if this marker isn't already present in the > exception's detail message. > > > I'm also a little unclear on how the ExceptionDetailMessage service > > context would work with user exceptions (assuming your intention is to > > use this mechanism for user exceptions as well as system exceptions, > > given that the service context may be passed with USER_EXCEPTION and > > SYSTEM_EXCEPTION replies). In the case of streams-based stubs, an > > org.omg.CORBA.portable.ApplicationException encapsulating the exception > > type ID and an input stream containing the exception data would be > > thrown back to the stub, which instaniates the appropriate user > > exception type via the helper class - i.e. there's no mechanism to pass > > up the detail message. In the case of the DII-based stubs, a similar > > argument applies to the org.omg.CORBA.UnknownUserException. Am I missing > > something here, or would we need to modify these wrapper classes or the > > user exception helper classes or the stubs to accomodate this? > > > You are right that this is a problem. However, there is a partial solution. > The detail message can be passed back to stream-based stubs by creating a > subclass of ApplicationException that takes a detailMessage on its constructor > and overrides getMessage() to return this detailMessage. This would allow > stream-based stubs to call getMessage() on the ApplicationException and > use the returned string (if any) to set the detailMessage in the user > exception that they throw back to the application. Existing stubs would > just ignore the new detailMessage, and new ones would only pick it up if > the ORB had set it. It isn't even necessary to standardize the name of the > new subclass of ApplicationException that does this, since the stubs only > have to call the Throwable.getMessage() method on the ApplicationException. > However, it might be more straightforward to make this a standard class. > > Unfortunately, this doesn't work for DII stubs since UnknownUserException is > for no obvious reason declared final. So DII stubs will never pass this > message back. I'd be willing to make this a limitation of using DII stubs. > > > On the server side there also seems to be an issue with streams-based > > skeletons which simply catch a user exception, encoding it onto the > > output stream returned by > > org.omg.CORBA.portable.ResponseHandler.createExceptionReply() without > > any reference to the detail message - in fact I'd expect in many ORB > > implementations the reply service context list would already be encoded > > on the stream returned from createExceptionReply(), so there would not > > be an opportunity to add an ExceptionDetailMessage at this stage. > > > This is somewhat harder to deal with. Ideally there would be an overloaded > getExceptionReply(userException) method which would create the necessary > service context. This could be defined in a new interface ResponseHandler2 > (actual name TBD) which extends ResponseHandler, since ResponseHandler is > "locked in" to the JDK core. > > Skeletons that support passing back a detailMessage would check if the > passed-in ResponseHandler is an instanceof ResponseHandler2. If so, they > would call ResponseHandler2.getExceptionReply(userException) and if not, > they would call ResponseHandler.getExceptionReply(). > > ORBs that support this mechanism would pass the skeleton's invoke() method > an object that implements the new ResponseHandler2 interface. > > > Should we limit usage of this service context to SystemExceptions? > > > It is simpler to do this, but I think the approach I have suggested above is > workable, upwards compatible, and not too difficult to implement. What do > you think? > > Simon > > > Regards, > > Eoghan Glynn. > > > > Orbix2000/Java Engineering Team. > > > > Simon Nash wrote: > > > > > > The interop RTF resolved issue 3405 by adding a new service context called > > > ExceptionDetailMessage. The usage of this service context was > > > left to language mappings to define. We need to define this usage for Java. > > > > > > Writing the service context: > > > > > > There are a few possibilities that come to mind: > > > 1) The result of calling getMessage() on the exception. > > > 2) The result of calling toString() on the exception. > > > 3) The result of calling printStackTrace(PrintWriter) on the exception. > > > > > > I'm inclined to think that option 3 is best, since the callee's stack trace > > > is often very valuable debugging information. > > > > > > Reading the service context: > > > > > > The wstring from the service context should become the Java error message > > > in the unmarshalled exception object. > > > > > > Simon > > > -- > > > Simon C Nash, Technology Architect, IBM Java Technology Centre > > > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > > > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > > -- > Simon C Nash, Technology Architect, IBM Java Technology Centre > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Mon, 6 Nov 2000 14:39:01 -0500 (EST) From: Bob Scheifler - SMI Software Development Reply-To: Bob Scheifler - SMI Software Development Subject: Re: Usage of ExceptionDetailMessage service context To: nash@hursley.ibm.com Cc: java-rtf@omg.org MIME-Version: 1.0 Content-MD5: ru71TsIt2yMc/dyEw9pTZg== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: #Lpd9Qm]d91?X!!BeC!! > There are a few possibilities that come to mind: > 1) The result of calling getMessage() on the exception. > 2) The result of calling toString() on the exception. > 3) The result of calling printStackTrace(PrintWriter) on the exception. I'm merely a bystander, but option 3 can easily be considered opening up a security/privacy hole, in that it reveals information about the internal implementation of the server. I think it would be imprudent to mandate it. - Bob Date: Mon, 06 Nov 2000 22:13:40 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Bob Scheifler - SMI Software Development CC: java-rtf@omg.org Subject: Re: Usage of ExceptionDetailMessage service context References: <200011061936.OAA01517@eastmail1.East.Sun.COM> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: *L)e9g4#e9j<4e9`PO!! Bob, Good point. Including the stack trace should be permitted but not mandated. Simon Bob Scheifler - SMI Software Development wrote: > > > There are a few possibilities that come to mind: > > 1) The result of calling getMessage() on the exception. > > 2) The result of calling toString() on the exception. > > 3) The result of calling printStackTrace(PrintWriter) on the exception. > > I'm merely a bystander, but option 3 can easily be considered opening > up a security/privacy hole, in that it reveals information about > the internal implementation of the server. I think it would be > imprudent to mandate it. > > - Bob -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Tue, 07 Nov 2000 23:10:23 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Vijaykumar Natarajan CC: Eoghan Glynn , java-rtf@omg.org Subject: Re: Usage of ExceptionDetailMessage service context References: <3A00A49D.1B4E7550@hursley.ibm.com> <3A017406.215FC385@iona.com> <3A05A4B6.D85035C3@hursley.ibm.com> <3A06FCC3.71CD1CF6@inprise.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: J@=!!DDk!!>U:e9?*`!! Vijay, Vijaykumar Natarajan wrote: > > Hi all, > Simon Nash wrote: > > > Eoghan, > > > > Eoghan Glynn wrote: > > > > > > Hi Simon, > > > > > > If memory serves, the original intent of the interop issue was just to > > > allow the SystemException reason string (which effectively becomes the > > > java.lang.RuntimeException detail message) be encoded on the wire in an > > > exceptional reply. However given that the language mapping was left > > > open, I would agree that providing the exception stack trace (option #3) > > > in addition would be a useful diagnostic aid. The only concern I'd have > > > is that a exception raised on a cascaded invocation would become a bit > > > overloaded with mutliple stack traces - i.e. A calls B calls C calls D > > > which raises exception E => once E is delivered to A, > > > E.printStaceTrace() will include 4 stack traces. > > > > > I agree that we should try to avoid this, since only the original stack trace > > is likely to contain useful debugging information. I think the ORB that creates > > the ExceptionDetailMessage service context should detect that the detail message > > already contains a stack trace and avoid appending a second one. This could be > > done by having the ORB add some marker (e.g., a leading ">") to the wstring in > > the ExceptionDetailMessage service context. The ORB would only put the stack > > trace into the service context if this marker isn't already present in the > > exception's detail message. > > I totally disagree. Since this is a feature that enables the debugging information > to be avaiable on the client side and there is really nothing useful that can be > done with the error message except printing it out, it makes most sense to provide > all the stack traces appended because that accurately represents the picture of what > actually happened. Yes it would be a little heavy but not having it retracts from > the value added by the stack trace. > On further consideration, I agree that this could of be some use. My original thought was that the "rethrows" stack traces provide little useful debugging information, since they will only have the call stack for the place where the ORB unmarshalled the exception from the GIOP stream and created a new copy of the same exception. However, they will also show application code calling the stub for the server method that threw the exception, which could provide some useful information. > > > I'm also a little unclear on how the ExceptionDetailMessage service > > > context would work with user exceptions (assuming your intention is to > > > use this mechanism for user exceptions as well as system exceptions, > > > given that the service context may be passed with USER_EXCEPTION and > > > SYSTEM_EXCEPTION replies). In the case of streams-based stubs, an > > > org.omg.CORBA.portable.ApplicationException encapsulating the exception > > > type ID and an input stream containing the exception data would be > > > thrown back to the stub, which instaniates the appropriate user > > > exception type via the helper class - i.e. there's no mechanism to pass > > > up the detail message. In the case of the DII-based stubs, a similar > > > argument applies to the org.omg.CORBA.UnknownUserException. Am I missing > > > something here, or would we need to modify these wrapper classes or the > > > user exception helper classes or the stubs to accomodate this? > > > > > You are right that this is a problem. However, there is a partial solution. > > The detail message can be passed back to stream-based stubs by creating a > > subclass of ApplicationException that takes a detailMessage on its constructor > > and overrides getMessage() to return this detailMessage. This would allow > > stream-based stubs to call getMessage() on the ApplicationException and > > use the returned string (if any) to set the detailMessage in the user > > exception that they throw back to the application. Existing stubs would > > just ignore the new detailMessage, and new ones would only pick it up if > > the ORB had set it. It isn't even necessary to standardize the name of the > > new subclass of ApplicationException that does this, since the stubs only > > have to call the Throwable.getMessage() method on the ApplicationException. > > However, it might be more straightforward to make this a standard class. > > > > Unfortunately, this doesn't work for DII stubs since UnknownUserException is > > for no obvious reason declared final. So DII stubs will never pass this > > message back. I'd be willing to make this a limitation of using DII stubs. > > I am not too keen on overloading the use of this in the case of standard System/User > exceptions as they have well defined semantics defined either by the spec or by the > user application respectively. > We have received a number of requests from users to provide this information (at least the server-side detail message) for SystemExceptions. > The case of Unknown is special as it is the only > means of communicating a very wide variety of exceptions on the server side, with > no user control possible on the server side. As for the message travelling up, to > the user, the use of it for ServerErrors and ServerExceptions is easily achieved by > setting the message on the ServerError and ServerException exceptions themselves. > If we don't pass back a stack strace, there is no problem, since the serialized exception in the UnknownExceptionInfo service context already contains the server's detail message. It's tricker if we want to pass back the server's stack trace to the client. These exceptions are created by mapSystemException, which is passed an UnknownException, which doesn't have any way of holding the additional information from the ExceptionDetailMessage service context (until Sun implements the resolution to issue 3570 in 1.4). However, the same subclassing "trick" that I previously proposed for ApplicationException could be used in the interim to pass this information back to the stub in a subclass of UnknownException so that it is available to the implementation of mapSystemException. > However, the case for RuntimeException is harder because the stubs throw the > original exception unmarshaled from the stream and there is no opportunity to > replace the string message in that exception. > This is a problem if we want to pass back stack trace information, since there's no obvious way to replace the string message in the already deserialized exception. Perhaps the PutField facility of serialization could be used by the server to serialize the RuntimeException with a modified string message that includes a stack trace. I'll experiment and see if this works. > Passing the message back in > UnknownUserException for DII is still fine, because the java RTF just passed the > resolution to provide a constructor w/ a String message. > This was added by issue 3570 to UnknownException, not UnknownUserException. So the problem with DII (which uses the latter class) is not solved. > > > > > On the server side there also seems to be an issue with streams-based > > > skeletons which simply catch a user exception, encoding it onto the > > > output stream returned by > > > org.omg.CORBA.portable.ResponseHandler.createExceptionReply() without > > > any reference to the detail message - in fact I'd expect in many ORB > > > implementations the reply service context list would already be encoded > > > on the stream returned from createExceptionReply(), so there would not > > > be an opportunity to add an ExceptionDetailMessage at this stage. > > > > > This is somewhat harder to deal with. Ideally there would be an overloaded > > getExceptionReply(userException) method which would create the necessary > > service context. This could be defined in a new interface ResponseHandler2 > > (actual name TBD) which extends ResponseHandler, since ResponseHandler is > > "locked in" to the JDK core. > > > > Skeletons that support passing back a detailMessage would check if the > > passed-in ResponseHandler is an instanceof ResponseHandler2. If so, they > > would call ResponseHandler2.getExceptionReply(userException) and if not, > > they would call ResponseHandler.getExceptionReply(). > > > > ORBs that support this mechanism would pass the skeleton's invoke() method > > an object that implements the new ResponseHandler2 interface. > > > > > Should we limit usage of this service context to SystemExceptions? > > > > > It is simpler to do this, but I think the approach I have suggested above is > > workable, upwards compatible, and not too difficult to implement. What do > > you think? > > My feeling is to restrict this to only CORBA::UNKNOWN or at most to > SystemExceptions. > I think this is definitely needed on all SystemExceptions. I'd be OK with restricting it to SystemExceptions for now, since we could always consider extending it to user exceptions later. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Tue, 07 Nov 2000 23:14:41 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Eoghan Glynn CC: java-rtf@omg.org Subject: Re: Usage of ExceptionDetailMessage service context References: <3A00A49D.1B4E7550@hursley.ibm.com> <3A017406.215FC385@iona.com> <3A05A4B6.D85035C3@hursley.ibm.com> <3A070462.D3F889B8@iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: =J?!!&2/!!&;B!!iHP!! Eoghan, Eoghan Glynn wrote: > > Hi Simon, > > Extending the org.omg.CORBA.portable classes in the fashion you suggest > is workable, but strikes me as over-kill, as the user exceptions may > always be defined to carry any context/diagnostic information that the > app requires. Its the case of system exceptions (or worse, Java > exceptions wrapped in UNKNOWN) where the developer/administrator really > needs help in determining what's going on. So I'd be of a mind to > restrict the usage of the service context to system exceptions only. > I'm OK with this for now. When we have real experience of doing this for system exceptions and Java exceptions, we can see if there is user demand to extend it to user exceptions. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Tue, 07 Nov 2000 18:28:41 -0800 From: "Vijaykumar Natarajan" X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Simon Nash CC: Vijaykumar Natarajan , Eoghan Glynn , java-rtf@omg.org Subject: Re: Usage of ExceptionDetailMessage service context References: <3A00A49D.1B4E7550@hursley.ibm.com> <3A017406.215FC385@iona.com> <3A05A4B6.D85035C3@hursley.ibm.com> <3A06FCC3.71CD1CF6@inprise.com> <3A088BDF.E272CD34@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: o&M!!8cTd9S<2e9Gb6e9 Hi Simon, > > > > I am not too keen on overloading the use of this in the case of > >standard System/User > > exceptions as they have well defined semantics defined either by > >the spec or by the > > user application respectively. > > > We have received a number of requests from users to provide this > >information > (at least the server-side detail message) for SystemExceptions. Then what I would suggest is that for exceptions other than UNKNOWN, the ExceptionDetailMessage include the Server side detail message and for UNKNOWN, it is upto the implementation to choose to either include the detail message or the stack trace (Since both result as message strings in the exception, there is no extra information that needs to be provided...). > > > Passing the message back in > > UnknownUserException for DII is still fine, because the java RTF just passed the > > resolution to provide a constructor w/ a String message. > > > This was added by issue 3570 to UnknownException, not UnknownUserException. > So the problem with DII (which uses the latter class) is not solved. Oops! My mistake. You are right. This was added to UnknownException. Going back then to the original issue w/ DII. An UnknownUserException occurs only when the server does not adhere to the IDL contract. Providing a stack trace in this case is still adds no useful information, as this was thrown explicitly in the user code of the method that was called by the client. Vijay Date: Sat, 11 Nov 2000 22:31:34 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Vijaykumar Natarajan CC: Eoghan Glynn , java-rtf@omg.org Subject: Re: Usage of ExceptionDetailMessage service context References: <3A00A49D.1B4E7550@hursley.ibm.com> <3A017406.215FC385@iona.com> <3A05A4B6.D85035C3@hursley.ibm.com> <3A06FCC3.71CD1CF6@inprise.com> <3A088BDF.E272CD34@hursley.ibm.com> <3A08BA59.B2656CC9@inprise.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: W=4e9*jg!!OLBe9"ZW!! Vijay, Vijaykumar Natarajan wrote: > > Hi Simon, > > > > > > > I am not too keen on overloading the use of this in the case of standard System/User > > > exceptions as they have well defined semantics defined either by the spec or by the > > > user application respectively. > > > > > We have received a number of requests from users to provide this information > > (at least the server-side detail message) for SystemExceptions. > > Then what I would suggest is that for exceptions other than UNKNOWN, the > ExceptionDetailMessage > include the Server side detail message and for UNKNOWN, it is upto the implementation to > choose to either include the detail message or the stack trace (Since both result as > message strings in the exception, there is no extra information that needs to be > provided...). > I don't know why you think the stack trace is only useful for UNKNOWN exceptions. In our experience (and that of our users) it is frequently useful to have this information for other system exceptions thrown by the server-side ORB. > > > > > Passing the message back in > > > UnknownUserException for DII is still fine, because the java RTF just passed the > > > resolution to provide a constructor w/ a String message. > > > > > This was added by issue 3570 to UnknownException, not UnknownUserException. > > So the problem with DII (which uses the latter class) is not solved. > > Oops! My mistake. You are right. This was added to UnknownException. Going back then to > the original issue w/ DII. An UnknownUserException occurs only when the server does not > adhere to the IDL contract. Providing a stack trace in this case is still adds no useful > information, as this was thrown explicitly in the user code of the method that was called > by the client. > I beg to differ. All user exceptions passed back to a DII client are passed using an UnknownUserException (confusing name) object. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Importance: Normal Subject: Issue 4013: Usage of ExceptionDetailMessage service context To: Mary Leland Cc: Java RTF X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Ann Dalton1" Date: Thu, 19 Jul 2001 18:00:41 +0100 X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.6 |December 14, 2000) at 19/07/2001 17:59:01 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: g5 X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Java RTF Subject: Re: Issue 4013: Usage of ExceptionDetailMessage service context References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 0m,e9&P4e9eKb!!jDod9 RTF Members, Ann's proposal is precise enough to vote on, and appears to capture a compromise based on the previous discussion. Please send in any feedback by 10 am EDT on Tuesday, July 24; if it seems reasonable, I'll initiate a vote at that point. Thanks, Mary Leland Chair, OMG IDL to Java RTF (973) 443-7562 mleland@fpk.hp.com Ann Dalton1 wrote: > > Mary, > > I've recently taken over some of Simon Nash's responsibilities for IBM's > Java ORB, including > those relating to the IDL-to-Java RTF. I'm trying to follow up some of the > issues Simon was > concerned with and notice that this one was discussed in November 2000 but, > as far as I can see, > didn't progress to resolution. > As we have customers waiting for this function, could we please reopen the > discussion with a view > to resolving the issue. > Many thanks, > Ann > > The following revised proposal is an attempt to incorporate feedback > received previously:- > > Summary: The interop RTF resolved issue 3405 by adding a new service > context called > ExceptionDetailMessage. The usage of this service context was > left to language mappings to define. We need to define this usage for > Java. > > The proposal is to define the ExceptionDetailMessage service context to be > associated with Reply messages with a reply_status of SYSTEM_EXCEPTION. > > Writing the service context: > > The callee's stack trace is often very valuable debugging information but > may contain > sensitive or unwanted information. The wstring within the service context > will therefore contain > the result of calling either printStackTrace(PrintWriter) or getMessage() > on the exception. > > Reading the service context: > > The wstring from the service context shall become the Java error message > in the unmarshalled exception object. > > Revised Text: In section 1.15.2 System Exceptions, insert a new third > paragraph after the text > "rules defined in Section 1.5, 'Helpers', on page 1-13.", as follows:- > "When a System Exception is marshaled, its GIOP Reply message shall include > an > associated ExceptionDetailMessage service context. The callee's stack trace > is often very > valuable debugging information but may contain sensitive or unwanted > information. > The wstring within the service context will therefore contain the result of > calling either > printStackTrace(PrintWriter) or getMessage() on the exception. When > unmarshalling a > System Exception on the client side, the wstring from any > ExceptionDetailMessage service > context shall become the Java error message in the unmarshalled exception > object." Date: Thu, 19 Jul 2001 19:23:14 +0100 From: Eoghan Glynn X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ann Dalton1 CC: Mary Leland , Java RTF Subject: Re: Issue 4013: Usage of ExceptionDetailMessage service context References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: :^Od9?&Td9f/~e9GP5!! Hi Ann, Some points of feedback ... 1. Why restrict the service context data to either the output of printStackTrace() or getMessage() applied to the Exception? Further useful information about the exception could also be provided, such as "stringified" minor code to be used where the minor code is unknown to the client and thus cannot be displayed/logged in a human readable fashion. It would be useful IMO to allow implementations to freely prefix the output of printStackTrace() or getMessage() with any other information they deem useful. 2. For propogated exceptions, is it only the first stack trace in the chain, or the last trace, or even all traces, that's provided to the client? This was discussed last time round: > The only concern I'd have > is that a exception raised on a cascaded invocation would become a > bit > overloaded with mutliple stack traces - i.e. A calls B calls C calls > D > which raises exception E => once E is delivered to A, > E.printStaceTrace() will include 4 stack traces. and Simon's opinion was: > I agree that we should try to avoid this, since only the original stack > trace is likely to contain useful debugging information. I think the > ORB that creates the ExceptionDetailMessage service context should > detect that the detail message already contains a stack trace and avoid > appending a second one. This could be done by having the ORB add some > marker (e.g., a leading ">") to the wstring in the > ExceptionDetailMessage service context. The ORB would only put the > stack trace into the service context if this marker isn't already > present in the exception's detail message. but I can't remember any more specific resolution. Regards, Eoghan Glynn. Ann Dalton1 wrote: > > Mary, > > I've recently taken over some of Simon Nash's responsibilities for IBM's > Java ORB, including > those relating to the IDL-to-Java RTF. I'm trying to follow up some of the > issues Simon was > concerned with and notice that this one was discussed in November 2000 but, > as far as I can see, > didn't progress to resolution. > As we have customers waiting for this function, could we please reopen the > discussion with a view > to resolving the issue. > Many thanks, > Ann > > The following revised proposal is an attempt to incorporate feedback > received previously:- > > Summary: The interop RTF resolved issue 3405 by adding a new service > context called > ExceptionDetailMessage. The usage of this service context was > left to language mappings to define. We need to define this usage for > Java. > > The proposal is to define the ExceptionDetailMessage service context to be > associated with Reply messages with a reply_status of SYSTEM_EXCEPTION. > > Writing the service context: > > The callee's stack trace is often very valuable debugging information but > may contain > sensitive or unwanted information. The wstring within the service context > will therefore contain > the result of calling either printStackTrace(PrintWriter) or getMessage() > on the exception. > > Reading the service context: > > The wstring from the service context shall become the Java error message > in the unmarshalled exception object. > > Revised Text: In section 1.15.2 System Exceptions, insert a new third > paragraph after the text > "rules defined in Section 1.5, 'Helpers', on page 1-13.", as follows:- > "When a System Exception is marshaled, its GIOP Reply message shall include > an > associated ExceptionDetailMessage service context. The callee's stack trace > is often very > valuable debugging information but may contain sensitive or unwanted > information. > The wstring within the service context will therefore contain the result of > calling either > printStackTrace(PrintWriter) or getMessage() on the exception. When > unmarshalling a > System Exception on the client side, the wstring from any > ExceptionDetailMessage service > context shall become the Java error message in the unmarshalled exception > object." Date: Thu, 19 Jul 2001 18:13:59 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Issue 4013: Usage of ExceptionDetailMessage service context To: ann_dalton@uk.ibm.com, eglynn@iona.com Cc: mleland@fpk.hp.com, java-rtf@omg.org MIME-Version: 1.0 Content-MD5: n1CCnF2pv2LM3xgeEaRGFQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: %!=!!;bkd9YU9e9RTLe9 Status: RO Another issue with this proposal is the changes in exceptions that are introduced in JDK 1.4 (Merlin). Merlin adds a new feature to java.lang.Throwable: a cause field for exception chaining. The cause field contains another Throwable, which can be set to the exception that caused the next exception to be thrown. This will most likely be valueable for complex layered systems, in which low level failures cause a cascade of errors, and the errors need to be reported. Of course, we could just ignore the cause information, but this will likely provide valuable debugging information (or further security holes depending on your view). Also, I am not comfortable with dictating the layout of the information passed back. I think it is up to the ORB vendor to provide such a facility, and the only thing that an application can do is print out the information. There is no interop or portability requirement here. I could also see a possibility of integrating this mechanism with a comprehensive logging system by logging the details of the error and placing only a handle for the error into the service context. A framework could be provided to give access to detailed logged information related to the error. Finally, note that Merlin provies a new method StackTraceElement[] getStackTrace() on Throwable that provides programmatic access to the stack trace. This makes it convenient and portable for systems to format and process stack traces portably in many ways, which can include placing some encoding of this information in the service context, which may be different from the result of calling printStackTrace. Ken. Date: Fri, 20 Jul 2001 11:36:09 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Eoghan Glynn CC: Ann Dalton1 , Mary Leland , Java RTF Subject: Re: Issue 4013: Usage of ExceptionDetailMessage service context References: <3B572592.8C91A35B@iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: G"8!!)SH!!7Y-!!R8Td9 Eoghan, Regarding cascaded stack traces, I think the discussion moved on beyond that point and there was consensus that the concatenation of stack traces was useful and should not be suppressed. Simon Eoghan Glynn wrote: > > Hi Ann, > > Some points of feedback ... > > 1. Why restrict the service context data to either the output of > printStackTrace() or getMessage() applied to the Exception? Further > useful information about the exception could also be provided, such as > "stringified" minor code to be used where the minor code is unknown to > the client and thus cannot be displayed/logged in a human readable > fashion. It would be useful IMO to allow implementations to freely > prefix the output of printStackTrace() or getMessage() with any other > information they deem useful. > > 2. For propogated exceptions, is it only the first stack trace in the > chain, or the last trace, or even all traces, that's provided to the > client? This was discussed last time round: > > > The only concern I'd have > > is that a exception raised on a cascaded invocation would become a bit > > overloaded with mutliple stack traces - i.e. A calls B calls C calls D > > which raises exception E => once E is delivered to A, > > E.printStaceTrace() will include 4 stack traces. > > and Simon's opinion was: > > > I agree that we should try to avoid this, since only the original stack > > trace is likely to contain useful debugging information. I think the > > ORB that creates the ExceptionDetailMessage service context should > > detect that the detail message already contains a stack trace and avoid > > appending a second one. This could be done by having the ORB add some > > marker (e.g., a leading ">") to the wstring in the > > ExceptionDetailMessage service context. The ORB would only put the > > stack trace into the service context if this marker isn't already > > present in the exception's detail message. > > but I can't remember any more specific resolution. > > Regards, > Eoghan Glynn. > > Ann Dalton1 wrote: > > > > Mary, > > > > I've recently taken over some of Simon Nash's responsibilities for IBM's > > Java ORB, including > > those relating to the IDL-to-Java RTF. I'm trying to follow up some of the > > issues Simon was > > concerned with and notice that this one was discussed in November 2000 but, > > as far as I can see, > > didn't progress to resolution. > > As we have customers waiting for this function, could we please reopen the > > discussion with a view > > to resolving the issue. > > Many thanks, > > Ann > > > > The following revised proposal is an attempt to incorporate feedback > > received previously:- > > > > Summary: The interop RTF resolved issue 3405 by adding a new service > > context called > > ExceptionDetailMessage. The usage of this service context was > > left to language mappings to define. We need to define this usage for > > Java. > > > > The proposal is to define the ExceptionDetailMessage service context to be > > associated with Reply messages with a reply_status of SYSTEM_EXCEPTION. > > > > Writing the service context: > > > > The callee's stack trace is often very valuable debugging information but > > may contain > > sensitive or unwanted information. The wstring within the service context > > will therefore contain > > the result of calling either printStackTrace(PrintWriter) or getMessage() > > on the exception. > > > > Reading the service context: > > > > The wstring from the service context shall become the Java error message > > in the unmarshalled exception object. > > > > Revised Text: In section 1.15.2 System Exceptions, insert a new third > > paragraph after the text > > "rules defined in Section 1.5, 'Helpers', on page 1-13.", as follows:- > > "When a System Exception is marshaled, its GIOP Reply message shall include > > an > > associated ExceptionDetailMessage service context. The callee's stack trace > > is often very > > valuable debugging information but may contain sensitive or unwanted > > information. > > The wstring within the service context will therefore contain the result of > > calling either > > printStackTrace(PrintWriter) or getMessage() on the exception. When > > unmarshalling a > > System Exception on the client side, the wstring from any > > ExceptionDetailMessage service > > context shall become the Java error message in the unmarshalled exception > > object." -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Importance: High Subject: Re: Issue 4013: Usage of ExceptionDetailMessage service context To: Ken Cavanaugh , Eoghan Glynn Cc: Mary Leland , Java RTF X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Ann Dalton1" Date: Mon, 23 Jul 2001 10:28:19 +0100 X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.6 |December 14, 2000) at 23/07/2001 10:26:41 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: =`&!!VX9e9E'9e96(V!! Ken, Thanks for the additional information re JDK 1.4. Since we can't pre-req JDK 1.4, I guess we should merely try to avoid precluding its usage at a later date? I assume calling printStackTrace(PrintWriter) or getMessage() on the exception will probably still work on JDK 1.4, but may have augmented outputs? It seems reasonable to me that an ORB should have the freedom to include whatever detail it deems useful but since, as you say, all an application can do is print it, I would be concerned if it were merely a handle to data in some other repository: that would appear to couple client and server ORBs too tightly together. The intention was, as far as I can see, to require an ORB to provide some debugging information that would be useful from any client. getMessage() or the rather longer printStackTrace(), seemed to satisfy that requirement simply. However, if that is deemed overly proscriptive, perhaps we could amend the proposal to say "When a System Exception is marshaled, its GIOP Reply message shall include an associated ExceptionDetailMessage service context. The callee's stack trace is often very valuable debugging information but may contain sensitive or unwanted information. The wstring within the service context will therefore contain additional information relating to the exception, for example the result of calling either printStackTrace(PrintWriter) or getMessage() on the exception. When unmarshalling a System Exception on the client side, the wstring from any ExceptionDetailMessage service context shall become the Java error message in the unmarshalled exception object." What do you think? Ann A E Dalton Java Technology Centre MP 146, IBM UK Labs, Hursley Park, Winchester, Hants. SO21 2JN Tel: UK-1962-816791 Fax: UK-1962-815388 ann_dalton@uk.ibm.com ---------------------- Forwarded by Ann Dalton1/UK/IBM on 22/07/2001 21:24 --------------------------- Ken Cavanaugh on 20/07/2001 02:13:59 Please respond to Ken Cavanaugh To: Ann Dalton1/UK/IBM@IBMGB, eglynn@iona.com cc: mleland@fpk.hp.com, java-rtf@omg.org Subject: Re: Issue 4013: Usage of ExceptionDetailMessage service context Another issue with this proposal is the changes in exceptions that are introduced in JDK 1.4 (Merlin). Merlin adds a new feature to java.lang.Throwable: a cause field for exception chaining. The cause field contains another Throwable, which can be set to the exception that caused the next exception to be thrown. This will most likely be valueable for complex layered systems, in which low level failures cause a cascade of errors, and the errors need to be reported. Of course, we could just ignore the cause information, but this will likely provide valuable debugging information (or further security holes depending on your view). Also, I am not comfortable with dictating the layout of the information passed back. I think it is up to the ORB vendor to provide such a facility, and the only thing that an application can do is print out the information. There is no interop or portability requirement here. I could also see a possibility of integrating this mechanism with a comprehensive logging system by logging the details of the error and placing only a handle for the error into the service context. A framework could be provided to give access to detailed logged information related to the error. Finally, note that Merlin provies a new method StackTraceElement[] getStackTrace() on Throwable that provides programmatic access to the stack trace. This makes it convenient and portable for systems to format and process stack traces portably in many ways, which can include placing some encoding of this information in the service context, which may be different from the result of calling printStackTrace. Ken. Simon Nash on 20/07/2001 11:36:09 Please respond to Simon Nash To: Eoghan Glynn cc: Ann Dalton1/UK/IBM@IBMGB, Mary Leland , Java RTF Subject: Re: Issue 4013: Usage of ExceptionDetailMessage service context Eoghan, Regarding cascaded stack traces, I think the discussion moved on beyond that point and there was consensus that the concatenation of stack traces was useful and should not be suppressed. Simon Eoghan Glynn wrote: > > Hi Ann, > > Some points of feedback ... > > 1. Why restrict the service context data to either the output of > printStackTrace() or getMessage() applied to the Exception? Further > useful information about the exception could also be provided, such as > "stringified" minor code to be used where the minor code is unknown to > the client and thus cannot be displayed/logged in a human readable > fashion. It would be useful IMO to allow implementations to freely > prefix the output of printStackTrace() or getMessage() with any other > information they deem useful. > > 2. For propogated exceptions, is it only the first stack trace in the > chain, or the last trace, or even all traces, that's provided to the > client? This was discussed last time round: > > > The only concern I'd have > > is that a exception raised on a cascaded invocation would become a bit > > overloaded with mutliple stack traces - i.e. A calls B calls C calls D > > which raises exception E => once E is delivered to A, > > E.printStaceTrace() will include 4 stack traces. > > and Simon's opinion was: > > > I agree that we should try to avoid this, since only the original stack > > trace is likely to contain useful debugging information. I think the > > ORB that creates the ExceptionDetailMessage service context should > > detect that the detail message already contains a stack trace and avoid > > appending a second one. This could be done by having the ORB add some > > marker (e.g., a leading ">") to the wstring in the > > ExceptionDetailMessage service context. The ORB would only put the > > stack trace into the service context if this marker isn't already > > present in the exception's detail message. > > but I can't remember any more specific resolution. > > Regards, > Eoghan Glynn. > > Ann Dalton1 wrote: > > > > Mary, > > > > I've recently taken over some of Simon Nash's responsibilities for IBM's > > Java ORB, including > > those relating to the IDL-to-Java RTF. I'm trying to follow up some of the > > issues Simon was > > concerned with and notice that this one was discussed in November 2000 but, > > as far as I can see, > > didn't progress to resolution. > > As we have customers waiting for this function, could we please reopen the > > discussion with a view > > to resolving the issue. > > Many thanks, > > Ann > > > > The following revised proposal is an attempt to incorporate feedback > > received previously:- > > > > Summary: The interop RTF resolved issue 3405 by adding a new service > > context called > > ExceptionDetailMessage. The usage of this service context was > > left to language mappings to define. We need to define this usage for > > Java. > > > > The proposal is to define the ExceptionDetailMessage service context to be > > associated with Reply messages with a reply_status of SYSTEM_EXCEPTION. > > > > Writing the service context: > > > > The callee's stack trace is often very valuable debugging information but > > may contain > > sensitive or unwanted information. The wstring within the service context > > will therefore contain > > the result of calling either printStackTrace(PrintWriter) or getMessage () > > on the exception. > > > > Reading the service context: > > > > The wstring from the service context shall become the Java error message > > in the unmarshalled exception object. > > > > Revised Text: In section 1.15.2 System Exceptions, insert a new third > > paragraph after the text > > "rules defined in Section 1.5, 'Helpers', on page 1-13.", as follows:- > > "When a System Exception is marshaled, its GIOP Reply message shall include > > an > > associated ExceptionDetailMessage service context. The callee's stack trace > > is often very > > valuable debugging information but may contain sensitive or unwanted > > information. > > The wstring within the service context will therefore contain the result of > > calling either > > printStackTrace(PrintWriter) or getMessage() on the exception. When > > unmarshalling a > > System Exception on the client side, the wstring from any > > ExceptionDetailMessage service > > context shall become the Java error message in the unmarshalled exception > > object." Date: Mon, 23 Jul 2001 11:04:57 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Issue 4013: Usage of ExceptionDetailMessage service context To: Ken.Cavanaugh@sun.com, eglynn@iona.com, ann_dalton@uk.ibm.com Cc: mleland@fpk.hp.com, java-rtf@omg.org MIME-Version: 1.0 Content-MD5: sFzc64HCNmEWUVGN7sKUlg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: !hh!!oP6e91C/e9>5;!! >Importance: High >Subject: Re: Issue 4013: Usage of ExceptionDetailMessage service >context >To: Ken Cavanaugh , Eoghan Glynn > >Cc: Mary Leland , Java RTF >From: "Ann Dalton1" >X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.6 >|December 14, 2000) at 23/07/2001 10:26:41 >MIME-Version: 1.0 > >Ken, > >Thanks for the additional information re JDK 1.4. Since we can't >pre-req >JDK 1.4, I guess we should merely try to avoid precluding its usage >at a >later date? That's fine with me. I just don't want the resolution of the issue to be overly restrictive. >I assume calling printStackTrace(PrintWriter) or getMessage() >on the exception will probably still work on JDK 1.4, but may have >augmented outputs? > I think it produces the same output, since you can always get the cause and print its stack trace independently. >It seems reasonable to me that an ORB should have the freedom to >include whatever detail it deems useful but since, as you say, all an >application can do is print it, I would be concerned if it were >merely a >handle to data in some other repository: that would appear to couple >client and server ORBs too tightly together. The intention was, as >far >as I can see, to require an ORB to provide some debugging information >that would be useful from any client. getMessage() or the rather >longer >printStackTrace(), seemed to satisfy that requirement simply. I realized after I sent the message that the discussion about handles to repositories for error logging was not really relevant to the issue. An ORB can always choose to implement some such mechanism, but the issue at hand is just to provide more information that can be printed by any client. >However, >if that is deemed overly proscriptive, perhaps we could amend the >proposal to say > >"When a System Exception is marshaled, its GIOP Reply message >shall include an associated ExceptionDetailMessage service context. >The callee's stack trace is often very valuable debugging information >but may contain sensitive or unwanted information. The wstring within >the service context will therefore contain additional information >relating to the exception, for example the result of calling either >printStackTrace(PrintWriter) or getMessage() on the exception. >When unmarshalling a System Exception on the client side, the wstring >from any ExceptionDetailMessage service context shall become the >Java error message in the unmarshalled exception object." > >What do you think? I think this is fine. It gives examples of possible contents for the ExceptionDetailMessage without constraining what an ORB may do. A compliant implementation may choose to do anything reasonable, so long as the result is some sort of displayable string. For example, I could imagine encoding a small XML document that describes the error in as much detail as the ORB has available (at an obvious cost in size). Ken. Date: Mon, 23 Jul 2001 14:57:18 -0400 (EDT) From: Bob Scheifler - SMI Software Development Reply-To: Bob Scheifler - SMI Software Development Subject: Re: Issue 4013: Usage of ExceptionDetailMessage service context To: Ken.Cavanaugh@sun.com, eglynn@iona.com, ann_dalton@uk.ibm.com Cc: mleland@fpk.hp.com, java-rtf@omg.org MIME-Version: 1.0 Content-MD5: MzkpA5q5gI6UIa0PPBdJRg== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: l4\!!)V+!!@#-e9g7H!! > >I assume calling printStackTrace(PrintWriter) or getMessage() > >on the exception will probably still work on JDK 1.4, but may have > >augmented outputs? > > > > I think it produces the same output, since you can always get the > >cause > and print its stack trace independently. The output has been augmented to include the entire causal chain of exceptions and their stack traces (abbreviated where they share common frames) - Bob Date: Tue, 24 Jul 2001 10:39:19 -0400 From: Mary Leland X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Java RTF Subject: VOTE: Issue 4013, Due August 1, 2001 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: "^A!!P0\d9`KIe97G4!! Here is a proposed resolution for Issue 4013. Votes are due by 5pm US EDT on August 1, 2001. ------------------------------------------------------------------------ Issue 4013: The interop RTF resolved issue 3405 by adding a new service context called ExceptionDetailMessage. The usage of this service context was left to language mappings to define. We need to define this usage for Java. Writing the service context: There are a few possibilities that come to mind: 1) The result of calling getMessage() on the exception. 2) The result of calling toString() on the exception. 3) The result of calling printStackTrace(PrintWriter) on the exception. I'm inclined to think that option 3 is best, since the callee's stack trace is often very valuable debugging information. Reading the service context: The wstring from the service context should become the Java error message in the unmarshalled exception object. ----------------------------------------------------------------------------- Proposed Resolution: In section 1.15.2 System Exceptions, insert a new third paragraph after the text "rules defined in Section 1.5, 'Helpers', on page 1-13.", as follows:- "When a System Exception is marshaled, its GIOP Reply message shall include an associated ExceptionDetailMessage service context. The callee's stack trace is often very valuable debugging information but may contain sensitive or unwanted information. The wstring within the service context will therefore contain additional information relating to the exception, for example the result of calling either printStackTrace(PrintWriter) or getMessage() on the exception. When unmarshalling a System Exception on the client side, the wstring from any ExceptionDetailMessage service context shall become the Java error message in the unmarshalled exception object." ---------------------------------------------------------------------------- Mary Leland Chair, OMG IDL to Java RTF +1 (973) 443-7562