fix(java-spring): expose requestBody named examples to Mustache template context (#23607)

[anupamchaubey]

Fixes #23607.

Description of Changes
Updated AbstractJavaCodegen to correctly populate named requestBody examples from mediaType.getExamples() into codegenParameter.examples, ensuring they are properly exposed to Mustache templates.

Added a unit test in SpringCodegenTest along with a test OpenAPI specification YAML (requestbody_named_examples.yaml) to verify that named request body examples are correctly mapped and available for template rendering.

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.

---

Summary by cubic

Expose named requestBody named examples to Mustache templates in the Java Spring generator and set a scalar example for non-model request bodies. Previously templates could not access named examples; now they are available on codegenParameter.examples, and non-model bodies use the first named example for codegenParameter.example (models still ignore complex examples and log once).

• Assigns mediaType.getExamples() to codegenParameter.examples; falls back to existing example logic when none are provided.
• For non-model bodies only, sets codegenParameter.example from the first named example’s value.
• Adds a Spring test that preprocesses and sets the OpenAPI on the generator to mirror DefaultGenerator, asserting named examples “Jessica” and “Ron” are exposed.

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

[cubic-dev-ai]

All reported issues were addressed across 3 files

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

Re-trigger cubic</sub>

[wing328]

thanks for the PR

did you have a chance to review the feedback from cubic-dev-ai?

calling generator.opts(input).generate(); seems not necessary?

[Mattias-Sehlstedt]

Any particular reason as to why this is placed within the JavaCodegen and not in the DefaultCodegen? I would assume that this is something that all code generators most likely would want to access?

[Mattias-Sehlstedt]

Is it an intentional change that we now silently continue processing rather than throwing an exception if the request body does not contain any content?

[anupamchaubey]

Thanks for the thorough review, @Mattias-Sehlstedt!

1. Why AbstractJavaCodegen instead of DefaultCodegen? You make a great point; exposing named examples is likely useful for other generators too. I implemented it here as a focused fix for Java, but I can look into shifting this up to DefaultCodegen to align with setParameterExamples if you think it belongs globally.

2. Silent continue on empty content: Yes, that was an intentional adjustment to avoid abrupt runtime exceptions on non-standard specs, allowing the generator to proceed smoothly. However, if a strict check or warning is preferred there, I'd be happy to add it back!

[Mattias-Sehlstedt]

To clarify if it was not clear to begin with: I am not affiliated with the project in any sense, and that these are my personal opinions.

1. I would argue that it definitely belongs as a global configuration so that any language generator can utilize the data to construct better examples locally with the mustache files.

2. Given that no one has raised any issue with a NPE being thrown unexpectedly I would leave that behavior as-is since I would argue that its age might even be an indicator of it not even being something that is possible (and if it is an issue, then someone will have to raise an issue specifically for that and highlight exactly when it occurs and what is a proper way of handling it).

Note that the @Override on the method also seems to have fallen back one space.

[Mattias-Sehlstedt]

DefaultCodegen has setParameterExamples(CodegenParameter codegenParameter, Parameter parameter) which does basically the same as this. Is that something we should mimic for clarity?

[anupamchaubey]

Thanks for pointing that out! Mimicking DefaultCodegen#setParameterExamples makes total sense for consistency and clarity. I can refactor this to align with that pattern.

[cubic-dev-ai]

All reported issues were addressed across 1 file (changes from recent commits).

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

Re-trigger cubic</sub>

[anupamchaubey]

thanks for the PR

did you have a chance to review the feedback from cubic-dev-ai?

calling generator.opts(input).generate(); seems not necessary?

Thanks, @wing328! Yes, you were spot on—I've removed the unnecessary generator.opts(input).generate() call and cleaned up the test scaffolding.