[Mattias-Sehlstedt]

Adds a .toString to the singleRequestParameter class. This is for example helpful when the class is used within the JUnit testing framework, which relies on the .toString to showcase the difference between an expected and actual test value match.

The implementation is an adaptation of the toString that is used for pojos (models).

PR checklist

• Read the contribution guidelines.
• Run the following to build the project and update samples:

  ./mvnw clean package || exit
  ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
  ./bin/utils/export_docs_generators.sh || exit
  

  (For Windows users, please run the script in WSL)
  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

Java technical committee since I assume the Spring one is tied to the server generation.
@bbdouglas (2017/07) @sreeshas (2017/08) @jfiala (2017/08) @lukoyanov (2017/09) @cbornet (2017/09) @jeff9finger (2018/01) @karismann (2019/03) @Zomzog (2019/04) @lwlee2608 (2019/10) @martin-mfg (2023/08) @KannaKim (2026/07)

---

Summary by cubic

Add toString to generated single-request-parameter classes for Java restclient and webclient. This makes request objects readable in logs and JUnit diffs while masking passwords.

• New Features
  • toString matches model POJO style with a multi-line, indented field list.
  • Password fields are masked; values are safely stringified.
  • Regenerated Java petstore samples to include the new method.

^{Written for commit a7c52d2. Summary will update on new commits.}

[cubic-dev-ai]

3 issues found across 8 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="modules/openapi-generator/src/main/resources/Java/libraries/webclient/single_request_parameter.mustache">

<violation number="1" location="modules/openapi-generator/src/main/resources/Java/libraries/webclient/single_request_parameter.mustache:61">
P2: Binary request parameters will produce identity-based values such as `[B@...` in `toString()`, so output is nondeterministic and does not provide useful expected/actual diffs for `byte[]` values. Handling `isByteArray` with `Arrays.toString(...)` (while retaining the password branch) would make this formatting useful for binary parameters too.</violation>
</file>

<file name="samples/client/petstore/java/restclient-useSingleRequestParameter-static/src/main/java/org/openapitools/client/api/UserApi.java">

<violation number="1" location="samples/client/petstore/java/restclient-useSingleRequestParameter-static/src/main/java/org/openapitools/client/api/UserApi.java:465">
P2: The new LoginUserRequest.toString() prints the password parameter in clear text (sb.append("...password: ").append(toIndentedString(password))). If these request objects get logged or appear in JUnit failure output, the credential is exposed. The generator already supports masking via the isPassword guard (used by pojo toString for format: password fields); consider marking the login password param as format: password in the source spec so isPassword evaluates true and the template emits "*" instead of the value.</violation>
</file>

<file name="modules/openapi-generator/src/main/resources/Java/libraries/restclient/single_request_parameter.mustache">

