Product/components used and version/fix level are you on:
Product - webMethods Integration Server
Version - 22.214.171.124
Updates - IS_9.12_Core_Fix22, IS_9.12_SPM_Fix1
Detailed explanation of the problem:
We are facing File logging issues on 9.12 ESB web methods we are using Log4j- 2.17.0 jars
we do have other servers which are running on 10.5 logs with the same versions and are working fine want to confirm the compatibility of the Log4j with methods 9.12 and we are using JDK 1.8jdk in each of the versions
Error messages / full error message screenshot / log fileL
Is your question related to the free trial, or to a production (customer) instance?
Have you installed all the latest fixes for the products and systems you are using?
As per the details provided above
Please provide more information about the issue you are experiencing with log4j (logs, screen shots of flow and/or error, etc…). As log4j is a java library and webMethods is a java product you should be able to use any library without any problems as long as that library supports the environment java version. For that you need to check the documentation of the library you are using. A simple google search will give you that answer.
Also note that 9.12 is pretty old now, even 10.5 will be out of support scope this October. I would rather plan an upgrade or migration instead.
As Java 1.8 and Java 8 are equivalent to each other, this should not be the problem.
More likely there is a classpath conflict when log4j/log4j2 is delivered with the webMethods Suite and if you added the log4j2 jars manually in addition to the deliverd one.
I don’t believe there is a compatibility issue because the log4j functions as expected in other lower environments with the 1.8 JDK.
How might the classpath issue with log4j be resolved since this is a production environment? I have my doubts about trying these things.
I just checked my local wM 9.12 installation and I found a log4j.jar under /common/lib/ext with version 1.2.16.
I doubt that this can be used together with log4j2 jars.
Most likely the wM 10.x stream is using log4j2 itself, so there is a lesser risk for compatibility issues.
Just checking my 10.7 Trial installation, these one seems to come with log4j2 2.10/2.13.
If you rely on newer functions from log4j2, which are not available in log4j v1, and the log4j v1 jar (from IS installation) is loaded before your custom log4j2 jars, you are definitely hitting a classpath loading conflict.