Repository navigation
Java/Spring: class-level @RequestMapping prefix dropped from Route nodes — breaks cross-repo-intelligence for prefixed controllers #734
Description
Activity
Thanks, this is a good actionable Java/Spring route extraction bug. Class-level
@RequestMappingprefixes should compose with method-level mappings before we emitRoute.path; otherwise cross-repo HTTP matching cannot work for prefixed controllers. Tracking this under parsing/cross-repo extraction, with a regression fixture around class-level + method-level mappings as the right first step.- added a commit that references this issue
on Jul 12, 2026 Comment to post on upstream issue #734
"Java/Spring: class-level @RequestMapping prefix dropped from Route nodes — breaks cross-repo-intelligence for prefixed controllers"
#734NOTE: scrubbed of internal identifiers — generic class/route names only.
Still reproduces on v0.9.0 (linux-amd64-portable,
mode=full) — confirming this isn't fixed by the v0.9.0 extraction work.Data point from a production Java/Spring Boot service: of 88
Routenodes, only 3 carry a full path. The rest are bare method-level fragments — e.g. a controller with a class-level@RequestMapping("/api/widgets")and method-level@PostMapping("/")/@PutMapping("/{id}")produces:/ POST WidgetControllerBase.java /{id} PUT WidgetControllerBase.java /{id} DELETE WidgetControllerBase.javaThe real endpoint is
POST /api/widgets, notPOST /.Downstream effect on the tool surface (beyond the cross-repo edges already described in the issue):
find_route_handlercannot match any real endpoint path.find_route_handler {"project":"...", "method":"GET", "path":"/api/widgets"} → {"results": [], "total": 0}...for a route that demonstrably exists.
Additional root-cause detail: decorator arguments aren't captured at all
This may be the more general defect worth fixing.
Decoratornodes are name-only, deduplicated, with no arguments and no file path:MATCH (d:Decorator) WHERE d.name CONTAINS "RequestMapping" RETURN d.name, d.file_path
→ a single row:
["RequestMapping", ""]So the base path exists nowhere in the graph — it is not merely un-composed into the
Route, it is never captured. That also means a consumer cannot work around the issue by re-composing the path themselves.Suggestion
Two layers:
- Capture annotation/decorator arguments on
Decoratornodes (withfile_path, un-deduplicated). This is generally useful well beyond Spring — it's the same missing data that blocks any annotation-driven framework. - Compose class-level base + method-level path into the
Route, either inRoute.nameor as an additionalfull_pathproperty (keeping the fragment for backwards compatibility).
HANDLESedges (Method → Route) already exist and work well — this is the missing piece that would make them actionable.- Capture annotation/decorator arguments on
- added a commit that references this issue
on Jul 15, 2026 Thank you, @maehrlae2, for the clean repro, and @rehanazher for the production data point! The main case is fixed as of v0.9.0 (a19fe03): your
MccRequirementControllerexample now producesGET /api/corporate/mcc/corporates/{corporateId}/requirements.Your
…ControllerBaseexample points at a remaining gap, which we reproduced. When the class-level@RequestMappingsits on the subclass (or on an interface) and the handler methods are inherited from a base class, the prefix isn't applied. We'll track that as a follow-up, and capturing annotation arguments on Decorator nodes as a feature request. Could you confirm the plain-controller case on v0.11.0?Thanks for the report! To move this forward we need a bit more so we can reproduce it ourselves:
- the
codebase-memory-mcp --versionyou're on - the exact steps or command you ran
- a public repo (or a small dummy snippet) that shows the problem — please don't paste proprietary code
Once that's here we'll pick it straight back up. Heads-up: issues left
awaiting-reporterare automatically closed after a few weeks of silence, but a comment reopens the door anytime.- the
Version: v0.8.1 (Windows amd64)
Summary
For Spring MVC/Boot REST controllers that put a base path on the class via
@RequestMapping("/prefix")and per-endpoint paths on@GetMapping/@PostMapping/etc., the extractedRoutenode only stores the method-level path fragment — the class-level prefix is silently dropped. EveryRoutein the graph ends up with the wrong (truncated) path, socross-repo-intelligencecan never produce aCROSS_HTTP_CALLSedge for these routes: the caller's real URL (which does include the prefix) can never string-match the truncated route.Repro
Expected
Route:GET /api/corporate/mcc/corporates/{corporateId}/requirementsActual
Routein the graph (viasearch_graph(label="Route", name_pattern=".*mcc.*")):GET /corporates/{corporateId}/requirements— the/api/corporate/mccprefix is missing.Not an isolated case: on a real ~45k-node Spring Boot codebase, sampling all 120 extracted
Routenodes, none carry their controller's class-level@RequestMappingprefix, across several distinct controllers/base paths.Impact
index_repository(mode="cross-repo-intelligence")against a real consumer (a Laravel/PHP frontend calling these Java REST endpoints over HTTP with fully-qualified, correct paths) returnstotal_cross_edges: 0for every category — consistent with #523, #678, #686, which look like the same underlying bug class (router/class-level prefix stripped) across different frameworks (FastAPI, Go Fiber). This appears to be the Java/Spring instance of that same class of bug, which I didn't see filed separately.Environment
@RestController+ class-level@RequestMapping+ method-level@GetMapping/@PostMapping/etc.