Grails - Exception when stopping/cancelling an upload - exception

I have a very basic upload action in my controller. It looks something like the action below. It works great. The only problem I'm seeing is when a user cancels an upload (or hits stop on their browser). I am able to recover correctly, but not before seeing an uncaught exception in my logs. The exception is listed below. Any help or feedback on how to correctly catch the uncaught exception here would be appreciated. Seems like it's happening somewhere between the client and the controller action since the exception is being displayed but none of the log messages in the action are showing up.
def upload = {
def f = null
try {
f = request.getFile('assetFile')
if(!f || f.empty) {
log.warn "File is empty"
render(view:'upload')
return
}
} catch (Exception e) {
log.warn "Caught exception:", e
render(view:'upload')
return
}
}
Exception is:
2010-08-06 15:33:22,826 ERROR [TP-Processor8] filter.UrlMappingsFilter - Error when matching URL mapping [/(*)/(*)?/(*)?]:Could not parse multipart servlet request; nested exception is org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. Stream ended unexpectedly
org.springframework.web.multipart.MultipartException: Could not parse multipart servlet request; nested exception is org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. Stream ended unexpectedly
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.jsecurity.web.servlet.JSecurityFilter.doFilterInternal(JSecurityFilter.java:384)
at org.jsecurity.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:183)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:200)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:775)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:704)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:897)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
at java.lang.Thread.run(Thread.java:619)
Caused by: org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. Stream ended unexpectedly
at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:367)
at org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(ServletFileUpload.java:126)
... 25 more
Caused by: org.apache.commons.fileupload.MultipartStream$MalformedStreamException: Stream ended unexpectedly
at org.apache.commons.fileupload.MultipartStream$ItemInputStream.makeAvailable(MultipartStream.java:983)
at org.apache.commons.fileupload.MultipartStream$ItemInputStream.read(MultipartStream.java:887)
at java.io.InputStream.read(InputStream.java:85)
at org.apache.commons.fileupload.util.Streams.copy(Streams.java:94)
at org.apache.commons.fileupload.util.Streams.copy(Streams.java:64)
at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:362)
... 26 more

I'm terribly late on this, but I just ran into the same problem today and resolved it by adding a servlet filter (I also tried a Grails filter, but the exception is thrown prior to hitting it).
First you need to create a web.xml in your project...
grails install-templates
Add a filter to web.xml (make sure not to put the filter-mapping before any other filters)...
<filter>
<filter-name>upload</filter-name>
<filter-class>com.myProject.UploadFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>upload</filter-name>
<url-pattern>/media/uploadMediaAsset/*</url-pattern>
</filter-mapping>
Create the filter class...
package com.myProject
import javax.servlet.*
import org.apache.commons.logging.Log
import org.apache.commons.logging.LogFactory
import org.springframework.web.multipart.MultipartException
public class UploadFilter implements Filter {
private Log log = LogFactory.getLog(getClass())
public void init(FilterConfig filterConfig) throws ServletException { /* Do nothing */ }
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws java.io.IOException, ServletException {
log.debug 'Making sure file upload gets here.'
try {
chain.doFilter(request, response)
} catch (MultipartException mpE) {
log.error mpE
}
}
public void destroy() { /* Do nothing */ }
}

Late response. I was actually able to find the solution for anyone still working on this problem. See http://brainflush.wordpress.com/2008/12/04/how-to-gracefully-recover-from-file-upload-errors-in-grails/.

Related

How should "Connection reset by peer" be handled in Netty?

