Diese Regel bezieht sich auf Änderungen und Konflikte in der JAXB-Initialisierungsklasse (Java Architecture for XML Binding), die auftreten können, wenn eine Migration von Versionen von WebSphere Application Server vor Version 7.0 durchgeführt wird. Es gibt zwei JAXB-Migrationsszenarien, die zu Problemen mit Kundenanwendungen führen. Das erste Szenario bezieht sich auf Anwendungen, die von WebSphere 6.1 Feature Pack for Web Services migriert werden. Das zweite Szenario bezieht sich auf Kundenanwendungen, die eine JAXB-Implementierung packen und auf WebSphere Version 7.0 oder höher migriert werden.
In WebSphere Version 7.0 wird JAXB 2.1 mit der Laufzeitumgebung Java 6 bereitgestellt.
Vor
Version 7.0 wurde mit WebSphere 6.1 Feature Pack for Web Services JAXB 2.0 bereitgestellt, das eine andere
Initialisierungsklasse als die in JAXB 2.1 oder 2.2 (Version 8.0) verwendete Klasse verwendet.
Wenn die Anwendung die Verwendung der alten Initialisierungsklasse spezifiziert, können Ausnahmen des Typs
"Klasse nicht gefunden" generiert werden, wenn die Anwendung ausgeführt wird.
Die Initialisierungsklasse kann mit der Eigenschaft javax.xml.bind.context.factory definiert werden. Die alte Initialisierungsklasse ist com.sun.xml.bind.ContextFactory.
Wenn der alte Klassenname in der Eigenschaft javax.xml.bind.context.factory definiert wird,
empfangen Sie eine Ausnahme des Typs java.lang.ClassNotFoundException, wenn die mit
Java 6 verfügbaren JAXB-Bibliotheken verwendet werden.
Diese Regel sucht nach der Methode javax.xml.bind.JAXBContext.newInstance, die verwendet wird, um
einen JAXBContext abzurufen. Wenn Sie JAXB verwenden, müssen Sie prüfen, ob Ihre Anwendung
die alte Kontextfactory verwendet. Die Regel erkennt auch die Zeichenfolgeliterale
"com.sun.xml.bind.ContextFactory" und "com.sun.xml.bind.DefaultJAXBContextImpl" in Java-Code, durchsucht aber
keine Eigenschaftendateien, in denen diese Werte häufig definiert werden.
Sie können auch als Java-Systemeigenschaften definiert werden.
JAXB-Eigenschaften werden gewöhnlich aus einer Datei jaxb.properties geladen. Durchsuchen Sie die Eigenschaftendateien Ihrer Anwendung manuell, um festzustellen, ob die alte
Kontextfactory definiert ist.
Wählen Sie Suche > Datei…aus, um die Eigenschaftendateien in Eclipse zu scannen.
Geben Sie com.sun.xml.bind.ContextFactory im Feld
Enthält folgenden Text ein.
Geben Sie *.properties im Feld Muster für Dateinamen ein.
Wiederholen Sie die Suche für die Zeichenfolge com.sun.xml.bind.DefaultJAXBContextImpl.
Wenn Sie JAXB in WebSphere Version 7 oder Version 8 verwenden, wird standardmäßig die
Initialisierungsklasse
com.ibm.xml.xlxp2.jaxb.JAXBContextFactory verwendet, wenn die Eigenschaft
javax.xml.bind.context.factory nicht definiert ist.
Für das zweite Szenario können Kunden, die eine JAXB-Implementierung in ihre Anwendung vor Version 7 packen, ebenfalls die soeben beschriebenen Probleme oder Verhaltensänderungen beobachten, wenn sie eine Migration auf WebSphere Version 7.0 oder höher durchführen. Dies ist der Fall, wenn die Versionen 2.1 und 2.2 von JAXB, die mit der Java-Laufzeitumgebung bereitgestellt werden, anstelle der mit der Anwendung bereitgestellten JAXB-Implementierung geladen werden. Im Artikel Enabling a third-party JAX-WS application in WebSphere Application Server V7 wird beschrieben, wie Sie die Probleme im Klassenladeprogramm umgehen können, wenn Sie Ihre JAXB-Implementierung verwenden möchten.
Weitere Informationen finden Sie in den folgenden Referenzdokumenten: