Cette règle est liée aux conflits et aux modifications de la classe d'initialisation de la liaison XML (JAXB) pouvant survenir lors de la migration depuis des versions de WebSphere Application Server antérieures à la version 7.0. Deux scénarios de migration JAXB peuvent générer des problèmes avec les applications client. Le premier concerne les applications migrées à partir de WebSphere 6.1 Feature Pack for Web Services. Le deuxième concerne les applications client qui conditionnent une implémentation JAXB et qui sont migrées vers la version 7.0 ou une version ultérieure de WebSphere.
Dans WebSphere version 7.0, JAXB 2.1 est livré avec l'environnement d'exécution Java 6.
Avant la version 7.0, WebSphere 6.1 Feature Pack for Web Services fournissait JAXB 2.0, qui utilisait une classe d'initialisation différente de celle qui est utilisée dans JAXB 2.1 ou 2.2 (version 8.0).
Si l'application spécifie l'utilisation de l'ancienne classe d'initialisation, des exceptions signalant que la classe est introuvable peuvent être générées lors de l'exécution de l'application.
La classe d'initialisation peut être définie avec la propriété javax.xml.bind.context.factory. L'ancienne classe d'initialisation est com.sun.xml.bind.ContextFactory.
Si le nom de l'ancienne classe est défini dans la propriété javax.xml.bind.context.factory, vous obtiendrez une exception java.lang.ClassNotFoundException lorsque vous utiliserez les bibliothèques JAXB disponibles avec Java 6.
Cette règle recherche la méthode javax.xml.bind.JAXBContext.newInstance qui est utilisée pour obtenir un objet JAXBContext. Si vous utilisez JAXB, déterminez si votre application utilise l'ancienne fabrique de contexte. La règle détecte aussi les littéraux de type chaîne
"com.sun.xml.bind.ContextFactory" ou "com.sun.xml.bind.DefaultJAXBContextImpl" dans le code Java, mais n'analyse pas les fichiers de propriétés dans lesquels ces valeurs sont souvent définies.
Ces dernières peuvent également être définies dans des propriétés système Java.
En général, les propriétés JAXB sont chargées à partir d'un fichier jaxb.properties. Analysez manuellement les fichiers de propriétés de votre application pour déterminer si l'ancienne fabrique de contexte est définie.
Pour analyser les fichiers de propriétés dans Eclipse, sélectionnez Rechercher > Fichier....
Dans la zone Contenant le texte, entrez com.sun.xml.bind.ContextFactory.
Dans la zone Masques de nom de fichier, entrez *.properties.
Répétez la recherche pour la chaîne com.sun.xml.bind.DefaultJAXBContextImpl.
Si vous utilisez JAXB dans WebSphere version 7 ou 8, la classe d'initialisation par défaut est com.ibm.xml.xlxp2.jaxb.JAXBContextFactory si aucune propriété javax.xml.bind.context.factory n'est définie.
Dans le deuxième scénario, les clients qui conditionnent une implémentation JAXB dans leur application antérieure à la version 7 peuvent également rencontrer les problèmes décrits ou des changements de comportement lors de la migration vers la version 7.0 ou une version ultérieure de WebSphere. Tel est le cas lorsque les versions JAXB 2.1 et 2.2 mises à disposition avec l'environnement d'exécution Java sont chargées à la place de l'implémentation JAXB livrée avec l'application. L'article Enabling a third-party JAX-WS application in WebSphere Application Server 7 décrit les solutions palliatives aux problèmes de chargeur de classe qui vous permettront de continuer à utiliser votre implémentation JAXB.
Pour plus d'informations, voir les références suivantes :