Enterprise-Bean-Code auf die unterstützte Spezifikation migrieren

Dieses Produkt unterstützt die Spezifikation Enterprise JavaBeans (EJB) 3.1 .

Vorbereitungen

Bei der Verwendung von Beans der EJB Version 3.x sollten keine Migrationsprobleme auftreten. Vorhandene Anwendungen sollten weiterhin unverändert ausgeführt und fehlerfrei kompiliert werden.
Anmerkung: Die Spezifikationen EJB 3.0 und EJB 3.1 unterstützen die Verwendung von Entity-Beans im Stil von EJB 1.1 nicht mehr. Während die Verwendung von Modulen der EJB Version 2.x und früher im Produkt noch nicht veraltet ist, wird empfohlen, mit der Migration auf Java™ Persistence API (JPA) oder JDBCzu beginnen.

Informationen zu dieser Task

Führen Sie von den folgenden Schritten die für die Implementierung Ihrer Anwendung erforderlichen Schritte aus.

Vorgehensweise

  1. Modifizieren Sie den Enterprise-Bean-Code entsprechend den Änderungen der Spezifikation.

    Sie müssen die Beans der Version 1.1 auf Beans der Version 2.x migrieren und sie erneut im Produkt implementieren. Weitere Informationen finden Sie unter Enterprise-Bean-Code von Version 1.1 auf Version 2.1 migrieren.

    Hinweis: Die Spezifikation der EJB-Version 2.0 schreibt vor, dass vor der Ausführung einer findByMethod-Abfrage durch den EJB-Container der Zustand aller in die aktuelle Transaktion aufgenommenen Enterprise Beans mit dem persistenten Speicher synchronisiert wird. Dies ist notwendig, damit die Abfrage für aktuelle Daten ausgeführt wird. Werden Beans der Version 1.1 erneut zu einem Modul gemäß EJB 2.x assembliert, synchronisiert der EJB-Container sowohl den Status von Beans der Version 1.1 als auch den Status von Beans der Version 2.x. Im Ergebnis dieses Prozesses kann es zu Änderungen des Anwendungsverhaltens kommen, obwohl sich der Anwendungscode der Beans von Version 1.1 nicht geändert hat.
  2. [AIX Solaris HP-UX Linux Windows] Stellen Sie sicher, dass WebSphere® Application Server 64-Bit-Kompatibilität ist.
    Dies ist kein Problem für eine reine Java-Anwendung. Wenn Ihr Anwendungscode jedoch JNI-Code (JNI = Java Native Interface) verwendet, müssen Sie Folgendes beachten: JNI ermöglicht Java-Code, der auf einer virtuellen Maschine ausgeführt wird, mit Anwendungen und Bibliotheken zu arbeiten, die in anderen Sprachen geschrieben sind, z. B. C, C + + und Assembly. Es ist möglich, dass die JNI-Aufrufe nach der Kompilierung anders sind, weil sich die JNI-Spezifikationen von Version zu Version ändern können.
  3. Assemblieren Sie erneut und implementieren Sie alle Module erneut, um migrierten Code zu integrieren