[
https://issues.apache.org/jira/browse/LOG4J2-3458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514993#comment-17514993
]
Ralph Goers edited comment on LOG4J2-3458 at 3/31/22, 12:17 AM:
----------------------------------------------------------------
This example makes no sense to me. The value of newMessage is supposed to be a
message key. Why is it a file path?
That said, it seems LocalizedMessage is using FormattedMessage to determine the
type of message formatting to use. I see it is using RegEx matching to do that.
We should probably allow the LocalizedMessageFactory to be able to be
configured with the MessageFactory to use when resolving the message rather
than relying completely on the dynamic check.
was (Author: [email protected]):
This example makes no sense to me. The value of newMessage is supposed to be a
message key. Why is it a file path?
That said, it seems LocalizedMessage is using FormattedMessage to determine the
type of message formatting to use. It first tries to format it as a
MessageFormatMessage. If that gets an exception it tries StringFormatMessage.
It that gets an Exception it then tries ParameterizedMessage. What I don't
understand is why you would be seeing the exception from StringFormattedMessage
as that exception is caught and ignored.
> LocalizedMessage causes a lot of noise on the console
> -----------------------------------------------------
>
> Key: LOG4J2-3458
> URL: https://issues.apache.org/jira/browse/LOG4J2-3458
> Project: Log4j 2
> Issue Type: Bug
> Components: API
> Affects Versions: 2.17.2
> Reporter: Gary D. Gregory
> Priority: Major
>
> I have an app where we log data that is percent encoded through a localized
> message factory. We get a ton of noise on the console due to logging of
> internal exceptions, for example:
> ERROR StatusLogger Unable to format msg:
> C:/Program%20Files/Some%20Company/Some%20Product%20Name/
> java.util.UnknownFormatConversionException: Conversion = 'F'
> at java.util.Formatter$FormatSpecifier.conversion(Formatter.java:2691)
> at java.util.Formatter$FormatSpecifier.<init>(Formatter.java:2720)
> at java.util.Formatter.parse(Formatter.java:2560)
> at java.util.Formatter.format(Formatter.java:2501)
> at java.util.Formatter.format(Formatter.java:2455)
> at java.lang.String.format(String.java:2981)
> at
> org.apache.logging.log4j.message.StringFormattedMessage.formatMessage(StringFormattedMessage.java:116)
> at
> org.apache.logging.log4j.message.StringFormattedMessage.getFormattedMessage(StringFormattedMessage.java:88)
> at
> org.apache.logging.log4j.message.FormattedMessage.getFormattedMessage(FormattedMessage.java:178)
> at
> org.apache.logging.log4j.message.LocalizedMessage.getFormattedMessage(LocalizedMessage.java:196)
> at
> org.apache.logging.log4j.message.LocalizedSimpleMessageFactoryTest.testNoMatchPercentInMessage(LocalizedSimpleMessageFactoryTest.java:79)
> I updated this test to demonstrate:
> [https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-api/src/test/java/org/apache/logging/log4j/message/LocalizedMessageFactoryTest.java]
> In a nutshell:
> {code:java}
> @Test
> public void testNoMatchPercentInMessage() {
> final LocalizedMessageFactory localizedMessageFactory = new
> LocalizedMessageFactory(ResourceBundle.getBundle("MF", Locale.US));
> final Message message =
> localizedMessageFactory.newMessage("C:/Program%20Files/Some%20Company/Some%20Product%20Name/");
>
> assertEquals("C:/Program%20Files/Some%20Company/Some%20Product%20Name/",
> message.getFormattedMessage());
> }
> {code}
> Options:
> - Don't log the exception (simple)
> - Log at the TRACE level instead of ERROR.
> - Provide a better simpler localized MessageFactory that does not perform %
> substitution
> - ?
> I read the Javadoc that says that using a localized MessageFactory is not
> preferred, but it would be a large change for our app.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
