You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-dev@xml.apache.org by Sanjiva Weerawarana <sa...@watson.ibm.com> on 2000/09/08 03:40:50 UTC
Re: Patch proposal: Ability to serialize parameters (specifically, exceptions) in a Fault
Hi Eric,
I put some code in to forward stack traces via the detail element ..
it does some of what you posted I think.
I didn't merge your code in because I wasn't certain of its applicability
in non Java-to-Java cases. That is, if the client is in VBScript and
the server is in Java, then sending a serialized exception object does
little good. I admit that I didn't review your code very carefully ..
so I may have gotten an incorrect intuition about it. Please correct if
I'm mistaken, but otherwise I am opposed to putting in special-case code
without some organized way of doing that .. that is, I fully expect
that Java-Java will be a common usecase and in that case it should be
possible to exploit that. I would like to see some generic solution to
the need to enable extensible special-casing.
(Did anyone else check out Eric's patch?)
Sanjiva.
----- Original Message -----
From: "Eric M. Dashofy" <ed...@ics.uci.edu>
To: <so...@xml.apache.org>
Sent: Monday, August 21, 2000 4:26 PM
Subject: Patch proposal: Ability to serialize parameters (specifically,
exceptions) in a Fault
>
> Okay everybody, I've never posted a patch to an Apache product before, so I
> will probably screw it up this first time. I would RTFM more, but the
> directions at http://xml.apache.org/source.html are a bit sparse; I've
> nonetheless tried to follow them closely :). I am going to post this
> proposal/rationale for the patch, then I'm going to post the patch in a
> formal [PATCH] email separately using the recommended format (diff -u
> file.java.orig file2.java >> patch)
>
> Patch type: Feature enhancement
>
> Description: The patch I'm proposing enhances Apache SOAP for Java 2.0 to
> allow users to include serialized objects, namely Parameters, in the detail
> element of a SOAP fault. The chief (but not sole) purpose of this is to
> allow SOAP to return a serialized Java exception when an error occurs in the
> invoked SOAP object. Currently, the only type of object that the API allows
> in the detail message of a Fault is a DOM Element, which can be used to
> store a marshalled exception, but in a hackish way.
>
> Reason for patch: With this capability in place, it becomes straightforward
> to implement RPC with Exceptions and build an RMI-like service on top of
> SOAP. Without this capability, the client cannot reconstruct an exception
> that happened on the server, even if it can be marshalled.
>
> Alternatives to the patch: I could have modified the server to include the
> exception in a Response, but in my research, Don Box and others have said
> that errors and exceptions never belong in a Response. Philosophically, I
> agree.
>
> Changes: org.apache.soap.Fault.marshall() and
> org.apache.soap.Fault.unmarshall() are changed so they marshall and
> unmarshall both Elements and Parameters. If a Parameter cannot be
> marshalled (because a serializer is missing, for instance) then an exception
> stack trace is printed, but does not cause the marshall to fail, since the
> fault can be interpreted (albeit more limitedly) with only the fault code
> and fault string. org.apache.soap.Constants is changed to add one
> additional constant for a tag name for an included parameter, to distinguish
> it from a normal element. org.apache.soap.server.http.RPCRouterServlet is
> modified as follows: if a SOAPException occurs and it contains a target
> exception, RPCRouterServlet will now automatically add the targetException
> (wrapped in a Parameter object) to the detail element of the Fault object
> returned. If this exception cannot be marshalled, an error message will be
> printed, but the fault will still be returned without the exception as
> described above.
>
> API Changes: None. Since all the fault detail entries are stored in a
> Vector, the classes are simply modified to store and understand both
> Elements and Parameters in this Vector.
>
> Backward compatibility: Excellent. If the server is upgraded with this
> patch, but not the client, then the client will simply see the marshalled
> Parameter in the detail element as an Element, which it should ignore
> because it doesn't understand it. If the client is upgraded and not the
> server, then there will be no exception in the detail element, and the
> client will see only Elements in the detail element of a returned fault.
>
> If any more clarification is required (or, hell, if you just want to flame
> me), you may email me personally or, preferably, post it to soap-dev so the
> group may benefit.
>
> Best regards,
> -----
> Eric M. Dashofy <ed...@ics.uci.edu>
> Graduate Student Researcher, Information & Computer Science
> University of California, Irvine
> http://www.ics.uci.edu/~edashofy
>
RE: Patch proposal: Ability to serialize parameters (specifically, exceptions) in a Fault
Posted by "Eric M. Dashofy" <ed...@ics.uci.edu>.
Thanks for the response Sanjiva!
Of course, the ability to send stack traces back over to the client is
useful. However, it's insufficient to implement RPC-with-exceptions over
SOAP. My thinking was, if it's possible to marshal a return value (which
may be a Java type) and return it in the no-failures case, it should be
possible to marshal an exception (which happens in Java, but also C++ and
other languages) and put it in the detail element of a Fault when there's a
failure. Being able to reconstruct the entire server-side exception on the
client is a very important thing, in my opinion, and it's necessary to
emulate the functionality of, say, RMI.
Actually, there are two parts to my patch. One is more Java-specific than
the other.
The first part of the patch changes the marshall() method in the Fault class
to allow both Parameter and org.w3c.dom.Element objects in the detail
Vector. I do not think this is Java-specific, and is the best place for
this to occur. If it's not done here, then I have to somehow serialize the
Parameter into an org.w3c.dom.Element outside of the Fault.marshall()
method. To do this, using the Apache-Java-SOAP serializers, I have to:
1. Create a new StringWriter
2. Get the parameter serializer from the XJMR
3. Serialize the parameter
4. Close the StringWriter
5. Open up a StringReader on the resulting string to read it back.
6. XML-parse the string reader using Xerces or another parser into an
org.w3c.dom.Element
7. Add that element to the Vector.
In the process, I lose some of the valuable contextual variables I have in
Fault.marshall() like inScopeEncStyle and nsStack, and I have to make some
educated guesses about them. I would be able to avoid this entirely if the
serializers could output an Element, but they currently just output to a
Writer. If I could use the serializers and get back an Element, this would
probably be a nonissue.
The second part of the patch is somewhat more Java-specific. It modifies
the RPCRouterServlet so that when an exception is thrown by m.invoke() (and
sent out in an InvocationTargetException), the servlet attempts to serialize
this exception and add it to the detail element automatically. If a
serializer cannot be found for this exception, it is not serialized
(actually, it prints a diagnostic message which I could remove from the
patch if desirable, but that's just cosmetic) and everything goes on as
normal. I would argue that clients written in other languages can ignore
this sub-element, so it's helpful in the Java-to-Java case, but not harmful
in the Java-to-FooLanguage case. Also, if you've got an appropriate
exception deserializer and mapping in FooLanguage, you could deserialize it
there as well.
I hope this clears up my reason for the patch. If anything, I would like to
leave in the changes to Fault because they're a nasty kludge elsewhere, and
it seems like there might be a few of us interested in returning Parameters
in the fault. If you don't want to change RPCRouterServlet to automatically
serialize Java exceptions thrown by the called method, I can understand
this, and the workaround for me is to just copy the code from
RPCRouterServlet, modify it slightly, and use MyRPCRouterServlet instead of
RPCRouterServlet--not a big headache.
Any comments appreciated.
Thanks very much,
--Eric
-----Original Message-----
From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
Sent: Thursday, September 07, 2000 6:41 PM
To: soap-dev@xml.apache.org
Subject: Re: Patch proposal: Ability to serialize parameters
(specifically, exceptions) in a Fault
Hi Eric,
I put some code in to forward stack traces via the detail element ..
it does some of what you posted I think.
I didn't merge your code in because I wasn't certain of its applicability
in non Java-to-Java cases. That is, if the client is in VBScript and
the server is in Java, then sending a serialized exception object does
little good. I admit that I didn't review your code very carefully ..
so I may have gotten an incorrect intuition about it. Please correct if
I'm mistaken, but otherwise I am opposed to putting in special-case code
without some organized way of doing that .. that is, I fully expect
that Java-Java will be a common usecase and in that case it should be
possible to exploit that. I would like to see some generic solution to
the need to enable extensible special-casing.
(Did anyone else check out Eric's patch?)
Sanjiva.
----- Original Message -----
From: "Eric M. Dashofy" <ed...@ics.uci.edu>
To: <so...@xml.apache.org>
Sent: Monday, August 21, 2000 4:26 PM
Subject: Patch proposal: Ability to serialize parameters (specifically,
exceptions) in a Fault
>
> Okay everybody, I've never posted a patch to an Apache product before, so
I
> will probably screw it up this first time. I would RTFM more, but the
> directions at http://xml.apache.org/source.html are a bit sparse; I've
> nonetheless tried to follow them closely :). I am going to post this
> proposal/rationale for the patch, then I'm going to post the patch in a
> formal [PATCH] email separately using the recommended format (diff -u
> file.java.orig file2.java >> patch)
>
> Patch type: Feature enhancement
>
> Description: The patch I'm proposing enhances Apache SOAP for Java 2.0 to
> allow users to include serialized objects, namely Parameters, in the
detail
> element of a SOAP fault. The chief (but not sole) purpose of this is to
> allow SOAP to return a serialized Java exception when an error occurs in
the
> invoked SOAP object. Currently, the only type of object that the API
allows
> in the detail message of a Fault is a DOM Element, which can be used to
> store a marshalled exception, but in a hackish way.
>
> Reason for patch: With this capability in place, it becomes
straightforward
> to implement RPC with Exceptions and build an RMI-like service on top of
> SOAP. Without this capability, the client cannot reconstruct an exception
> that happened on the server, even if it can be marshalled.
>
> Alternatives to the patch: I could have modified the server to include the
> exception in a Response, but in my research, Don Box and others have said
> that errors and exceptions never belong in a Response. Philosophically, I
> agree.
>
> Changes: org.apache.soap.Fault.marshall() and
> org.apache.soap.Fault.unmarshall() are changed so they marshall and
> unmarshall both Elements and Parameters. If a Parameter cannot be
> marshalled (because a serializer is missing, for instance) then an
exception
> stack trace is printed, but does not cause the marshall to fail, since the
> fault can be interpreted (albeit more limitedly) with only the fault code
> and fault string. org.apache.soap.Constants is changed to add one
> additional constant for a tag name for an included parameter, to
distinguish
> it from a normal element. org.apache.soap.server.http.RPCRouterServlet is
> modified as follows: if a SOAPException occurs and it contains a target
> exception, RPCRouterServlet will now automatically add the targetException
> (wrapped in a Parameter object) to the detail element of the Fault object
> returned. If this exception cannot be marshalled, an error message will
be
> printed, but the fault will still be returned without the exception as
> described above.
>
> API Changes: None. Since all the fault detail entries are stored in a
> Vector, the classes are simply modified to store and understand both
> Elements and Parameters in this Vector.
>
> Backward compatibility: Excellent. If the server is upgraded with this
> patch, but not the client, then the client will simply see the marshalled
> Parameter in the detail element as an Element, which it should ignore
> because it doesn't understand it. If the client is upgraded and not the
> server, then there will be no exception in the detail element, and the
> client will see only Elements in the detail element of a returned fault.
>
> If any more clarification is required (or, hell, if you just want to flame
> me), you may email me personally or, preferably, post it to soap-dev so
the
> group may benefit.
>
> Best regards,
> -----
> Eric M. Dashofy <ed...@ics.uci.edu>
> Graduate Student Researcher, Information & Computer Science
> University of California, Irvine
> http://www.ics.uci.edu/~edashofy
>
RE: Patch proposal: Ability to serialize parameters (specifically, exceptions) in a Fault
Posted by "Eric M. Dashofy" <ed...@ics.uci.edu>.
Thanks for the response Sanjiva!
Of course, the ability to send stack traces back over to the client is
useful. However, it's insufficient to implement RPC-with-exceptions over
SOAP. My thinking was, if it's possible to marshal a return value (which
may be a Java type) and return it in the no-failures case, it should be
possible to marshal an exception (which happens in Java, but also C++ and
other languages) and put it in the detail element of a Fault when there's a
failure. Being able to reconstruct the entire server-side exception on the
client is a very important thing, in my opinion, and it's necessary to
emulate the functionality of, say, RMI.
Actually, there are two parts to my patch. One is more Java-specific than
the other.
The first part of the patch changes the marshall() method in the Fault class
to allow both Parameter and org.w3c.dom.Element objects in the detail
Vector. I do not think this is Java-specific, and is the best place for
this to occur. If it's not done here, then I have to somehow serialize the
Parameter into an org.w3c.dom.Element outside of the Fault.marshall()
method. To do this, using the Apache-Java-SOAP serializers, I have to:
1. Create a new StringWriter
2. Get the parameter serializer from the XJMR
3. Serialize the parameter
4. Close the StringWriter
5. Open up a StringReader on the resulting string to read it back.
6. XML-parse the string reader using Xerces or another parser into an
org.w3c.dom.Element
7. Add that element to the Vector.
In the process, I lose some of the valuable contextual variables I have in
Fault.marshall() like inScopeEncStyle and nsStack, and I have to make some
educated guesses about them. I would be able to avoid this entirely if the
serializers could output an Element, but they currently just output to a
Writer. If I could use the serializers and get back an Element, this would
probably be a nonissue.
The second part of the patch is somewhat more Java-specific. It modifies
the RPCRouterServlet so that when an exception is thrown by m.invoke() (and
sent out in an InvocationTargetException), the servlet attempts to serialize
this exception and add it to the detail element automatically. If a
serializer cannot be found for this exception, it is not serialized
(actually, it prints a diagnostic message which I could remove from the
patch if desirable, but that's just cosmetic) and everything goes on as
normal. I would argue that clients written in other languages can ignore
this sub-element, so it's helpful in the Java-to-Java case, but not harmful
in the Java-to-FooLanguage case. Also, if you've got an appropriate
exception deserializer and mapping in FooLanguage, you could deserialize it
there as well.
I hope this clears up my reason for the patch. If anything, I would like to
leave in the changes to Fault because they're a nasty kludge elsewhere, and
it seems like there might be a few of us interested in returning Parameters
in the fault. If you don't want to change RPCRouterServlet to automatically
serialize Java exceptions thrown by the called method, I can understand
this, and the workaround for me is to just copy the code from
RPCRouterServlet, modify it slightly, and use MyRPCRouterServlet instead of
RPCRouterServlet--not a big headache.
Any comments appreciated.
Thanks very much,
--Eric
-----Original Message-----
From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
Sent: Thursday, September 07, 2000 6:41 PM
To: soap-dev@xml.apache.org
Subject: Re: Patch proposal: Ability to serialize parameters
(specifically, exceptions) in a Fault
Hi Eric,
I put some code in to forward stack traces via the detail element ..
it does some of what you posted I think.
I didn't merge your code in because I wasn't certain of its applicability
in non Java-to-Java cases. That is, if the client is in VBScript and
the server is in Java, then sending a serialized exception object does
little good. I admit that I didn't review your code very carefully ..
so I may have gotten an incorrect intuition about it. Please correct if
I'm mistaken, but otherwise I am opposed to putting in special-case code
without some organized way of doing that .. that is, I fully expect
that Java-Java will be a common usecase and in that case it should be
possible to exploit that. I would like to see some generic solution to
the need to enable extensible special-casing.
(Did anyone else check out Eric's patch?)
Sanjiva.
----- Original Message -----
From: "Eric M. Dashofy" <ed...@ics.uci.edu>
To: <so...@xml.apache.org>
Sent: Monday, August 21, 2000 4:26 PM
Subject: Patch proposal: Ability to serialize parameters (specifically,
exceptions) in a Fault
>
> Okay everybody, I've never posted a patch to an Apache product before, so
I
> will probably screw it up this first time. I would RTFM more, but the
> directions at http://xml.apache.org/source.html are a bit sparse; I've
> nonetheless tried to follow them closely :). I am going to post this
> proposal/rationale for the patch, then I'm going to post the patch in a
> formal [PATCH] email separately using the recommended format (diff -u
> file.java.orig file2.java >> patch)
>
> Patch type: Feature enhancement
>
> Description: The patch I'm proposing enhances Apache SOAP for Java 2.0 to
> allow users to include serialized objects, namely Parameters, in the
detail
> element of a SOAP fault. The chief (but not sole) purpose of this is to
> allow SOAP to return a serialized Java exception when an error occurs in
the
> invoked SOAP object. Currently, the only type of object that the API
allows
> in the detail message of a Fault is a DOM Element, which can be used to
> store a marshalled exception, but in a hackish way.
>
> Reason for patch: With this capability in place, it becomes
straightforward
> to implement RPC with Exceptions and build an RMI-like service on top of
> SOAP. Without this capability, the client cannot reconstruct an exception
> that happened on the server, even if it can be marshalled.
>
> Alternatives to the patch: I could have modified the server to include the
> exception in a Response, but in my research, Don Box and others have said
> that errors and exceptions never belong in a Response. Philosophically, I
> agree.
>
> Changes: org.apache.soap.Fault.marshall() and
> org.apache.soap.Fault.unmarshall() are changed so they marshall and
> unmarshall both Elements and Parameters. If a Parameter cannot be
> marshalled (because a serializer is missing, for instance) then an
exception
> stack trace is printed, but does not cause the marshall to fail, since the
> fault can be interpreted (albeit more limitedly) with only the fault code
> and fault string. org.apache.soap.Constants is changed to add one
> additional constant for a tag name for an included parameter, to
distinguish
> it from a normal element. org.apache.soap.server.http.RPCRouterServlet is
> modified as follows: if a SOAPException occurs and it contains a target
> exception, RPCRouterServlet will now automatically add the targetException
> (wrapped in a Parameter object) to the detail element of the Fault object
> returned. If this exception cannot be marshalled, an error message will
be
> printed, but the fault will still be returned without the exception as
> described above.
>
> API Changes: None. Since all the fault detail entries are stored in a
> Vector, the classes are simply modified to store and understand both
> Elements and Parameters in this Vector.
>
> Backward compatibility: Excellent. If the server is upgraded with this
> patch, but not the client, then the client will simply see the marshalled
> Parameter in the detail element as an Element, which it should ignore
> because it doesn't understand it. If the client is upgraded and not the
> server, then there will be no exception in the detail element, and the
> client will see only Elements in the detail element of a returned fault.
>
> If any more clarification is required (or, hell, if you just want to flame
> me), you may email me personally or, preferably, post it to soap-dev so
the
> group may benefit.
>
> Best regards,
> -----
> Eric M. Dashofy <ed...@ics.uci.edu>
> Graduate Student Researcher, Information & Computer Science
> University of California, Irvine
> http://www.ics.uci.edu/~edashofy
>