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

[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.

[wing328]

thanks for reporting the issue

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

[rignicat]

@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)

[Sgitario]

I'm using Spring Boot + RESTEasy (see https://github.com/resteasy/resteasy-spring-boot).
Note that this is how the logic works in the RESTEasy extension: https://github.com/resteasy/resteasy-spring-boot/blob/4b76fc14439af9fec5b1b8f5756332ba339148a7/common/resteasy-spring-boot-starter-common/src/main/java/org/jboss/resteasy/springboot/common/ResteasyResourcesFinder.java#L217

[rignicat]

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?

[Sgitario]

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.

[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...

[wing328]

Just merged the fix by @rignicat

Please give it a try with the latest master