Repository navigation
Java/JAX-RS: method-level @Path sub-routes inconsistently composed with class-level prefix #1005
Description
Version: 0.9.0 (macOS arm64, official install.sh)
Stack: Java 21 / Quarkus (JAX-RS, jakarta.ws.rs)
Observed
In the same indexed repository, two JAX-RS resources with the same annotation pattern (class-level @Path prefix + method-level @Path sub-paths, verb annotation before @Path) produce different Route extraction results:
- Resource A: all 10 sub-routes composed correctly, e.g.
__route__POST__/api/v1/things/{}/archive,__route__GET__/api/v1/things/{}. - Resource B: only the class-level route is emitted (
__route__GET__/api/v1/widgets). Method-level sub-paths such as@Path("/count")and@Path("/{id}/read")produce no Route nodes at all.
The inconsistency is worse than a uniform miss: consumers cannot tell whether an absent route means "endpoint does not exist" or "extractor skipped it".
Shape of the failing resource (sanitized)
@Path("/api/v1/widgets")
@RequestScoped
public class WidgetResource {
public WidgetResource(
ListWidgetsUseCase list,
@ConfigProperty(name = "app.widgets.default-limit") int defaultLimit,
@ConfigProperty(name = "app.widgets.max-limit") int maxLimit) { ... }
@GET
@Produces(APPLICATION_JSON)
public PageResponse<WidgetResponse> list(@QueryParam("limit") String limit) { ... }
@GET
@Path("/count")
@Produces(APPLICATION_JSON)
public CountResponse count() { ... } // <- no Route node emitted
}The resource that works has the same @GET / @Path ordering; notable differences in the failing one are constructor parameters annotated with @ConfigProperty and generic DTO return types (PageResponse<T>).
Expected
Method-level @Path composed with the class-level prefix consistently, as it already happens for Resource A (/{} normalization there is great).
Possibly related to #734 (Spring class-level prefix dropped), though here the failure is intra-repo inconsistent rather than uniform.
Happy to run diagnostics builds or provide CBM_DIAGNOSTICS=1 output.
Activity
DeusData commentedon Jul 10, 2026
Thanks for the detailed Java/JAX-RS case. I have triaged this into 0.9.1-rc as a parsing/quality bug. PR #1007 is the current fix candidate; review will focus on class-plus-method path composition and making sure Spring-style extraction does not regress.
fix: compose JAX-RS method-level @path with class-level prefix (DeusD…
DeusData commentedon Jul 15, 2026
Fixed on main by PR #1007 (merged in 34867d9, author @CharlesQueiroz), shipping in v0.9.1.
The root cause was two independent defects: (1) the annotation scan returned on the first mapping annotation, so JAX-RS
@GETmatched before the sibling@Pathand the sub-path defaulted to/; (2) the class-prefix helper only recognized verb-bearing annotations, so a lone class@Pathprefix was never composed. Both are fixed with a one-pass scan that records verb and@Pathseparately.Verified end-to-end on your resource shape:
@Path("/api/v1/widgets")+ method@GET @Path("/count")→/api/v1/widgets/count(previously collapsed to__route__GET__/)@GETwith no method path →/api/v1/widgets@RestController/@RequestMapping/@GetMappingcomposition confirmed unregressedKnown limitation, deferred to a follow-up:
@ApplicationPathbase-path composition needs cross-class resolution (like Spring's cross-file case). Your reported case uses class@Path, which is fixed. Closing — retest on v0.9.1 welcome.