Hi @ppkarwasz,

Can you update the release notes for 2.24.0 to document the fact that this deprecation also means that the relaxed syntax of with 'P' and 'T' optional is also thus deprecated?
This is not clearly defined in the release notes and thus means consumers of o.a.l.l.c.a.r.a.Duration that naively migrate to java.time.Duration can thus suddenly encounter java.time.format.DateTimeParseException's for strings that could previously be parsed without issue.

Thanks,
Jeremy

Hi @ppkarwasz,

Can you update the release notes for 2.24.0 to document the fact that this deprecation also means that the relaxed syntax of with 'P' and 'T' optional is also thus deprecated? This is not clearly defined in the release notes and thus means consumers of o.a.l.l.c.a.r.a.Duration that naively migrate to java.time.Duration can thus suddenly encounter java.time.format.DateTimeParseException's for strings that could previously be parsed without issue.

Thanks, Jeremy

I also am not sure if it would be worthwhile calling out to users in the Release Notes that configuration elements such as <IfLastModified age="7d"/> are also thus deprecated and should be updated to syntax such as <IfLastModified age="P7D"/>?

I also am not sure if it would be worthwhile calling out to users in the Release Notes that configuration elements such as <IfLastModified age="7d"/> are also thus deprecated and should be updated to syntax such as <IfLastModified age="P7D"/>?

@norrisjeremy, to keep the backward compatibility, Log4j 2 still uses the (deprecated) Log4j Duration class to read IfLastModified#age – the new j.t.Duration syntax is not supported yet. We only marked the class and its usages as deprecated to warn users accessing those fields programmatically, etc. But you have a point: Log4j 3 completely switches to j.t.Duration and this will break incompatible IfLastModified configurations. That said, Log4j 3 will be a big bang anyway... 🤷