[ https://issues.apache.org/jira/browse/LOG4J2-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15646724#comment-15646724 ]
Joern Huxhorn commented on LOG4J2-1226: --------------------------------------- OK, with {{Throwable}} as additional argument to log(message) methods everything works as expected. With the behavior right now, {{Throwable getThrowable();}} should probably be removed from the {{Message}} interface. But that won't work either since {{Message}} creation is hidden in an exchangeable {{MessageFactory2}}, ruling out explicit calling of a method not defined in the interface. I think {{log(Message)}} methods should check {{Message.getThrowable()}} and use any {{Throwable}} it might find, e.g. {code:java} public void debug(final Message msg) { logIfEnabled(FQCN, Level.DEBUG, null, msg, msg.getThrowable()); } {code} instead of {code:java} public void debug(final Message msg) { logIfEnabled(FQCN, Level.DEBUG, null, msg, null); } {code} But that would be an entirely different issue. Should I create one? Anyway, I'll close this one. Thanks for seeing this through. > Message instances are simply serialized. They mustn't. > ------------------------------------------------------ > > Key: LOG4J2-1226 > URL: https://issues.apache.org/jira/browse/LOG4J2-1226 > Project: Log4j 2 > Issue Type: Bug > Components: API > Affects Versions: 2.5 > Reporter: Joern Huxhorn > Assignee: Remko Popma > Fix For: 2.8 > > > Right now, any Message instance used to call any log method are simply sent > as they are. > Instead, the {{Throwable}} must be transformed into a {{ThrowableProxy}}. > Custom {{Message}} implementations must be transformed into one of log4j's > standard message implementations and care must be taken to convert the > {{Parameters}} {{Object[]}} into {{String[]}} before the message is > serialized. > Otherwise, deserialization will fail if a custom {{Throwable}}, custom > {{Message}} or custom parameter is not contained in the classpath of the > application receiving the serialized {{LogEvent}}. > I found those issues while implementing the circumvention for [Apache Commons > statement to widespread Java object de-serialisation > vulnerability|https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread] > in [Lilith|http://lilithapp.com]. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org