Double-check for handler mapping in MetricsFilter

[OrangeDog]

If any request is dealt with by a filter (e.g. something in the security chain) then it appears in the metrics as unmapped. This makes it hard to see, for example, which endpoints clients keep failing to authenticate with (all of them, or one in particular), or the total number of requests made to an endpoint.

One solution I can see is to inject a HandlerMapping into the filter and add this at the top of getFinalStatus:

try {
    handlerMapping.getHandler(request);
} catch (Exception ignored) { }

This then adds the appropriate attribute if the request would have been mapped to something before a filter dealt with it. As this method is private, I cannot easily just replace this behaviour.

[wilkinsona]

Injecting a HandlerMapping would further couple MetricsFilter to Spring MVC and we actually want to move things in the other direction (see #7505). Furthermore, if a filter has rejected a request and prevented further processing of the request from being performed, I don't think it would be appropriate for MetricsFilter to circumvent that out of the box.

The change in #7505 will see MetricsFilter defining its own request attribute that's used to determine the metric name based on a mapping, in the meantime it uses Spring MVC's HandlerMapping.BEST_MATCHING_PATTERN. If you want the behaviour that you've described, you could add your own, appropriately ordered Filter that sets this attribute before the filter chain unwinds back to the metrics filter.