Skip to content

[BUG] Breaking change: @Path annotation no longer generated at class level when interfaceOnly=true in v7.17.0Β #22279

Closed

Description

@Sgitario

Bug Report Checklist

  • Have you provided a full/minimal spec to reproduce the issue?
  • Have you validated the input using an OpenAPI validator?
  • Have you tested with the latest master to confirm the issue still exists?
  • Have you searched for related issues/PRs?
  • What's the actual output vs expected output?
  • [Optional] Sponsorship to speed up the bug fix or feature request (example)
Description

Starting with OpenAPI Generator v7.17.0, when using the jaxrs-spec generator with interfaceOnly=true, the @Path annotation is no longer generated at the class level of JAX-RS interfaces. This breaks JAX-RS resource registration in frameworks like RESTEasy/Spring Boot, causing 404 errors for endpoints that worked correctly in v7.16.0.

Generator

jaxrs-spec

Configuration
<configOptions>
  <interfaceOnly>true</interfaceOnly>
  <useJakartaEe>true</useJakartaEe>
</configOptions>
Expected Behavior (v7.16.0)

Generated interface includes @Path at class level:

@Path("/v1/opt-in")
public interface OptInApi {
    @DELETE
    void deleteOptInConfig();
    
    @GET  
    OptInConfig getOptInConfig();
}
Actual Behavior (v7.17.0)

Generated interface has NO @Path at class level:

public interface OptInApi {
    @DELETE
    @Path("/v1/opt-in")
    void deleteOptInConfig();
    
    @GET
    @Path("/v1/opt-in") 
    OptInConfig getOptInConfig();
}
Root Cause

This breaking change was introduced in commit 808d106e0c6 from PR #22169 "[jaxrs] Support jackson option (true by default)".

The change modified api.mustache template to conditionally generate @Path only when NOT using interfaceOnly:

{{^interfaceOnly}}
@Path("{{commonPath}}")
{{/interfaceOnly}}
Impact
  • JAX-RS frameworks like RESTEasy cannot properly register resources without class-level @Path annotation
  • Existing projects using interfaceOnly=true break when upgrading to v7.17.0
  • Results in 404 errors for previously working endpoints
Proposed Solution

The @Path annotation should be generated at class level regardless of interfaceOnly setting, as it's required for proper JAX-RS resource registration. The conditional logic should only apply to implementation-specific annotations, not core JAX-RS annotations.

Steps to Reproduce
  1. Use jaxrs-spec generator with interfaceOnly=true
  2. Generate code with v7.17.0
  3. Try to use generated interfaces in RESTEasy/Spring Boot application
  4. Observe 404 errors for endpoints

This appears to be an unintended breaking change that should be reverted or made configurable.

Activity

  1. wing328 commented on Nov 4, 2025

    @wing328
    Member

    thanks for reporting the issue

    @rignicat can you please review the issue when you've time?

  2. rignicat commented on Nov 4, 2025

    @rignicat
    Contributor

    @Sgitario how exactly are you guys using the generated interface? I am creating an implementation, but when adding this to a war my application server (Payara) picks up the interface as well (and then breaks, because its an interface not a class).

    So the solution is to put the @Path over the methods, preventing the application server from picking up the interface (and then you set an appropriate or empty @Path above the implementation)

  3. rignicat commented on Nov 5, 2025

    @rignicat
    Contributor

    okay, I assume this doesn't pick up the interfaces like Payara does. Can you add @Path("") parameter to your beans to solve this? or do we need to revert this?

  4. Sgitario commented on Nov 5, 2025

    @Sgitario
    Author

    okay, I assume this doesn't pick up the interfaces like Payara does. Can you add @Path("") parameter to your beans to solve this? or do we need to revert this?

    Unfortunately, we do have many generated API and we don't have control to add the annotation in all of them. I also tried to use interfaceOnly=false, but it didn't work for us either.

  5. grantsunny commented on Nov 10, 2025

    @grantsunny

    This issue was hit on our end today and we have to fallback to 7.16.0. @Sgitario thank you for reporting this and expecting a rather prompt fix...

  6. wing328 commented on Nov 10, 2025

    @wing328
    Member

    Just merged the fix by @rignicat

    Please give it a try with the latest master

  7. added a commit that references this issue on Nov 10, 2025
    28e2254
  8. added a commit that references this issue on Dec 25, 2025
    af45646
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions