Migration vers log4j2

Avec la version 22.1 minor update 1, IBM Sterling® Order Management System utilise log4j2 pour la journalisation et ne fournit pas le fichier log4j v1.2.17.jar.

La classe YFCLogCategory qui est principalement utilisée pour la journalisation par le code Sterling™ Order Management System et également utilisée par le code client n'étend pas org.apache.log4j.Category, qui est une classe log4j 1.x Votre code personnalisé est impacté par cette édition si vous utilisez des méthodes qui ne sont pas définies par la classe YFCLogCategory . Les méthodes qui ne sont pas définies par la classe YFCLogCategory et qui sont disponibles à partir de la classe parent org.apache.log4j.Category ne sont pas prises en charge.

Après avoir appliqué l'édition 22.1 mineure mise à jour 1 , vous pouvez consulter les méthodes dans le Javadoc de base mis à jour. Les méthodes suivantes sont ajoutées à la classe YFCLogCategory pour s'assurer qu'aucun échec d'exécution du code personnalisé ne se produit. Toutefois, il s'agit de méthodes factices qui peuvent être supprimées dans une édition ultérieure.

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

Modifications du code personnalisé

IMPORTANT :

La méthode YFCLogCategory.getLogger() n'est pas prise en charge. Utilisez la méthode YFCLogCategory.instance(Class.class) à la place.

Exemple :

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

Vérifiez votre code personnalisé et apportez les modifications suivantes:

Si vous transtyper l'instance YFCLogCategory vers org.apache.log4j.Category ou org.apache.log4j.Logger, elle n'est pas prise en charge. Le transtypage d'une instance de YFCLogCategory en org.apache.log4j.Logger ou org.apache.log4j.Category ne se compile pas lors de l'écriture d'un nouveau code. Pour le code personnalisé existant qui comporte ces transtypages, le code personnalisé rencontre ClassCastException lors de l'exécution. Par exemple, les lignes #2 et #3 du modèle de code suivant ne sont pas prises en charge.
```
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
```
Si vous appelez log(Level level, Object), remplacez-le par des méthodes spécifiques telles que error (Object) ou debug (Object) qui sont fournies par la classe YFCLogCategory .
Si vous appelez setLevel(Level level), vous devez le supprimer. Vous ne pouvez pas modifier les niveaux de consignateurs dans log4j2 car il n'est pas pris en charge dans l'API log4j2 . Une gestion plus poussée des niveaux de journalisation est effectuée par le code et vous devez créer des traces pour des parties spécifiques du code pour lesquelles vous souhaitez une journalisation étendue.
Si vous appelez isEnabledFor(Level level), remplacez-le par des méthodes spécifiques telles que isInfoEnabled ou isTimerEnabled.

Retrait de log4j-1.2.17.jar

Sterling Order Management System supprime le fichier JAR log4j 1.2.17 de son fichier JAR fourni pour des raisons de sécurité. Vous devez donc supprimer tous les appels directs aux classes org.apache.log4j.* . Si vous ne parvenez pas à supprimer les appels ou les importations des classes org.apache.log4j.* , vous devez inclure le fichier JAR log4j 1.2.17 dans votre package de personnalisation en le téléchargeant à partir du site officiel Apache .

Effectuez les modifications de code suivantes:

Supprimez org.apache.log4j.Logger et utilisez YFCLogCategory.
Supprimez org.apache.log4j.Level et utilisez des méthodes spécifiques dans YFCLogCategory.

Conditionnement log4j-1.2.17.jar

IBM recommande de ne pas utiliser directement les classes Apache log4j (v2 ou v1). Vous pouvez utiliser YFCLogCategory, qui vous empêche d'être exposé aux modifications apportées à l'API de journalisation sous-jacente dans Sterling Order Management System.

Si vous conditionnez le fichier JAR log4j 1.x dans le package de personnalisation, qui est antérieur à la version 1.2.17 , et si vous avez besoin du fichier JAR log4j 1.x pour prendre en charge vos dépendances de code personnalisé, vous devez supprimer l'ancien fichier JAR et le package log4j-1.2.17.jar.

Remarque: Packaging log4j-1.2.17.jar est une option temporaire. log4j-1.2.17.jar est obsolète et aucune prise en charge n'est disponible à partir d' Apache. IBM limitera le conditionnement de log4j-1.2.17.jar dans les éditions futures.

Bibliothèques tierces

Si vous disposez de bibliothèques tierces qui ont des dépendances sur des fichiers JAR log4j 1.x , recherchez ces fichiers JAR en exécutant la commande suivante sur le contenu extrait du fichier JAR tiers que vous conditionnez dans le package de personnalisation.

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

Cette commande imprime les classes qui dépendent du fichier Jar log4j 1.x . Si vous trouvez des résultats, vous devez vérifier si une version mise à jour de ce fichier Jar est disponible.

Certaines bibliothèques tierces liées à la journalisation, telles que slf4j ou commons-logging, peuvent avoir la dépendance log4j 1.x Jar, mais vous pouvez ignorer ces bibliothèques.