A "side effect" of using Netty is that you need to handle stuff you never thought about, like sockets closing and connection resets. A recurring theme is having your logs stuffed full of java.lang.IOException: Connection reset by peer.
What I am wondering about is how to handle these "correctly" from a web server perspective. AFAIK, this error simply means the other side has closed its socket (for instance, if reloading the web page or similar) while a request was sent to the server.
This is how we currently handle exceptions happening in our pipeline (I think it does not make full sense):
s, not the handler I have attached to the end of the pipeline.
current setup
pipeline.addLast(
new HttpServerCodec(),
new HttpObjectAggregator(MAX_CONTENT_LENGTH),
new HttpChunkContentCompressor(),
new ChunkedWriteHandler()
// lots of handlers
// ...
new InterruptingExceptionHandler()
);
pipeline.addFirst(new OutboundExceptionRouter());
the handler of exceptions
private class InterruptingExceptionHandler extends ChannelInboundHandlerAdapter {
#Override
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) {
final var id = ctx.channel().id();
// This needs to ge before the next section as the interrupt handler might shutdown the server before
// we are able to notify the client of the error
ctx.writeAndFlush(serverErrorJSON("A server error happened. Examine the logs for channel id " + id));
if (cause instanceof Error) {
logger.error(format("Error caught at end of pipeline in channel %s, interrupting!", id), cause);
ApplicationPipelineInitializer.this.serverInterruptHook.run();
} else {
logger.error(format("Uncaught user land exception in channel %s for request %s: ", id, requestId(ctx)), cause);
}
}
If some exception, like the IOException, is thrown we try and write a response back. In the case of a closed socket, this will then fail, right? So I guess we should try and detect "connection reset by peer" somehow and just ignore the exception silently to avoid triggering a new issue by writing to a closed socket ... If so, how? Should I try and do err instanceof IOException and err.message.equals("Connection reset by peer") or are there more elegant solutions? To me, it seems like this should be handled by some handler further down in the stack, closer to the HTTP handler
If you wonder about the OutboundExceptionRouter:
/**
* This is the first outbound handler invoked in the pipeline. What it does is add a listener to the
* outbound write promise which will execute future.channel().pipeline().fireExceptionCaught(future.cause())
* when the promise fails.
* The fireExceptionCaught method propagates the exception through the pipeline in the INBOUND direction,
* eventually reaching the ExceptionHandler.
*/
private class OutboundExceptionRouter extends ChannelOutboundHandlerAdapter {
#Override
public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) throws Exception {
promise.addListener(ChannelFutureListener.FIRE_EXCEPTION_ON_FAILURE);
super.write(ctx, msg, promise);
}
}

JSP Loading Incompletely on Websphere Application Server 8.5

I am planning to migrate from Websphere Application Server (WAS) 7 to version 8.5. I have deployed an application which runs fine on WAS 7 and I have not made any changes to it since migration.
However, on WAS 8.5, the JSP pages are not being getting loaded completely. When I examine these pages through "View Source," I can see that the HTML content is only half-loaded. Specifically, the HTML itself is not completed with closing tags.
In WAS 7, the result of "View Source" looks like this:
<html>
...
...
<td..../>
<td..../>
<td..../>
...
...
</html>
But the same in WAS 8.5 looks like:
<html>
...
...
<td..../>
<td..../>
<td..
I have done the following so far:
I compared the class files of compiled JSP on WAS 7 and WAS 8.5. They are almost same, so I assume that the compilation is done properly. However, displaying the page with in HTML is not getting done properly.
I tried enabling JavaScript debugging on IE, but it did not show any errors while loading.
There are no errors in application logs and server logs that I can see.
My questions:
The set of <td> tags above is generated through JSP custom tags. Should I check code of the tags?
Is there any Custom property in Web Container Settings in Websphere which control such behaviour?
Is there any timeout property which is causing page to stop loading half-way?
Please suggest what else should I check.
this is a well known behavior that happens when an Exception is thrown and Response has already been commited.
generally the exception is logged, but in some particular case it is not.
i read you workarounded removing EncodingFilter, but if you still want to find the problem you can try to code a Filter, that must be executed BEFORE EncodingFilter, wich sets response.setBufferSize to a larger size.
this can be such a filter:
public class ResponseBufferFilter implements Filter
{
private FilterConfig filterConfig;
#Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException
{
try
{
// or better take the value from filterConfig.getInitParameter
response.setBufferSize(100000000);
chain.doFilter(request, response);
}
catch(Exception e)
{
e.printStackTrace();
throw new ServletException(e.getMessage(), e);
}
}
#Override
public void init(FilterConfig filterConfig) throws ServletException
{
this.filterConfig = filterConfig;
}
#Override
public void destroy()
{
filterConfig = null;
}
}
and this is the mapping:
<filter>
<filter-name>Response Buffer Filter</filter-name>
<filter-class>test.example.filter.ResponseBufferFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>Response Buffer Filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter>
<filter-name>SetCharacterEncoding</filter-name>
<!-- provide the class causing unwanted behavior -->
<filter-class>org.apache.catalina.filters.SetCharacterEncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>SetCharacterEncoding</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
this will not solve the problem, but at least it should allow log of exception, one way or another, if any.

