Co-authored-by: Volkan Yazıcı <[email protected]>

…ger (#3854)

Co-authored-by: Volkan Yazıcı <[email protected]>

…#3831)

* Correct log message format in AbstractDriverManagerConnectionSource

The debug log message in AbstractDriverManagerConnectionSource had 4 placeholders but was supplied with 5 arguments.
This corrects the format string to match the argument count, resolving the warning.

Fixes #3828

* Add changelog entry

…3824)

Fixes #3835.

Historically, throwable pattern converters (`%ex`, `%xEx`, etc.) behaved in a context-sensitive way:

* If the **preceding formatter’s expansion** did not end with whitespace, the converter automatically inserted a space before rendering the exception.

In version `2.25.0`, this was changed to insert a **newline** instead of a space, but the behavior was still dependent on surrounding context.

#### What this change does

This PR removes the context-dependent behavior altogether and makes `%ex` expansion fully predictable, while remaining backward-compatible:

* When `%ex` is **added implicitly** because `alwaysWriteExceptions=true`:

  * If the pattern already ends with `%n`, a plain `%ex` is appended.
  * Otherwise, `%notEmpty{%n%ex}` is appended.
    This ensures exceptions are always clearly separated from the main log message by a newline, without adding extra characters when no exception is present.
* When `%ex` is **explicitly included** in the pattern by the user:

  * Its expansion is rendered exactly as written in the pattern.
  * It will **never** prepend a newline on its own.

#### Why

* Eliminates confusing context-sensitive behavior.
* Makes output consistent and predictable.
* Preserves legacy expectations by only modifying implicitly added `%ex`.

Closes #3873

Co-authored-by: Volkan Yazıcı <[email protected]>

This update documents the historical whitespace handling of the `%ex` pattern converter and how it has evolved in the `2.25.x` releases.

Key point: since `2.25.2`, when users add `%ex` explicitly in their pattern, Log4j no longer inserts any automatic separator. It is now entirely up to the user to decide how (or whether) to separate the stack trace from the preceding output.

Related to #3837

Co-authored-by: Volkan Yazıcı <[email protected]>

…r` (#3932)