<violation number="1" location="modules/openapi-generator/src/main/resources/Java/libraries/restclient/single_request_parameter.mustache:65">
P2: A request parameter named `sb` is rendered incorrectly: the unqualified field reference resolves to the local `StringBuilder sb`, so `toString()` prints the builder instead of the parameter value. Qualifying generated fields with `this.` avoids this valid name collision.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P2: Binary request parameters will produce identity-based values such as [B@... in toString(), so output is nondeterministic and does not provide useful expected/actual diffs for byte[] values. Handling isByteArray with Arrays.toString(...) (while retaining the password branch) would make this formatting useful for binary parameters too.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At modules/openapi-generator/src/main/resources/Java/libraries/webclient/single_request_parameter.mustache, line 61:

<comment>Binary request parameters will produce identity-based values such as `[B@...` in `toString()`, so output is nondeterministic and does not provide useful expected/actual diffs for `byte[]` values. Handling `isByteArray` with `Arrays.toString(...)` (while retaining the password branch) would make this formatting useful for binary parameters too.</comment>

<file context>
@@ -52,6 +52,25 @@
+            StringBuilder sb = new StringBuilder();
+            sb.append("class {{#lambda.titlecase}}{{operationId}}{{/lambda.titlecase}}Request {\n");
+            {{#allParams}}
+            sb.append("    {{paramName}}: ").append({{#isPassword}}"*"{{/isPassword}}{{^isPassword}}toIndentedString({{paramName}}){{/isPassword}}).append("\n");
+            {{/allParams}}
+            sb.append("}");
</file context>

Suggested change

	sb.append(" {{paramName}}: ").append({{#isPassword}}"*"{{/isPassword}}{{^isPassword}}toIndentedString({{paramName}}){{/isPassword}}).append("\n");
	sb.append(" {{paramName}}: ").append({{#isPassword}}"*"{{/isPassword}}{{^isPassword}}{{#isByteArray}}Arrays.toString({{paramName}}){{/isByteArray}}{{^isByteArray}}toIndentedString({{paramName}}){{/isByteArray}}{{/isPassword}}).append("\n");

[cubic-dev-ai]

P2: The new LoginUserRequest.toString() prints the password parameter in clear text (sb.append("...password: ").append(toIndentedString(password))). If these request objects get logged or appear in JUnit failure output, the credential is exposed. The generator already supports masking via the isPassword guard (used by pojo toString for format: password fields); consider marking the login password param as format: password in the source spec so isPassword evaluates true and the template emits "*" instead of the value.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At samples/client/petstore/java/restclient-useSingleRequestParameter-static/src/main/java/org/openapitools/client/api/UserApi.java, line 465:

<comment>The new LoginUserRequest.toString() prints the password parameter in clear text (sb.append("...password: ").append(toIndentedString(password))). If these request objects get logged or appear in JUnit failure output, the credential is exposed. The generator already supports masking via the isPassword guard (used by pojo toString for format: password fields); consider marking the login password param as format: password in the source spec so isPassword evaluates true and the template emits "*" instead of the value.</comment>

<file context>
@@ -456,6 +456,24 @@ public boolean equals(Object o) {
+            StringBuilder sb = new StringBuilder();
+            sb.append("class LoginUserRequest {\n");
+            sb.append("    username: ").append(toIndentedString(username)).append("\n");
+            sb.append("    password: ").append(toIndentedString(password)).append("\n");
+            sb.append("}");
+            return sb.toString();
</file context>

[Mattias-Sehlstedt]

This is handled in #22761

[cubic-dev-ai]

P2: A request parameter named sb is rendered incorrectly: the unqualified field reference resolves to the local StringBuilder sb, so toString() prints the builder instead of the parameter value. Qualifying generated fields with this. avoids this valid name collision.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At modules/openapi-generator/src/main/resources/Java/libraries/restclient/single_request_parameter.mustache, line 65:

<comment>A request parameter named `sb` is rendered incorrectly: the unqualified field reference resolves to the local `StringBuilder sb`, so `toString()` prints the builder instead of the parameter value. Qualifying generated fields with `this.` avoids this valid name collision.</comment>

<file context>
@@ -56,6 +56,25 @@
+            StringBuilder sb = new StringBuilder();
+            sb.append("class {{#lambda.titlecase}}{{operationId}}{{/lambda.titlecase}}Request {\n");
+            {{#allParams}}
+            sb.append("    {{paramName}}: ").append({{#isPassword}}"*"{{/isPassword}}{{^isPassword}}toIndentedString({{paramName}}){{/isPassword}}).append("\n");
+            {{/allParams}}
+            sb.append("}");
</file context>

Suggested change

	sb.append(" {{paramName}}: ").append({{#isPassword}}"*"{{/isPassword}}{{^isPassword}}toIndentedString({{paramName}}){{/isPassword}}).append("\n");
	sb.append(" {{paramName}}: ").append({{#isPassword}}"*"{{/isPassword}}{{^isPassword}}toIndentedString(this.{{paramName}}){{/isPassword}}).append("\n");

[Mattias-Sehlstedt]

All feedback is relevant for cases outside this PR itself. If the feedback is considered relevant, then I can fix these in separate PRs that are merged before this one