Większość klas w pakietach weblogic.apache jest nieaktualna i zawiera instrukcje dotyczące używania klas org.apache lub analizatorów składni i transformatorów XML dostarczonych w ramach pakietu JDK (Java Development Kit). Ta reguła wykrywa odwołania do pakietów weblogic.apache. W skorowidzu BEA WebLogic Server API Reference należy kliknąć pakiet weblogic.apache, aby uzyskać konkretne informacje o tym, jak należy odwzorować każdą nieaktualną klasę na odpowiadającą jej klasę zastępczą.
RozwiązaniaWiększość pakietów weblogic.apache.xerces wskazuje, że zamiast nieaktualnych interfejsów API należy używać analizatorów składni i transformatorów XML dostarczonych w ramach pakietu JDK.
WebLogicPrzedstawiono tu prosty przykład analizatora DOMParser bez logiki try/catch. W produkcie WebLogic fragment kodu może wyglądać podobnie do tego, który przedstawiono w następującym przykładzie:
Sprawdzona procedura w przypadku serwera WebSphere Application Server traditional lub serwera Liberty polega na użyciu interfejsów Java API JAXP zamiast interfejsów API weblogic.apache. Jeśli zostanie wybrane to rozwiązanie, kod może wyglądać podobnie do tego, który przedstawiono w następującym przykładzie:
Jeśli interfejsy API weblogic.apache są używane intensywnie, najprostszym podejściem do konwersji aplikacji jest użycie zautomatyzowanej poprawki, gdy stanie się dostępna, która mapuje klasy weblogic.apache, które są dostępne w pakietach org.apache do odpowiedników open source odpowiednik.
Gdy automatyczna poprawka stanie się dostępna i zostanie zastosowana, kod Apache musi zostać pobrany i dołączony do ścieżki kompilacji aplikacji, aby aplikacja mogła zostać skompilowana. Wymagane pliki JAR znajdują się w projekcie Apache Xerces Java XML Parser. Większość interfejsów API znajduje się w plikach xercesImpl.jar i serializer.jar. Należy postępować zgodnie z obowiązującym w firmie procesem dotyczącym pobierania i certyfikowania kodu typu Open Source.
Użycie kodu typu Open Source powoduje, że migrowany kod jest podobny do następującego przykładu: