Drop the duplicate handler resolution in Spring Web 6 instrumentation

[amarziali]

What Does This Do

The Spring Web 6 instrumentation was copied from the 3/5 design and inherited a per-request cost it didn't need. An injected servlet filter (HandlerMappingResourceNameFilter) resolved the request handler a second time on every request, only to read the matched route. Spring's DispatcherServlet then resolved the same handler again during normal dispatch.

This PR removes that filter and the machinery that existed only to support it, and names the route from the attribute Spring already sets while dispatching.

It also handle a corner case when the preHandle is aborting the request before that the handler is matched (that was one of the reason why the previous filter was there). In this case the information is taken by HandlerMappingAdvice since it kicks in before applyPreHandle

The final split is:

• HandlerMappingAdvice (getHandler): annotated controllers, and the preHandle-abort case (route named before the controller is skipped).
• ControllerAdvice (handle): SimpleUrlHandlerMapping and the normal path.

Edit: The old instrumentation containing the spring-path-filter advice has been kept but it's disabled by default. Any customer that experience issues may reintroduce back by using DD_INTEGRATION_SPRING_PATH_FILTER_ENABLED=true

Motivation

Profiles shows this as the major overhead we had in the spring web instrumentation

Additional Notes

We have similar approach for spring 3/5 -> it might be worth also solving it

Contributor Checklist

• Format the title according to the contribution guidelines
• Assign the type: and (comp: or inst:) labels in addition to any other useful labels
• Avoid using close, fix, or any linking keywords when referencing an issue
  Use solves instead, and assign the PR milestone to the issue
• Update the CODEOWNERS file on source file addition, migration, or deletion
• Update public documentation with any new configuration flags or behaviors
• Add your completed PR to the merge queue by commenting /merge. You can also:
  • Customize the commit message associated with the merge with /merge --commit-message "..."
  • Remove your PR from the merge queue with /merge -c
  • Skip all merge queue checks with /merge -f --reason "reason"; please use this judiciously, as some checks do not run at the PR-level
  • Get more information in this doc

Jira ticket: [PROJ-IDENT]

[datadog-datadog-prod-us1-2]

✨ Fix all issues with BitsAI

⚠️ Warnings

🚦 5 Pipeline jobs failed

DataDog/apm-reliability/dd-trace-java | linux-java-spring-petclinic-startup-parallel     

🔄 Retry job. This looks flaky and may succeed on retry.

Build not found for pipeline 116402669 (HTTP 404).

DataDog/apm-reliability/dd-trace-java | java-startup-parallel-check-slo-breaches     

🛟 This job is unlikely to succeed on retry. Please review your pipeline configuration.

No Markdown threshold comparison report was generated due to missing scenarios for comparison.

DataDog/apm-reliability/dd-trace-java | java-startup-parallel-generate-slos     

🛟 This job is unlikely to succeed on retry. Please review your pipeline configuration.

Missing artifacts directory: No such file or directory for 'artifacts'.

View all 5 failed jobs.

Useful? React with 👍 / 👎

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 1bb1444 | Docs | Datadog PR Page | Give us feedback!}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a271f0d93c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[mcculls]

Thanks for adding a way to revert to the old behaviour, just in case

[amarziali]

/merge

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-06-03 15:12:00 UTC ℹ️ Start processing command /merge

---

2026-06-03 15:12:06 UTC ℹ️ MergeQueue: pull request added to the queue

The expected merge time in master is approximately 1h (p90).

---

2026-06-03 16:29:02 UTC ℹ️ MergeQueue: This merge request was merged