ppkarwasz commented on code in PR #3789:
URL: https://github.com/apache/logging-log4j2/pull/3789#discussion_r2193258551
##########
log4j-core/src/main/java/org/apache/logging/log4j/core/pattern/DatePatternConverter.java:
##########
@@ -109,84 +109,11 @@ private static String readPattern(@Nullable final
String[] options) {
* @since 2.25.0
*/
static String decodeNamedPattern(final String pattern) {
-
- // If legacy formatters are enabled, we need to produce output aimed
for `FixedDateFormat` and `FastDateFormat`.
- // Otherwise, we need to produce output aimed for `DateTimeFormatter`.
- // In conclusion, we need to check if legacy formatters enabled and
apply following transformations.
- //
- // | Microseconds | Nanoseconds |
Time-zone
- //
------------------------------+--------------+-------------+-----------
- // Legacy formatter directive | nnnnnn | nnnnnnnnn | X, XX,
XXX
- // `DateTimeFormatter` directive | SSSSSS | SSSSSSSSS | x, xx,
xxx
- //
- // Enabling legacy formatters mean that user requests the pattern to
be formatted using deprecated
- // `FixedDateFormat` and `FastDateFormat`.
- // These two have, let's not say _bogus_, but an _interesting_ way of
handling certain pattern directives:
- //
- // - They say they adhere to `SimpleDateFormat` specification, but use
`n` directive.
- // `n` is neither defined by `SimpleDateFormat`, nor
`SimpleDateFormat` supports sub-millisecond precisions.
- // `n` is probably manually introduced by Log4j to support
sub-millisecond precisions.
- //
- // - `n` denotes nano-of-second for `DateTimeFormatter`.
- // In Java 17, `n` and `N` (nano-of-day) always output nanosecond
precision.
- // This is independent of how many times they occur consequently.
- // Yet legacy formatters use repeated `n` to denote sub-milliseconds
precision of certain length.
- // This doesn't work for `DateTimeFormatter`, which needs
- //
- // - `SSSSSS` for 6-digit microsecond precision
- // - `SSSSSSSSS` for 9-digit nanosecond precision
- //
- // - Legacy formatters use `X`, `XX,` and `XXX` to choose between
`+00`, `+0000`, or `+00:00`.
- // This is the correct behaviour for `SimpleDateFormat`.
- // Though `X` in `DateTimeFormatter` produces `Z` for zero-offset.
- // To avoid the `Z` output, one needs to use `x` with
`DateTimeFormatter`.
- final boolean compat =
InstantPatternFormatter.LEGACY_FORMATTERS_ENABLED;
-
- switch (pattern) {
- case "ABSOLUTE":
- return "HH:mm:ss,SSS";
- case "ABSOLUTE_MICROS":
- return "HH:mm:ss," + (compat ? "nnnnnn" : "SSSSSS");
- case "ABSOLUTE_NANOS":
- return "HH:mm:ss," + (compat ? "nnnnnnnnn" : "SSSSSSSSS");
- case "ABSOLUTE_PERIOD":
- return "HH:mm:ss.SSS";
- case "COMPACT":
- return "yyyyMMddHHmmssSSS";
- case "DATE":
- return "dd MMM yyyy HH:mm:ss,SSS";
- case "DATE_PERIOD":
- return "dd MMM yyyy HH:mm:ss.SSS";
- case "DEFAULT":
- return "yyyy-MM-dd HH:mm:ss,SSS";
- case "DEFAULT_MICROS":
- return "yyyy-MM-dd HH:mm:ss," + (compat ? "nnnnnn" : "SSSSSS");
- case "DEFAULT_NANOS":
- return "yyyy-MM-dd HH:mm:ss," + (compat ? "nnnnnnnnn" :
"SSSSSSSSS");
- case "DEFAULT_PERIOD":
- return "yyyy-MM-dd HH:mm:ss.SSS";
- case "ISO8601_BASIC":
- return "yyyyMMdd'T'HHmmss,SSS";
- case "ISO8601_BASIC_PERIOD":
- return "yyyyMMdd'T'HHmmss.SSS";
- case "ISO8601":
- return "yyyy-MM-dd'T'HH:mm:ss,SSS";
- case "ISO8601_OFFSET_DATE_TIME_HH":
- return "yyyy-MM-dd'T'HH:mm:ss,SSS" + (compat ? "X" : "x");
- case "ISO8601_OFFSET_DATE_TIME_HHMM":
- return "yyyy-MM-dd'T'HH:mm:ss,SSS" + (compat ? "XX" : "xx");
- case "ISO8601_OFFSET_DATE_TIME_HHCMM":
- return "yyyy-MM-dd'T'HH:mm:ss,SSS" + (compat ? "XXX" : "xxx");
- case "ISO8601_PERIOD":
- return "yyyy-MM-dd'T'HH:mm:ss.SSS";
- case "ISO8601_PERIOD_MICROS":
- return "yyyy-MM-dd'T'HH:mm:ss." + (compat ? "nnnnnn" :
"SSSSSS");
- case "US_MONTH_DAY_YEAR2_TIME":
- return "dd/MM/yy HH:mm:ss.SSS";
- case "US_MONTH_DAY_YEAR4_TIME":
- return "dd/MM/yyyy HH:mm:ss.SSS";
+ try {
+ return NamedDatePattern.valueOf(pattern).getPattern();
+ } catch (IllegalArgumentException ignored) {
+ return pattern;
}
Review Comment:
I agree with @vy: since named patterns are the **exception** rather than the
norm, it would be preferable to avoid relying on exception handling for the
typical (non-named) case.
Using an approach like this avoids the performance and readability costs of
control flow via exceptions:
```suggestion
return Arrays.stream(NamedDatePattern.values())
.map(Enum::name)
.filter(pattern::equalsIgnoreCase)
.findAny()
.orElse(pattern);
```
##########
log4j-core/src/main/java/org/apache/logging/log4j/core/pattern/NamedDatePattern.java:
##########
@@ -0,0 +1,114 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to you under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.logging.log4j.core.pattern;
+
+import static
org.apache.logging.log4j.core.util.internal.instant.InstantPatternFormatter.LEGACY_FORMATTERS_ENABLED;
+
+import
org.apache.logging.log4j.core.util.internal.instant.InstantPatternFormatter;
+
+/**
+ * Represents named date & time patterns for formatting log timestamps.
+ *
+ * @see InstantPatternFormatter#LEGACY_FORMATTERS_ENABLED
+ * @see DatePatternConverter
+ * @since 2.26.0
+ */
+public enum NamedDatePattern {
+
+ // If legacy formatters are enabled, we need to produce output aimed for
`FixedDateFormat` and `FastDateFormat`.
+ // Otherwise, we need to produce output aimed for `DateTimeFormatter`.
+ // In conclusion, we need to check if legacy formatters enabled and apply
following transformations.
+ //
+ // | Microseconds | Nanoseconds | Time-zone
+ // ------------------------------+--------------+-------------+-----------
+ // Legacy formatter directive | nnnnnn | nnnnnnnnn | X, XX, XXX
+ // `DateTimeFormatter` directive | SSSSSS | SSSSSSSSS | x, xx, xxx
+ //
+ // Enabling legacy formatters mean that user requests the pattern to be
formatted using deprecated
+ // `FixedDateFormat` and `FastDateFormat`.
+ // These two have, let's not say _bogus_, but an _interesting_ way of
handling certain pattern directives:
+ //
+ // - They say they adhere to `SimpleDateFormat` specification, but use `n`
directive.
+ // `n` is neither defined by `SimpleDateFormat`, nor `SimpleDateFormat`
supports sub-millisecond precisions.
+ // `n` is probably manually introduced by Log4j to support
sub-millisecond precisions.
+ //
+ // - `n` denotes nano-of-second for `DateTimeFormatter`.
+ // In Java 17, `n` and `N` (nano-of-day) always output nanosecond
precision.
+ // This is independent of how many times they occur consequently.
+ // Yet legacy formatters use repeated `n` to denote sub-milliseconds
precision of certain length.
+ // This doesn't work for `DateTimeFormatter`, which needs
+ //
+ // - `SSSSSS` for 6-digit microsecond precision
+ // - `SSSSSSSSS` for 9-digit nanosecond precision
+ //
+ // - Legacy formatters use `X`, `XX,` and `XXX` to choose between `+00`,
`+0000`, or `+00:00`.
+ // This is the correct behaviour for `SimpleDateFormat`.
+ // Though `X` in `DateTimeFormatter` produces `Z` for zero-offset.
+ // To avoid the `Z` output, one needs to use `x` with
`DateTimeFormatter`.
Review Comment:
Of course this comment can be removed once we remove legacy patterns from
this class.
--
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: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
