Re: cvs commit: xml-soap/java/src/org/apache/soap/server MessageRouter.java

[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.