Migrating to log4j2

With the 22.1 minor update 1 release, IBM Sterling Order Management System uses log4j2 for the logging and does not ship the log4j v1.2.17.jar file.

The YFCLogCategory class that is primarily used for logging by the Sterling Order Management System code and also used by the customer code does not extend org.apache.log4j.Category, which is a log4j 1.x class. Your custom code is impacted with this release if you are using methods that are not defined by the YFCLogCategory class. Methods that are not defined by the YFCLogCategory class and are available from the org.apache.log4j.Category parent class, are not supported.

After you apply the 22.1 minor update 1 release, you can look at methods in the updated core Javadoc. The following methods are added to the YFCLogCategory class to ensure that no runtime failures of the custom code occur. However, these are dummy methods and might be removed in a later release.

public void log(Object level, Object obj)
public void setLevel(Object level)
public boolean isEnabledFor(Object level)

Custom code changes

Important:

The YFCLogCategory.getLogger() method is not supported. Use the YFCLogCategory.instance(Class.class) method instead.

For example,

private static YFCLogCategory logger = YFCLogCategory.instance(MyClassName.class);

Check your custom code and make the following changes:

If you are casting the YFCLogCategory instance to org.apache.log4j.Category or org.apache.log4j.Logger, it is not supported. Casting an instance of YFCLogCategory to org.apache.log4j.Logger or org.apache.log4j.Category does not compile when writing new code. For existing custom code that has these casts, the custom code encounters the ClassCastException at run time. For example, line #2 and #3 from the following code pattern are not supported.
```
YFCLogCategory LOGGER = YFCLogCategory.instance(MyClass.class.getName());
org.apache.log4j.Logger apLogger=(org.apache.log4j.Logger)LOGGER;          // Not supported
org.apache.log4j.Category apCategory=(org.apache.log4j.Category)LOGGER;    // Not supported
```
If you are calling log(Level level, Object), replace it with specific methods such as error(Object) or debug(Object) that are provided by the YFCLogCategory class.
If you are calling setLevel(Level level), you must delete it. You cannot change levels of loggers in log4j2 because it is not supported in the log4j2 API. Further management of log levels is done by the code, and you must create traces for specific parts of the code for which you want extended logging.
If you are calling isEnabledFor(Level level), replace it with specific methods such as isInfoEnabled or isTimerEnabled.

Removing log4j-1.2.17.jar

Sterling Order Management System is removing the log4j 1.2.17 Jar from its shipped Jar for security reasons and so you must remove all direct calls to org.apache.log4j.* classes. If you are not able to remove the calls or imports of org.apache.log4j.* classes, then you must include the log4j 1.2.17 Jar in your customization package by downloading it from the Apache official site.

Make the following code changes:

Remove org.apache.log4j.Logger and use YFCLogCategory.
Remove org.apache.log4j.Level and use specific methods in YFCLogCategory.

Packaging log4j-1.2.17.jar

IBM recommends not to use any Apache log4j (v2 or v1) classes directly. You can use YFCLogCategory, which prevents you from getting exposed to changes in the underlying logging API in Sterling Order Management System.

If you are packaging log4j 1.x Jar in the customization package, which is before the 1.2.17 version, and if you need log4j 1.x Jar to support your custom code dependencies, you must remove the old Jar and package log4j-1.2.17.jar.

Note: Packaging log4j-1.2.17.jar is a temporary option. log4j-1.2.17.jar is deprecated and no support is available from Apache. IBM will restrict the packaging of log4j-1.2.17.jar in future releases.

Third-party libraries

If you have third-party libraries that have dependencies on log4j 1.x Jars, search for such Jars by running the following command against the extracted contents of the third-party Jar file that you are packaging in the customization package.

jar -xvf <third-party jar>
grep -rnw 'org.apache.log4j'

This command prints classes that have dependency on the log4j 1.x Jar. If you find any results, you must check whether an updated version of that Jar file is available.

Some logging related third-party libraries such as slf4j or commons-logging might have the log4j 1.x Jar dependency but you can ignore these libraries.