Nie używaj wywołań interfejsu API implementacji Kodo

Serwer WebLogic używa interfejsu Kodo jako swojej implementacji technologii JPA 1.0. Ta reguła umożliwia wykrycie klas kodo.* i com.solarmetric.*. Interfejs Kodo jest oparty na interfejsie OpenJPA.
Podobnie interfejs OpenJPA był domyślnym dostawcą technologii JPA 1.0 i 2.0 w produkcie WebSphere. Jednak począwszy od standardu JPA 2.1, produkt WebSphere używa interfejsu EclipseLink jako domyślnego dostawcy JPA.

Rozwiązanie

Jeśli aplikacja używa interfejsu Kodo, najprostszym rozwiązaniem migracji aplikacji jest użycie interfejsu JPA 2.0. Użycie interfejsu JPA 2.0 będzie wymagać mniejszych zmian aplikacji niż w przypadku najnowszej wersji technologii JPA, ponieważ interfejs Kodo jest oparty na interfejsie OpenJPA, który jest także implementacją używaną przez produkt WebSphere na potrzeby obsługi interfejsu JPA 2.0. Jednak implementacja JPA 2.1 i nowsze są oparte na interfejsie EclipseLink. Różnice w implementacjach standardu JPA oznaczają, że istnieje możliwość wystąpienia zmian w zachowaniu aplikacji. Ponadto właściwości dostępne w interfejsie Kodo mogą nie mieć odpowiadających właściwości w interfejsie EclipseLink.
Następujące zalecenia dotyczą obu opcji migracji:

• Opcja 1: użycie interfejsu JPA 2.1 lub nowszego

  Jeśli użytkownik jest zainteresowany migracją do najnowszej specyfikacji standardu JPA, migracja będzie wymagać dodatkowego planowania i analiz. Jest dostępnych kilka zasobów dotyczących migracji z interfejsu OpenJPA do interfejsu EclipseLink. Ponieważ interfejs Kodo jest oparty na interfejsie OpenJPA, porady dotyczące interfejsu OpenJPA zwykle stosują się także do interfejsu Kodo. Informacje na temat migracji z interfejsu Kodo/OpenJPA do interfejsu EclipseLink zawierają następujące artykuły:

  • EclipseLink Dokumentacja Notatka: W Kodo dostępnych jest również kilka klas OpenJPA pod nieco inną nazwą. Pełną listę znanych klas interfejsu Kodo, które istnieją także w interfejsie OpenJPA, zawiera opis reguł migracji z interfejsu Kodo do interfejsu OpenJPA.
    
  • Różnice między interfejsami EclipseLink i WSJPA
• Opcja 2: użycie interfejsu JPA 2.0

  Jeśli celem jest szybsza migracja, prostsze rozwiązanie to migracja aplikacji do interfejsu JPA 2.0. W tym przypadku można skorzystać z kodo to OpenJPA i zautomatyzowane poprawki, które zostaną dostarczone należy przejść do okna dialogowego wyboru reguł i zaznaczyć kategorię JPA 2.0 w kategorii WebLogic JPA Migration. Spowoduje to włączenie zestawu reguł migrujących znane klasy i właściwości interfejsu Kodo do interfejsu OpenJPA. Należy także usunąć zaznaczenie pola wyboru JPA 2.1 w celu wyłączenia reguł dotyczących standardu JPA 2.1.
  Po wprowadzeniu niezbędnych zmian w aplikacji należy skonfigurować serwer aplikacji pod kątem używania standardu JPA 2.0 zamiast JPA 2.1.

  • W przypadku migrowania do serwera WebSphere Liberty można włączyć składnik jpa-2.0 w pliku server.xml. Uwaga: mimo że interfejs JPA 2.0 jest częścią specyfikacji Java EE 6, składnik jpa-2.0 jest obsługiwany w środowiskach Java EE 6 i Java EE 7. Jednak składnik jpa-2.0 nie będzie obsługiwany w środowisku Java EE 8.
  • W przypadku migracji do produktu WebSphere traditional 9 można zmienić domyślnego dostawcę JPA na interfejs WSJPA (zamiast interfejsu EclipseLink) – wersję interfejsu OpenJPA udostępnianą przez produkt WebSphere. Patrz Patrz Konfigurowanie interfejsu OpenJPA/WSJPA jako domyślnego dostawcy dla produktu WebSphere traditional 9, aby uzyskać szczegóły na temat zmiany domyślnego dostawcy JPA w produkcie WebSphere traditional.

Dodatkowe zasoby:

• Dostawcy JPA serwera WebSphere Application Server
• WebLogic Kodo Documentation (Dokumentacja interfejsu Kodo serwera WebLogic)