[wylovelyi]

What

The three %c precision examples in pattern-layout.adoc that spell a period before the asterisk now use the form without it:

Before	After
%c{1.2.*}	%c{1.2*}
%c{1.3.*}	%c{1.3*}
%c{1.8.*}	%c{1.8*}

The documented output values and the surrounding prose are unchanged.

Why

Thanks @ramanathan1504 for pointing this out — the earlier revision of this PR rewrote the expected outputs instead, which was the wrong fix.

The period before * changes which abbreviator is selected. NameAbbreviator.getAbbreviator() routes 1.2.* to PatternAbbreviator (one character count per segment, * = keep the rest verbatim) but 1.2* to DynamicWordAbbreviator (keep the rightmost N tokens in full).

The prose above the table describes the DynamicWordAbbreviator semantics:

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.

So the table rows are correct as written — it is the pattern spelling that was wrong. With the period removed, the prose, the pattern and the documented output all agree.

Verification

Measured against the released log4j-core 2.26.1, calling NameAbbreviator.getAbbreviator(precision) directly for logger name org.apache.commons.test.Foo:

precision   actual output                  table says                  match
1.2*        o.a.c.test.Foo                 o.a.c.test.Foo              yes
1.3*        o.a.commons.test.Foo           o.a.commons.test.Foo        yes
1.8*        org.apache.commons.test.Foo    org.apache.commons.test.Foo yes
1.2.*       o.ap.commons.test.Foo          o.a.c.test.Foo              NO
1.3.*       o.apa.commons.test.Foo         o.a.commons.test.Foo        NO
1.8.*       o.apache.commons.test.Foo      org.apache.commons.test.Foo NO

The last three rows are the PatternAbbreviator path and are what the page produced before this change; the first three are the DynamicWordAbbreviator path the prose describes.

%c{1.1.1.*} is left as-is: all three counts are 1, so both abbreviators happen to produce o.a.c.test.Foo and the row is already correct.

Scope

Documentation only — no behaviour change. Existing NameAbbreviatorTest assertions for 1.2* / 1.3* / 1.8* are untouched and still pass.

Refs #2522

[wylovelyi]

Friendly ping for review when you have a moment. This is a docs-only fix (1 file, +7/−4) that aligns the %c precision table examples and prose with the actual behaviour of NameAbbreviator — every row in the table was verified against log4j-core 2.26.1 (13/13 pass, see PR description). Zero behaviour change, existing NameAbbreviatorTest untouched.

[ramanathan1504]

The PR is right that %c{1.2.*} prints o.ap.commons.test.Foo today. That form is PatternAbbreviator, but the old outputs and the "rightmost tokens" sentence describe DynamicWordAbbreviator, which only matches 1.2* without the dot.
What do you think about keeping the prose and changing the three patterns in pattern-layout.adoc to %c{1.2*}, %c{1.3*} and %c{1.8*} instead? That gives c.f.b.bazzzle.AResourceLogger from #2522.

[wylovelyi]

Thanks @ramanathan1504 — you're right, and I've gone with your suggestion.

I pushed a new head that reverts my prose rewrite entirely and only changes the three patterns to %c{1.2*}, %c{1.3*} and %c{1.8*}. The diff is now +3/-3 in one file, and the prose and all documented outputs are exactly as they were.

Your point about the two abbreviators was the piece I had wrong: the period routes to PatternAbbreviator, which is why %c{1.2.*} prints o.ap.commons.test.Foo, while DynamicWordAbbreviator (no period) is what the prose actually describes. I re-verified directly against log4j-core 2.26.1:

1.2*  -> o.a.c.test.Foo                 (table: o.a.c.test.Foo)              match
1.3*  -> o.a.commons.test.Foo           (table: o.a.commons.test.Foo)        match
1.8*  -> org.apache.commons.test.Foo    (table: org.apache.commons.test.Foo) match
1.2.* -> o.ap.commons.test.Foo          (table: o.a.c.test.Foo)              no match

I left %c{1.1.1.*} alone since all three counts are 1 and both paths produce the same o.a.c.test.Foo there.

PR description updated to match. Thanks for the careful read.