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.

Arrêt de la commercialisation des pots d' log4j-1.x

Les log4j-1.x fichiers jar ne sont pas pris en charge dans le système IBM Sterling Order Management dans le cadre du package de personnalisation du client.

Arrêt de la distribution des fichiers jar de transition d' log4j1 s à log4j2

Les bocaux de transition entre l' log4j1 et l' log4j2 ne sont pas pris en charge. Par exemple, l'ajout log4j-1.2-api-2.17.1.jar à un package de personnalisation n'est pas pris en charge.

Bibliothèques tierces

Vous devez mettre à jour votre code personnalisé ou mettre à niveau tous les fichiers jar tiers qui dépendent encore d' log4j-1.x. Log4j-1.x est obsolète et n'est plus pris en charge par Apache. Si vous disposez de bibliothèques tierces qui nécessitent encore log4j 1.x, il s'agit probablement de bibliothèques obsolètes. Vous devez migrer vers la dernière version de ces bibliothèques tierces ou rechercher des alternatives plus sûres si les bibliothèques sont mises à jour pour utiliser log4j2.