[BUG] [kotlin+jvm-spring-restclient] Base URLs regression

[tom-wozniakowski-tw]

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

Regression between 7.17.1 and 7.18.0 (versions here are the Gradle plugin, I'm not sure what the underlying lib versions are) . Generated clients with kotlin generator and jvm-spring-restclient library now erroneously ignore the basePath values from the Spring RestClient.

Previously if you set a base path as myService/ and host as www.bob.org. A generated API call against POST action would look like:

POST www.bob.org/myService/action

In 7.18.0 the base path is ignored and you get:

POST www.bob.org/action

Rolling back to 7.17.1 fixes the issue.

OpenAPI declaration file content or url

openApiGenerate {
    generatorName = 'kotlin'
    inputSpec = "$projectDir/src/main/openapi/${project.name}-openapi.yaml"
    outputDir = "$projectDir/build/generated/openapi"
    configOptions = [
      library                 : "jvm-spring-restclient",
      useSpringBoot3          : "true",
      serializationLibrary    : "jackson",
      omitGradleWrapper       : "true",
      omitGradlePluginVersions: "true",
    ]
    typeMappings = [
      'string+binary': 'Resource'
    ]
    importMappings = [
      'Resource': 'org.springframework.core.io.Resource'
    ]
  }

[olaisolheim]

Having the same issue here.

        val client = MyGeneratedHttpClient(
            client = RestClient.builder()
                .baseUrl("http://localhost:1234/api")
                .build()
        )
        client.getCustomers()

The generated HTTP client seems to disregard the /api part. Should invoke /api/customers, but invokes /customers instead.

/api is part of servers section of OpenAPI spec:

servers:
  - url: /api
paths:
  /customers:
    post:
        ...

The only diff between 7.17.0 (left) and 7.18.0 (right) in my generated files are in the generated ApiClient.kt file:

[neeme-praks-sympower]

This issue also affects the kotlin-spring server generator, not just the client.

In 7.17.0, the generated server interface had:

@RequestMapping("\${api.base-path:/api/v1/devices}")
interface DevicesApi {

In 7.18.0, it changed to:

import DevicesApi.Companion.BASE_PATH

@RequestMapping("\${openapi.management.base-path:\${api.base-path:$BASE_PATH}}")
interface DevicesApi {
    companion object {
        const val BASE_PATH: String = "/api/v1/devices"
    }

The Kotlin string interpolation of $BASE_PATH works correctly at compile time—I verified via javap that the compiled annotation contains:

@RequestMapping(value=["${openapi.management.base-path:${api.base-path:/api/v1/devices}}"])

However, Spring doesn't resolve the nested property placeholder correctly at runtime, causing endpoints to be mounted at /gateways/... instead of /api/v1/devices/gateways/.... This results in 404 errors when clients call the expected paths.

Setting openapi.management.base-path or api.base-path explicitly in application.properties did not resolve the issue, suggesting Spring's @RequestMapping annotation processing doesn't support this nested placeholder syntax.

[Picazsoo]

Ok - I introduced this regression. I am very sorry for the issues caused!

[olaisolheim]

#22625 solves the server interface annotation problem mentioned by @neeme-praks-sympower, but does it solve the bug in this issue with the generated client?

[Picazsoo]

Hello @olaisolheim , I checked the changes done by @neeme-praks-sympower and it seems to be fixed everywhere. No trace of my code that caused the issue.

There might be some unused constant variables BASE_PATH left around, but those should do no harm.

If you need some other stuff from 7.18.0, you should be able to grab the fixed mustache files and substitute them externally via the templateDir functionality until 7.19.0 comes out.