Consuming JSON with Jersey 2.3 throws XML exception

I'm trying to make Jersey 2.3 + Moxy work with my custom objects. Everything is ok when I'm producing JSON from those objects, but refuses to work when I want to consume them by POST. Code first:
Custom object:
#XmlRootElement
public class ContentAction extends Action {
private String contentType;
private Integer contentLength;
public ContentAction() {
setType(ActionType.CONTENT);
}
public String getContentType() {
return contentType;
}
public void setContentType(String contentType) {
this.contentType = contentType;
}
public Integer getContentLength() {
return contentLength;
}
public void setContentLength(Integer contentLength) {
this.contentLength = contentLength;
}
}
Resource fragment (path is declared on the class):
#POST
#Produces(JsonHelper.JSON_UTF8)
public Action saveAction(#QueryParam("action") ContentAction action) throws IOException {
ActionEntity entity = actionConverter.toEntity(action);
entity.setBeacon(beaconService.findById(action.getBeacon().getId()));
return actionConverter.convert(actionService.save(entity));
}
API caller (class responsible for sending requests):
URI uri = buildUri(path, params);
HttpPost httpPost = new HttpPost(uri);
httpClient.execute(httpPost);
buildUri simply creates URI from address & parameters
The action is converted to JSON as follows: mapper.writeValueAsString(action)
And the exception:
org.glassfish.jersey.server.internal.inject.ExtractorException: Error unmarshalling JAXB object of type "class com.kontakt.platform.apicommon.model.ContentAction".
at org.glassfish.jersey.server.internal.inject.JaxbStringReaderProvider$RootElementProvider$1.fromString(JaxbStringReaderProvider.java:195)
at org.glassfish.jersey.server.internal.inject.AbstractParamValueExtractor.convert(AbstractParamValueExtractor.java:138)
at org.glassfish.jersey.server.internal.inject.AbstractParamValueExtractor.fromString(AbstractParamValueExtractor.java:129)
at org.glassfish.jersey.server.internal.inject.SingleValueExtractor.extract(SingleValueExtractor.java:83)
at org.glassfish.jersey.server.internal.inject.QueryParamValueFactoryProvider$QueryParamValueFactory.provide(QueryParamValueFactoryProvider.java:88)
at org.glassfish.jersey.server.spi.internal.ParameterValueHelper.getParameterValues(ParameterValueHelper.java:81)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$AbstractMethodParamInvoker.getParamValues(JavaResourceMethodDispatcherProvider.java:121)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$TypeOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:195)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:104)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:353)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:343)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:255)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:318)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:235)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:983)
at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:359)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:372)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:335)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:218)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1008)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:1852)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
Caused by: javax.xml.bind.UnmarshalException
- with linked exception:
[org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 1; Content is not allowed in prolog.]
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.createUnmarshalException(AbstractUnmarshallerImpl.java:335)
at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.createUnmarshalException(UnmarshallerImpl.java:512)
at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:209)
at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:175)
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:140)
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:123)
at org.glassfish.jersey.server.internal.inject.JaxbStringReaderProvider$RootElementProvider$1.fromString(JaxbStringReaderProvider.java:190)
... 40 more
Caused by: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 1; Content is not allowed in prolog.
at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:198)
at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:177)
at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:441)
at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:368)
at com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1388)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:998)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:607)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:116)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:489)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:835)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:123)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1210)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:568)
at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:203)
... 44 more
When I remove #XmlRootElement, Jersey tries to create object from constructor with string parameter (if added) = no automatic bean creation.
I've been stuck with this for two days and I'd be very grateful for any help.
I think the problem is that you need to set the content type. Since you are not specifying the content type, jersey is assuming it is reciving xml but it is in fact json. The error message is from jaxb trying to read the xml header and finding invalid characters. Try using the jersey client instead of an http post. Also I think you might what to change your #Produces(MediaType.APPLICATION_JSON) for consistency.
#Produces(MediaType.APPLICATION_JSON)
Example POST CODE
The most important part is that I am setting the type (type(MediaType.Application_JSON) that I am going to post.
WebResource webResource = createRestClient(true).resource(
REST_BASE_PATH + "/service");
ClientResponse response = webResource.type(MediaType.APPLICATION_JSON)
.accept(MediaType.APPLICATION_JSON)
.post(ClientResponse.class, contentActionObject);
Assert.assertTrue(response.getStatus() == 200);
If you do need to use the HttpPost object then there should be a configuration option to set http headers. I have done this using the the HttpUrlConnection. You would have to set your content type to be application/json instead of xml.
HttpURLConnection connection = null;
connection = (HttpURLConnection) new URL(requestUrl).openConnection();
connection.setRequestMethod("GET");
connection.setRequestProperty("Accept", "application/xml");
connection.setRequestProperty("Content-Type", "application/xml");
EclipseLink MOXy will be picked up as the JSON-binding provder by Jersey for media types that follow the following pattern.
*/json (i.e. application/json and text/json)
/+json
Based on your exception it appears as though the media type have have represented with JsonHelper.JSON_UTF8 does not match this pattern.
I know this is a little old, but I have been encountering the essentially the identical issue using Jersey 2.3 + Moxy. Same scenario and the identical exception is occurring. The only difference is that my POST method is annotated with:
#Produces(MediaType.APPLICATION_JSON)
#Consumes(MediaType.APPLICATION_JSON)
I did find that when if I passed the same JSON representation in the request body instead of as a query parameter that it was unmarshalled successfully. This would require changing your POST method declaration to:
public Action saveAction(ContentAction action)
Not sure if this would be a work around for you. If you found a resolution I would be interested in hearing what it was.

Jetty and JUnit - sending stub responses over http

I need to send a stub response over http to a requesting client from Jetty. It works when I run the Junit test independently, implies, I get the correct XML response .. but it fails when I run the same thing from maven. The error I see is "java.net.SocketException: Unexpected end of file from server". I have tried everything! Please help!
Here's my code -
Junit (when run as a Junit test - it works)
public class MyTest {
#Test
public void testGetOpenLots() throws Exception {
// create fixture
MyService fixture = new MyService();
// create jetty server instance
Server server = new Server(8080);
// set a handler
server.setHandler(new HelloHandler());
// set shutdown conditions
// server.setStopAtShutdown(true);
// start server
server.start();
// invoke operation
MyResponse result = fixture.getWeather(someDummyRequest);
assertNotNull(result);
}
}
Somewhere down the line, inside getWeather(), I create a URL object and pass the URL http://localhost:8080 to it and send the request to that URL. At this point, I expect that the HelloHandler's handle method will get invoked and will write this dummy XML response to stream and getWeather() method will receive the response.
Here's the handler:
public class HelloHandler extends AbstractHandler {
public void handle(String target, Request baseRequest,
HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException {
response.setContentType("application/xml;charset=utf-8");
response.setStatus(HttpServletResponse.SC_OK);
baseRequest.setHandled(true);
response.getWriter().println("<result>a simple response</result>");
}
}
When I run the same thing from maven, it throws the error mentioned above. What am I doing wrong?
Instead of implementing your own jetty handler you can try Jadler (http://jadler.net), an http stubbing/mocking library I've been working on for a while.

Using ServiceStack unhandled exception behavior

I would like to get automatic exception serialization without manually adding ResponseStatus to the response DTO.
Based on this info on unhandled exception behavior I wrote the following code
public class ContactService : RestServiceBase<Contact>
{
public override object OnGet(Contact request)
{
return ContactApi.GetContactInfo(request);
}
//To trigger the serialization of the Exception to ResponseStatus
protected override object HandleException(Contact request, Exception ex)
{
throw ex;
}
<snip />
}
Do you see any issues with using the library in this manner?
Thanks in advance.
UPDATE: I would like to get the following response when there is an exception without having to add ResponseStatus property to my response DTO object.
I am able to achieve this with by overriding the HandleException method as shown above.
My question is:
Can overriding the default exception handling behavior in this manner cause any problems down the road?
{
"ResponseStatus":{
"ErrorCode":"ApplicationException",
"Message":"CRASH",
}
}