There are two separate issues here. The first is what is being returned from the server side. The servlet invoker is very basic in that is it just sends a simple 500 error back to the client. The http invoker is a little better in that while still setting the response status to 500, will also send the exception object as well back to the client.
On the client side (which uses the http client invoker for both servlet and http server invoker), if the response code received is >= 400, will read the error stream instead of the input stream. The object returned from reading the stream will be the one returned to the Client.invoke() call (along with all the headers, including response code, in the metadata map passed in the invoke() call).
The reason the execption is returned instead of being thrown was that the web services team needed to be able to process it this way (will see if can get a comment from one of them on exactly why they needed this as can't remember off hand).
So, see two possible changes that could be made. First is to make the servlet invoker better about returning server side exception (like is done with the http server invoker). The second is to make it configurable as to if exception should be thrown or returned on Client.invoke() call.
are there any news about this issue? Are there plans to make modifications in servlet invoker as you mentioned?
Thanks in advance,
I like the idea of having it configurable - let the web services team configure theirs so it returns the exception, let me configure it so it will throw the exception :-)
I just learned that a recent change now means invoke doesn't return an exception object, instead it returns a String (correct Tom?).
I don't like this. You have no notion that this is really an error. At the very least, if I can't get the exception thrown, I would prefer the object returned by invoke to be an Exception - its getMessage() can return that String that is returned now.
Wrapping in an Exception means at least my caller to invoke will know that a true exception occurred. The stuff I'm working on, I want to use remoting's great feature of just being able to switch transports (in the invoker locator) and have a completely different transport mechanism used. My code never really knows what transport is being used - the customer just configures the locator URL in a config file to what they want to and *poof* they get what they want. If you force me to look at the HTTP return code, that requires my code to assume I am using a servlet or http transport. But that isn't always true. Looking at the return value of invoke() and seeing if it is instanceof Exception is acceptable in my usecase (of course, having an exception getting thrown would be ideal).
So now http(s) and servlet(sslservlet) will now throw exception by default, just like other transports. Can be configured to not throw exception (like was in past) as well.
Still need web services team to confirm changes are alright with them (since they requested the initial no throw).
This sounds like a perfect solution for everyone.