feat(template-st): log StringTemplate compile/runtime errors via SLF4J

[renechoi]

Why

StringTemplate v4 defaults to ErrorManager.DEFAULT_ERROR_LISTENER, which
writes compile-time and runtime diagnostics directly to stderr. In most
Spring-based deployments the process stderr stream is either discarded or
treated as an unstructured blob that never reaches Logstash/Grafana, making
template failures virtually invisible at run-time.

Issue #3604 “PromptTemplate should configure error reporting in String
Template” highlighted this gap and requested a way to surface those
messages through the conventional SLF4J pipeline. This commit fulfils that
request and aligns error handling with the rest of the framework logging
strategy.

What

• Slf4jStErrorListener – new STErrorListener implementation that
  delegates compileTimeError, runTimeError, IOError, and
  internalError events to the Logger of StTemplateRenderer.
• StTemplateRenderer
  • Allocates a single STGroup per render operation and registers the
    SLF4J listener so every template instance receives structured logging.
  • Keeps constructor/builder API unchanged; no public surface breakage.
• Unit tests
  • Added malformedTemplateShouldLogErrorViaSlf4j which
    • Injects a Logback ListAppender to capture log events.
    • Verifies that a malformed template triggers an ERROR log entry and
      that nothing is emitted to stderr.
  • Existing tests updated to work with the new code path but remain
    behaviour-identical.
• Docs / Javadoc
  • Updated class‐level Javadoc in StTemplateRenderer to mention the new
    error-reporting mechanism.

How

When createST(String template) is invoked, the renderer now:

1. Creates an STGroup with the configured delimiters.
2. Registers the shared Slf4jStErrorListener instance on the group.
3. Instantiates the ST template from that group.

Because the listener is stateless and threads only interact with it via the
SLF4J facade, the change is thread-safe and produces no additional
allocation hot-spots beyond the lifetime of the template rendering call.

Impact

• Operational visibility – Template compile/runtime errors now appear in
  application logs with timestamps, context, and stack traces, making them
  searchable and monitorable.
• No breaking changes – The public API, default delimiters, and
  validation semantics remain untouched. Projects depending on
  StTemplateRenderer require no code changes.
• Minimal footprint – Adds ~90 logical lines, zero external
  dependencies.

Migration Notes

No migration steps are required. Applications will automatically benefit
from structured error logging after updating to the version that includes
this commit.

References

• Inspired by PromptTemplate should configure error reporting in String Template #3604 “PromptTemplate should configure error reporting in
  String Template”.
• Supersedes ad-hoc stderr printing by adopting the framework’s SLF4J
  logging conventions.

Signed-off-by: [email protected]

[dev-jonghoonpark]

Please reorganize the imports in the following order:

1. java.*
2. other imports
3. org.springframework.*
4. static imports

Also, please avoid using wildcard imports .*

---

For reference, you can refer to the example in this file:
OpenAiApiIT.java.

[dev-jonghoonpark]

Additionally, unnecessary tabs have been added. It would be great if you could remove those as well.

[dev-jonghoonpark]

This line appears to have an unnecessary line break.

[sunyuhan1998]

Hi @renechoi , thank you for your contribution! I think this is a duplicate PR, as the issue is already being addressed through PR #3606 , which is currently under the 1.1.x milestone. I noticed that your PR includes unit tests for the log output, and I think this is a great addition!