Improve error handling for Jersey's Exception that caused by client

[ghost]

If sending a POST request with a Content-Type header that is not application/x-www-form-urlencoded and using @FormParam in resource method, an IllegalStateException will be thrown by Jersey and logged at ERROR level by LoggingExceptionMapper. Also, this is the same behavior as https://java.net/jira/browse/JERSEY-2636.

This indicates that users can easily output ERROR level logs in server side. Therefore, I would like to prevent this.

Steps to reproduce

1. Create a new resource class and method that given the @POST and @FormParam.
   Note: @Consumes is optional because ignoring.

@Path("/")
public class EchoResource {
    @POST
    @Consumes(MediaType.APPLICATION_FORM_URLENCODED)
    public String echo(@FormParam("msg") String msg) {
        return msg;
    }
}

2. Send the POST request without a Content-Type header, the 500 Internal Server Error is returned and logged at ERROR level.

$ curl -i -XPOST localhost:8080/
HTTP/1.1 500 Internal Server Error
Date: Sun, 26 Mar 2017 03:20:17 GMT
Content-Type: application/json
Content-Length: 110

{"code":500,"message":"There was an error processing your request. It has been logged (ID 76abeb6446b86576)."}

ERROR [2017-03-26 03:20:17,068] io.dropwizard.jersey.errors.LoggingExceptionMapper: Error handling a request: 76abeb6446b86576
! java.lang.IllegalStateException: The @FormParam is utilized when the content type of the request entity is not application/x-www-form-urlencoded
! at org.glassfish.jersey.server.internal.inject.FormParamValueFactoryProvider$FormParamValueFactory.ensureValidRequest(FormParamValueFactoryProvider.java:183)
! at org.glassfish.jersey.server.internal.inject.FormParamValueFactoryProvider$FormParamValueFactory.getForm(FormParamValueFactoryProvider.java:167)
! at org.glassfish.jersey.server.internal.inject.FormParamValueFactoryProvider$FormParamValueFactory.provide(FormParamValueFactoryProvider.java:118)
! at org.glassfish.jersey.server.spi.internal.ParamValueFactoryWithSource.provide(ParamValueFactoryWithSource.java:71)
! at org.glassfish.jersey.server.spi.internal.ParameterValueHelper.getParameterValues(ParameterValueHelper.java:90)
! at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$AbstractMethodParamInvoker.getParamValues(JavaResourceMethodDispatcherProvider.java:127)
...

Impact

Probably, this change does not affected to users using the past version, because If bound an ExceptionMapper<IllegalStateException> at Application#run(Configuration, Environment), this mappers register in the HK2 container before Dropwizard's ExceptionMapper(s) that is bound by the ExceptionMapperBinder.

Please refer to the following references for details.

Reference 1: HK2 API documentation

Services are sorted by (in order) the service ranking, the largest locator id (so that services in children are picked before services in parents) and smallest service id (so that older services are picked prior to newer services). Therefore the best instance of a service is a service with the highest ranking or largest service locator id or the lowest service id. The ranking of a service is found in its Descriptor and can be changed at any time at run time. The locator id of a service is a system assigned value for the Descriptor when it is bound into the ServiceLocator and is the id of that ServiceLocator. The service id of a service is a system assigned value for the Descriptor when it is bound into the ServiceLocator. The system assigned value is a monotonically increasing value. Thus if two services have the same ranking the best service will be associated with the oldest Descriptor bound into the system.

Reference 2: org.glassfish.jersey.internal.ExceptionMapperFactory#find(Class, T)

[coveralls]

Coverage increased (+0.01%) to 84.391% when pulling 74a69ee on t-tsutsumi:rfe/jersey-exception-handling into 8c27102 on dropwizard:master.

[arteam]

Looks good. Thank you for your detailed explanation of this issue. Hopefully https://java.net/jira/browse/JERSEY-2992 get resolved in the future.