question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Support for Jersey MappableException in 'DefaultJerseyTagsProvider'

See original GitHub issue

I am using Micrometer in my Jersey application and i have noticed that the DefaultJerseyTagsProvider can’t handle MappableException.

Here is an extract from the DefaultJerseyTagsProvider code:

 private static int statusCode(RequestEvent event) {
        Throwable exception = event.getException();
        if (exception != null) {
            if (exception instanceof WebApplicationException) {
                return ((WebApplicationException) exception).getResponse().getStatus();
            }
            return Response.Status.INTERNAL_SERVER_ERROR.getStatusCode();
        }
        return event.getContainerResponse().getStatus();
    }

With that code, whenever we have an exception that is not a WebApplicationException, we will have a 500 status code…

When using MappableException, application exceptions are mapped to Jersey Response (with an appropriate response status). For example, the ValidationExceptionMapper from Jersey should return a 400 (Bad Request) when request parameters validation fails. As a consequence, when using micrometer-jersey2, i am expecting a http.server.requests metric with a {status = 400} tag when my request is not valid but i only have {status = 500} tags.

Should it be possible to add support for MappableException so as the status tag value would be the same than the response status code?

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Comments:6 (6 by maintainers)

github_iconTop GitHub Comments

1reaction
mweirauchcommented, Jun 21, 2018

PR is merged. Thanks again!

0reactions
mweirauchcommented, Jun 19, 2018

Yeah, also looked a bit and came to the same conclusion. So within the statusCode() we don’t even have to handle any exceptions, just figure if the ContainerResponse is there and use its getStatus(), otherwise return Response.Status.INTERNAL_SERVER_ERROR.getStatusCode().

Thanks for looking into it!

PS: PR against branch 1.0.x please.

Read more comments on GitHub >

github_iconTop Results From Across the Web

jersey endpoint throwing an exception org.glassfish ... - Eclipse
I have an endpoint which returns a pdf file, the endpoint seems to work which means the client gets the file successfully, however...
Read more >
web services - org.glassfish.jersey.server.internal.process ...
I have a webservice hosted on tomcat7 which returns a zip file after some processing. I am getting below exception org.glassfish.jersey.server.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found