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 RP Johns <rj...@vignette.com> on 2001/05/22 15:18:12 UTC
Re: cvs commit: xml-soap/java/src/org/apache/soap/server
MessageRouter.java
This set of changes to the exception message handling breaks something
I was taking advantage of. Here's how I was using the message part of an exception:
When an exception is thrown by a service class,
that exception is serialized into an xml string. When it gets to the client side,
the serialized exception string is translated back into an instance of the exception and
thrown where it is caught by a client side proxy. A client side proxy is paired with a service
class to form a
single logical entity whereby exceptions can be thrown on the service side and caught on the client
side.
With the changes just made, I now have things
like: "Exception from service object: " prepended to the serialized exception.
Is there a way we can preserve the t.getMessage() semantic? The idea being that
the service class Throwable's message might be playing a meaningful role and
should be left alone.
thanks.
sanjiva@apache.org wrote:
> sanjiva 01/05/21 19:18:46
>
> Modified: java/src/org/apache/soap/server MessageRouter.java
> Log:
> improved error messages
>
> Revision Changes Path
> 1.6 +6 -4 xml-soap/java/src/org/apache/soap/server/MessageRouter.java
>
> Index: MessageRouter.java
> ===================================================================
> RCS file: /home/cvs/xml-soap/java/src/org/apache/soap/server/MessageRouter.java,v
> retrieving revision 1.5
> retrieving revision 1.6
> diff -u -r1.5 -r1.6
> --- MessageRouter.java 2001/05/18 14:00:58 1.5
> +++ MessageRouter.java 2001/05/22 02:18:44 1.6
> @@ -74,15 +74,17 @@
> throw (SOAPException)t;
> } else {
> throw new SOAPException(Constants.FAULT_CODE_SERVER,
> - t.getMessage (),
> - t);
> + "Exception from service object: " +
> + t.getMessage (), t);
> }
> } catch (ClassNotFoundException e) {
> throw new SOAPException (Constants.FAULT_CODE_SERVER,
> "Unable to load BSF: script services " +
> - "unsupported with BSF", e);
> + "unsupported without BSF", e);
> } catch (Throwable t) {
> - throw new SOAPException (Constants.FAULT_CODE_SERVER, t.getMessage(), t);
> + throw new SOAPException (Constants.FAULT_CODE_SERVER,
> + "Exception while handling service request: " +
> + t.getMessage(), t);
> }
> }
> }
>
>
>
Re: cvs commit: xml-soap/java/src/org/apache/soap/server
MessageRouter.java
Posted by RP Johns <rj...@vignette.com>.
Sanjiva, thanks for taking time to consider this. See in line comments:
Sanjiva Weerawarana wrote:
> > This set of changes to the exception message handling breaks something
> > I was taking advantage of. Here's how I was using the message part of an
> exception:
> >
> > When an exception is thrown by a service class,
> > that exception is serialized into an xml string. When it gets to the
> client side,
> > the serialized exception string is translated back into an instance of
> the exception and
> > thrown where it is caught by a client side proxy. A client side proxy is
> paired with a service
> > class to form a
> > single logical entity whereby exceptions can be thrown on the service
> side and caught on the client
> > side.
>
> I see what you're doing but that's not very safe .. first it depends
> on this thing that I broke and also it depends on having the same
> class files on both ends. That doesn't seem portable at all.
First of we code generate client and server side proxies. The proxy layer
has base class support for translating the exceptions serialized to xml.
If the client side proxy cannot reconstitute the actual Exception class,
then we are no worse off than a SOAPExceptions Fault.getFaultString().
So, if the client proxy is not used, for example, say a MS appbuilder tool
grabs the wsdl for the service, and builds it's own client side proxy,
then all it needs to do is handle the serialized xml exception, ie., translate it
into some language specific object -- or at a minimum display it as xml,
which is only a tad bit less readable than an exception's getMessage().
>
>
> > With the changes just made, I now have things
> > like: "Exception from service object: " prepended to the serialized
> exception.
>
> I put those because the exceptions were often pretty meaningless
> without that bit of context. I saw things like "Connection" coming
> out and that just doesn't tell the user anything about where it
> went wrong.
>
> > Is there a way we can preserve the t.getMessage() semantic? The idea being
> that
> > the service class Throwable's message might be playing a meaningful role
> and
> > should be left alone.
>
> I'm not sure how we can do both .. do you have any thoughts?
>
Well..., how about making the fault codes more specific. You would have
one for each distinguishing origin of the exception. The client
would have to get the fault code and compare it against a known
set of constants to gain more insight.
with a little more effort ...
The Fault object could have an additional method called getOriginalFaultString();
or, you could do it the other way and retain getFaultString() to do what it always
did, and add another method called getVerboseFaultString() which would decode
the fault code itself and prepend the same message you have added in your patches
to the original message. This gives the client the choice to get a clearer picture
should they want it, while allowing the original message of the exception to have
some application specific semantic.
I think SOAP clients in general will be very capable of handling xml so this
seems like a reasonable way to transmit exceptions from the server side
to the client side. Even in the case where the client is not a java client,
it will need to have some understanding of the exceptions of the service
it is using, so xml represents the best, most portable way to communicate them.
>
> If there's no way to do both I'm inclined to keeping the currently
> committed version with better error messages.
I hope we can work something out, because I'd very much prefer not
to have to add custom hacks.
>
>
> Sanjiva.
Again I thank you for your time.
Re: cvs commit: xml-soap/java/src/org/apache/soap/server MessageRouter.java
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
> This set of changes to the exception message handling breaks something
> I was taking advantage of. Here's how I was using the message part of an
exception:
>
> When an exception is thrown by a service class,
> that exception is serialized into an xml string. When it gets to the
client side,
> the serialized exception string is translated back into an instance of
the exception and
> thrown where it is caught by a client side proxy. A client side proxy is
paired with a service
> class to form a
> single logical entity whereby exceptions can be thrown on the service
side and caught on the client
> side.
I see what you're doing but that's not very safe .. first it depends
on this thing that I broke and also it depends on having the same
class files on both ends. That doesn't seem portable at all.
> With the changes just made, I now have things
> like: "Exception from service object: " prepended to the serialized
exception.
I put those because the exceptions were often pretty meaningless
without that bit of context. I saw things like "Connection" coming
out and that just doesn't tell the user anything about where it
went wrong.
> Is there a way we can preserve the t.getMessage() semantic? The idea being
that
> the service class Throwable's message might be playing a meaningful role
and
> should be left alone.
I'm not sure how we can do both .. do you have any thoughts?
If there's no way to do both I'm inclined to keeping the currently
committed version with better error messages.
Sanjiva.