Java/JAX-RS: method-level @Path sub-routes inconsistently composed with class-level prefix

[CharlesQueiroz]

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.

[DeusData]

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.