RE: Patch proposal: Ability to serialize parameters (specifically , exceptions) in a Fault

[Glen Daniels <gd...@allaire.com>]

+1 from me too.  Finally got around to reading it last night.

To Sanjiva's language-specificity concern, I agree with Eric.  Because we
can define specific exception serializers/deserializers, we're really able
to do service-specific encodings of this type of information, not so much
language-specific ones.

To Kevin's first point, that's just what Eric's patch does, it just wraps
the "arbitrary objects" in Parameters, so you can explicitly name the XML
elements in which they will be serialized (in this case it's always
<target>).

I don't think this approach as it stands is quite flexible enough - we do
want some kind of service-specific way of mapping exceptional conditions to
particular Fault <detail> elements, without having to lock exceptions to the
<target> element.  For now, it's a good start and gets us the ability to
actually throw meaningful typed exceptions on the client side.  As we
rearchitect for 3.0, we should definitely focus on this issue and design a
more general framework for it.

--Glen

> -----Original Message-----
> From: Kevin Mitchell [mailto:kevin.mitchell@xmls.com]
> Sent: Friday, September 08, 2000 9:14 AM
> To: 'soap-dev@xml.apache.org'
> Subject: RE: Patch proposal: Ability to serialize parameters
> (specifically , exceptions) in a Fault
> 
> 
> +1 on this patch...
> 
> My thought is both parts of this patch should go in.  I implemented
> something very much like this and found it to be very useful. 
> There was one
> difference: instead of supporting marshalling of only 
> Parameter objects in
> Fault.marshall, I ran each element of the detail vector thru 
> the supplied
> mapping registry; basically this allows any object to be 
> placed as a Fault
> detail (as long as the object has a registered serializer) If the
> serialization fails, I fell back to the original method of 
> seeing if the
> object is an Element, and then serializing it.
> 
> Another approach would be to allow one to register a "Fault 
> handler" with
> the RPCRouterServlet (thru a servlet init property, or 
> perhaps better the
> DeploymentDescriptor). The handler would be responsible for
> producing/adorning a Fault object, given some objects from 
> the servlet (the
> Exception thrown, the Call, etc...). This would give one full 
> control over
> the Fault returned, including not supplying exception data as a detail
> element at all.
> 
> 
> ~kjm
> 
> -----Original Message-----
> From: Eric M. Dashofy [mailto:edashofy@ics.uci.edu]
> Sent: Thursday, September 07, 2000 10:09 PM
> To: soap-dev@xml.apache.org
> Subject: RE: Patch proposal: Ability to serialize parameters
> (specifically, exceptions) in a Fault
> 
> 
> 
> 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
> >
>