wylovelyi opened a new pull request, #4394:
URL: https://github.com/apache/logging-log4j2/pull/4394
## What
Corrects the `%c` / `%logger` precision documentation so the examples match
what log4j2 actually produces.
## Why
Follow-up to #2522. While reproducing that report I found the example table
and the implementation disagree for every pattern where the number preceding
`*` is not `1` — not just the reported `1.2.*`:
| Pattern | Logger name | Table said | Actual output |
|---|---|---|---|
| `%c{1.2.*}` | `org.apache.commons.test.Foo` | `o.a.c.test.Foo` |
`o.ap.commons.test.Foo` |
| `%c{1.3.*}` | `org.apache.commons.test.Foo` | `o.a.commons.test.Foo` |
`o.apa.commons.test.Foo` |
| `%c{1.8.*}` | `org.apache.commons.test.Foo` |
`org.apache.commons.test.Foo` | `o.apache.commons.test.Foo` |
`%c{1.1.1.*}` only *looks* correct because all three counts happen to be `1`.
## Root cause
`NameAbbreviator.getAbbreviator()` consumes the digit before `*` as another
per-segment character count:
```java
if (trimmed.charAt(pos) == '*') {
charCount = Integer.MAX_VALUE;
} else if (trimmed.charAt(pos) >= '0' && trimmed.charAt(pos) <= '9') {
charCount = trimmed.charAt(pos) - '0'; // also consumes the digit
before '*'
...
}
```
For `1.2.*` the fragments become `[1 char, 2 chars, keep-all]`, so `org` →
`o`, `apache` → `ap`, and the rest is preserved verbatim — hence the unexpected
`p`.
The prose above the table also contributed to the confusion. It stated:
> If the number after the first period is followed by an asterisk it
indicates how many of the rightmost tokens will be printed in full.
Read literally that would make `%c{1.2.*}` = "1 char for leading segments +
the 2 rightmost tokens in full" = `o.a.commons.test.Foo`, which the
implementation has never produced. It is also inconsistent with the table
itself, since `%c{1.3.*}` → `o.a.commons.test.Foo` is only correct under the
"digit = character count" reading.
## How
- Rewrote the prose to describe the actual semantics: each numeric token is
the number of characters to print from the corresponding component, and `*`
prints that component — and all following components — in full.
- Corrected the three table rows listed above.
**No behaviour change.** The existing `NameAbbreviatorTest` assertions for
`1.2*` / `1.3*` / `1.8*` are untouched and still pass.
## Verification
Compiled and ran a harness against the released `log4j-core` **2.26.1**,
calling `NameAbbreviator.getAbbreviator(precision)` directly for **every** row
of the table (13 rows, including the `DynamicWordAbbreviator` path):
```text
%c{1} org.apache.commons.Foo Foo OK
%c{2} org.apache.commons.Foo commons.Foo OK
%c{10} org.apache.commons.Foo org.apache.commons.Foo OK
%c{-1} org.apache.commons.Foo apache.commons.Foo OK
%c{-2} org.apache.commons.Foo commons.Foo OK
%c{-10} org.apache.commons.Foo org.apache.commons.Foo OK
%c{1.} org.apache.commons.Foo o.a.c.Foo OK
%c{1.1.~.~} org.apache.commons.test.Foo o.a.~.~.Foo OK
%c{.} org.apache.commons.test.Foo ....Foo OK
%c{1.1.1.*} org.apache.commons.test.Foo o.a.c.test.Foo OK
%c{1.2.*} org.apache.commons.test.Foo o.ap.commons.test.Foo OK
%c{1.3.*} org.apache.commons.test.Foo o.apa.commons.test.Foo OK
%c{1.8.*} org.apache.commons.test.Foo o.apache.commons.test.Foo OK
passed=13 failed=0
```
Before this change the same harness reported 3 mismatches (the `1.2.*`,
`1.3.*`, `1.8.*` rows).
## Note on scope
This PR only corrects the documentation. If the intent is actually to change
the behaviour so that `N.*` means "keep the N rightmost tokens in full" (the
literal reading of the old prose), that would be a backward-incompatible change
affecting existing patterns like `1.2*` and `1.3*`, and it would break current
assertions in `NameAbbreviatorTest`. I deliberately avoided that here — happy
to open a separate PR if that is the preferred direction, ideally after a
decision on the issue.
Refs #2522
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
