GWTRPCServiceExporter and HandlerInterceptors

[David Durham]

Hi all,

I've got a handler interceptor defined for a GWT service that I'm
exporting with GWTRPCServiceExporter. The issue I'm seeing is that
GWTRPCServiceExporter is not allowing an exception to escape to my
HandlerInterceptor. Looking through the source code for the service
exporter from svn, it looks like processCall is throwing a
RuntimeException. I think the class in svn is different from what I
have 1.5b, though. Can you confirm that this is an issue you fixed
and that I should build from svn if I want to see exceptions make it
out of service exporter.

Thanks,
Dave

[David Durham]

On Fri, Apr 24, 2009 at 1:27 PM, David Durham <david.d...@gmail.com> wrote:
> Hi all,
>
> I've got a handler interceptor defined for a GWT service that I'm
> exporting with GWTRPCServiceExporter.  The issue I'm seeing is that
> GWTRPCServiceExporter is not allowing an exception to escape to my
> HandlerInterceptor.

So, I actually looked at the 1.5 branch code and I see that it also
throws a runtime exception. Stepping through with a debugger it now
appears to me that maybe the gwt RemoteServiceServlet is actually
catching the error and not allowing it to escape the doPost method.

Anyone ran into this one?

[George Georgovassilis]

Hello David,

the GWTRPCServiceExporter handles all exceptions that occur >inside<
the service. The reason is that the RPC contract allows exceptions from
the service to be serialised across the wire and be thrown back to the
client. For instance, imagine that you would like to throw back a
particular ValidationException with messages for the user.

If you wrap your advice around the service rather than the service
exporter you'll be able to intercept that exception.

--~--~----~
You received this message because you are subscribed to the Google Groups "gwt-sl" group.
To post to this group, send email to gwt...@googlegroups.com
To unsubscribe from this group, send email to gwt-sl+un...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/gwt-sl?hl=en-GB
-~----------~----~----~----~------~----~------~--~---

</pre>
</blockquote>
<br>
</body>
</html>

[David Durham]

Ok, more investigation.

I think that gwt service exporter should have this method:

protected void doUnexpectedFailure(Throwable e) throws Throwable {
super.doUnexpectedFailure(e);
throw e;
}

Reasoning is this:

The RemoteServiceServlet.doPost() catches Throwable and hands that off to:

protected void doUnexpectedFailure(Throwable e) {
ServletContext servletContext = getServletContext();
RPCServletUtils.writeResponseForUnexpectedFailure(servletContext,
getThreadLocalResponse(), e);
}

which has the following javadocs comment:

/**
* Override this method to control what should happen when an exception
* escapes the {@link #processCall(String)} method. The default implementation
* will log the failure and send a generic failure response to the client.<p/>
*
* An "expected failure" is an exception thrown by a service method that is
* declared in the signature of the service method. These exceptions are
* serialized back to the client, and are not passed to this method. This
* method is called only for exceptions or errors that are not part of the
* service method's signature, or that result from SecurityExceptions,
* SerializationExceptions, or other failures within the RPC framework.<p/>
*
* Note that if the desired behavior is to both send the GENERIC_FAILURE_MSG
* response AND to rethrow the exception, then this method should first send
* the GENERIC_FAILURE_MSG response itself (using getThreadLocalResponse), and
* then rethrow the exception. Rethrowing the exception will cause it to
* escape into the servlet container.
*
* @param e the exception which was thrown
*/

Sound right?

-Dave

[David Durham]

On Fri, Apr 24, 2009 at 1:56 PM, George Georgovassilis
<g.georgo...@gmail.com> wrote:
>
> Hello David,
>
> the GWTRPCServiceExporter handles all exceptions that occur  >inside<
> the service. The reason is that the RPC contract allows exceptions from
> the service to be serialised across the wire and be thrown back to the
> client. For instance, imagine that you would like to throw back a
> particular ValidationException with messages for the user.
>
> If you wrap your advice around the service rather than the service
> exporter you'll be able to intercept that exception.

Thanks. Please see my previous message about: protected void
doUnexpectedFailure(Throwable e)

I'm actually not using advice. The Spring handler interceptor
provides an easy way to get at the exception and the request and
response, so I'd like to use that or at least have the option to do
so. What do you think about the doUnexpectedFailure() idea?

[David Durham]

>  protected void doUnexpectedFailure(Throwable e) throws Throwable {
>         super.doUnexpectedFailure(e);
>         throw e;
>  }

Should be:

protected void doUnexpectedFailure(Throwable e) {
super.doUnexpectedFailure(e);
throw new RuntimeExcpetion(e);
}

[David Durham]

I tested this, and it works.

[David Durham]

>> Should be:
>>
>>  protected void doUnexpectedFailure(Throwable e) {
>>         super.doUnexpectedFailure(e);
>>         throw new RuntimeExcpetion(e);
>>  }
>>
>
> I tested this, and it works.

George, you didn't respond to this. Is it something you're interested
in adding? I can generate a patch if you'd like.

[George Georgovassilis]

Hi David,

sorry for the late answer. It's a good catch and it will definitely go
into the next release, most likely with a switch to toggle this behaviour.

[David Durham]

On Tue, Apr 28, 2009 at 1:21 AM, George Georgovassilis
<g.georgo...@gmail.com> wrote:
>
> Hi David,
>
> sorry for the late answer. It's a good catch and it will definitely go
> into the next release, most likely with a switch to toggle this behaviour.

Good call.

-Dave