Issue with Log4j2 on AIX IBM JRE on WL12c

Detailed about the Log4j2 not working with WL12c issue.

There were multiple issues. Basically I can classify them in 2 categories

  • Log4j2 had includes functionality for Xinclude. It ran without issue on Dev’s local machine (Sun java runtime) but gave below error on QA server (IBM runtime). The IBM runtime failed parsing the log4j2 configuration with error –

<Sep 11, 2017 9:28:30 PM GMT> <Notice> <StdErr> <xxxxxxx> <xxxxxxx> <ExecuteThread: ‘4’ for queue: ‘weblogic.kernel.System’> <<WLS Kernel>> <> <> <1505165310988> <BEA-000000> <ERROR StatusLogger Error parsing /opt/bea/domains/xxxxx/xxxxx/log4j2.xml>

<Sep 11, 2017 9:28:30 PM GMT> <Notice> <StdErr> <xxxxx> <xxxxxx> <ExecuteThread: ‘4’ for queue: ‘weblogic.kernel.System’> <<WLS Kernel>> <> <> <1505165310994> <BEA-000000> <javax.xml.parsers.ParserConfigurationException: Feature ‘http://apache.org/xml/features/xinclude&#8217; is not recognized.>

Xerces supported the Xinclude functionality in 2.8 (2.7 supports as well but had some bug related to Xinclude).

So we did 2 things –

    1. explicitly include xerces version we needed in ear and
    2. modified weblogic-application.xml to force the class loader to load our version over the version provide by WL container. (container also 2.8.x version but we didn’t want to rely on container)

Even after the above changes, the error persisted. It turns out in AIX JRE there is flag that indicates if Xerces uses Xinclude aware parser. This would be enabled either at JDK level or as startup parameter. We included

-Dorg.apache.xerces.xni.parser.XMLParserConfiguration=org.apache.xerces.parsers.XIncludeAwareParserConfiguration

This fixed the Xinclude issue.

  • Now the issue was the Log4j2 configuration was not being honored. That is, If package x.y.z was configured at debug level in log4j property, we still did not see any debug logs for x.y.z in the log file.

The issue was their were multiple logging jar that were include in ear, in domain’s lib directory and other places, there no clarity of which jar were taking precedence in the class loader hierarchy.

  1. So I worked with dev to clean up the unwanted jars.
  2. We explicitly included the needed slf4j and log4j jar in the ear itself.
  3. Modified weblogic-application.xml to force the class loader to load our version over the version provide by WL container.

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s