[Bug]: Query parameters incorrectly hoisted to path level causing write operations to inherit filtering parameters

[joe-akeem]

Description of the problem/issue

query parameters are incorrectly "hoisted" to the path level in the generated OpenAPI specification, even when they should only apply to specific operations (typically GET). According to the OpenAPI specification (§4.8.9), parameters defined at the path level apply to all operations on that path. This causes write operations (POST, PUT, PATCH, DELETE) to incorrectly inherit query parameters that are only meaningful for read operations.

Affected Version

2.2.34

Steps to Reproduce

• Create a JAX-RS resource with both GET and write operations on the same path
• Add query parameters to the GET operation (e.g., for filtering or pagination)
• Generate OpenAPI specification using swagger-jaxrs2
• Observe that query parameters appear at the path level instead of operation level

@Path("/users")
public class UserResource {
    
    @GET
    @Operation(summary = "List users")
    public Response getUsers(
        @QueryParam("filter") String filter,
        @QueryParam("page") Integer page) {
        // GET implementation
    }
    
    @POST
    @Operation(summary = "Create user")
    public Response createUser(UserRequest request) {
        // POST implementation - should NOT inherit query params
    }
}

Expected Behavior

The generated OpenAPI specification should place query parameters only in the operations where they are actually used:

/users:
  get:
    parameters:
      - name: filter
        in: query
      - name: page
        in: query
    # ... rest of GET operation
  post:
    # POST operation without query parameters

Actual Behavior

The generated OpenAPI specification incorrectly places query parameters at the path level:

/users:
  parameters:
    - name: filter
      in: query
    - name: page  
      in: query
  get:
    # GET operation (correctly inherits path-level params)
  post:
    # POST operation incorrectly inherits query params

Logs / Stack Traces

No specific error logs - this is a generation/scoping issue rather than a runtime error.

Additional Context

Related Issues: Similar parameter scoping issues have been reported in swagger-ui: #7482, #1802, #9384

Checklist

• I have searched the existing issues and this is not a duplicate.
• I have provided sufficient information for maintainers to reproduce the issue.

[Mattias-Sehlstedt]

Hi, my test is unable to reproduce the issue. Could you attempt to adjust the test so that it produces the behavior that you have reported?

[joe-akeem]

@Mattias-Sehlstedt while trying to come up with a minimal example to reproduce the problem, I stumbled across the root cause in our own code. We use an OpenAPISpecFilter to enrich the spec in other ways and it was misbehaving. I am really sorry for any inconvenience this might have caused. Thanks for looking into it!

[Mattias-Sehlstedt]

Great that we were able to find the cause! Thanks for quick feedback and for closing the issue 👍