[BUG][Kotlin][WebClient] Using String templates for path causes incorrect URI variables resolution

[dwawrzyniak1]

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator (example)?
• 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

The current implementation of the Kotlin jvm-web-client templates URI variables into a path using a String template instead of a URI builder. That makes micrometer metrics be aggregated by, for example, /person/id/1234 instead of person/id/{id}.

openapi-generator version

7.0.0

OpenAPI declaration file content or url

Anything with URI variables.

Generation Details

openApiGenerate {
  val packageName = "org.example"
  generatorName.set("kotlin")
  library.set("jvm-spring-webclient")
  inputSpec.set(tasks.generateOpenApiDocs.flatMap { it.outputFile })
  outputDir.set("$buildDir/generated/open-api-client")
  this.packageName.set(packageName)
  apiPackage.set("$packageName.api")
  modelPackage.set("$packageName.model")
  configOptions.set(
    mapOf(
      "serializationLibrary" to "jackson",
      "dateLibrary" to "java8",
      "useSpringBoot3" to "false",
      "enumPropertyNaming" to "UPPERCASE"
    )
  )
  importMappings.set(
    mapOf(
      "Pageable" to "org.springframework.data.domain.Pageable"
    )
  )
}

Steps to reproduce

Make the API call with the generated client from an application with a micrometer configured and check out client metrics.

Related issues/PRs

spring-projects/spring-framework#22371

Suggest a fix

Adjust templates to use the UriBuilder instead of String templating.

[wing328]

Adjust templates to use the UriBuilder instead of String templating.

I wonder if you can file a PR with the suggested fix. Let me know if you need any help.

[stefankoppier]

@dwawrzyniak1 I'll give this a look. I'm encountering a different bug with double url encoding, which can also be resolved by using UriBuilder.