1. Sehen Sie sich zuerst an, wie Ihr Applikation gepackt ist und welche Abhängigkeiten Sie besitzt. Weitere Informationen finden Sie hier Abschnitt 3.1.2.3, »Aktualisierung der Applikationsabhängigkeiten aufgrund von Klassenladeänderungen«
2. Falls Ihre Applikation ein Protokoll führt, so müssen Sie die korrekten Modulabhängigkeiten festlegen. Unter Abschnitt 3.1.4.1, »Bearbeitung von Protokollierungsabhängigkeiten« erfahren Sie mehr dazu.
3. Aufgrund der Änderungen beim modularen Klassenladen kann es sein, dass Sie die Packstruktur Ihres EAR oder WAR ändern müssen. Weitere Informationen finden Sie unter Abschnitt 3.1.5.1, »Modifizierung des Packagings von EARs und WARs« .

Prozedur 3.1. Modulabhängigkeiten verstehen

1. Implizite Modulabhängigkeiten verstehen

   Die Deployer innerhalb des Servers fügen implizit automatisch einige häufig verwendete Modulabhängigkeiten hinzu, wie etwa javax.api und sun.jdk. Dies macht die Klassen für das Deployment zur Runtime sichtbar, so dass der Entwickler die Abhängigkeiten nicht explizit hinzufügen muss. Informationen dazu, wie und wann diese impliziten Abhängigkeiten hinzugefügt werden, finden Sie unter Implicit Module Dependencies im Kapitel Class Loading and Modules des Development Guide für die JBoss EAP 6 unter https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/.

2. Explizite Modulabhängigkeiten verstehen

   Für andere Klassen müssen Module explizit festgelegt werden, da die fehlenden Abhängigkeiten ansonsten zu Deployment- oder Runtime-Fehlern führen. Falls eine Abhängigkeit fehlt, so sehen Sie ClassNotFoundExceptions oder NoClassDefFoundErrors-Traces im Serverprotokoll. Lädt mehr als ein Moduldasselbe JAR oder ein Modul lädt eine Klasse, die eine von einem anderen Modul geladene Klasse erweitert, so sehen Sie ClassCastExceptions-Traces im Serverprotokoll. Um Abhängigkeiten explizit festzulegen, bearbeiten Sie MANIFEST.MF oder erstellen Sie eine JBoss-spezifische Deployment-Deskriptor-Datei jboss-deployment-structure.xml. Weitere Informationen zu Modulabhängigkeiten finden Sie unter Overview of Class Loading and Modules im Kapitel Class Loading and Module des Development Guide für die JBoss EAP 6 unter https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/.

Prozedur 3.2. Speicherort der ResourceBundle Properties ändern

1. Falls Sie ein WAR-Archiv deployen, so müssen Sie diese Properties in den WEB-INF/classes/-Ordner des WAR packen.
2. Sollen diese Properties allen Komponenten in einem EAR zugänglich sein, so müssen Sie diese im root eines JARs verpacken und das JAR im lib/-Ordner des EAR platzieren.

Prozedur 3.3. Maßgeschneidertes Modul erstellen

1. Erstellen Sie die module/-Verzeichnisstruktur und pflegen Sie die relevanten Daten ein.
   1. Erstellen Sie eine Verzeichnisstruktur unter dem EAP_HOME/module-Verzeichnis, die die Dateien und JARs enthält. Zum Beispiel:

      $ cd EAP_HOME/modules/ 
      $ mkdir -p myorg-conf/main/properties

   2. Verschieben Sie die Properties-Dateien in das EAP_HOME/modules/myorg-conf/main/properties/-Verzeichnis, das Sie im vorherigen Schritt erstellt haben.
   3. Erstellen Sie eine module.xml-Datei im EAP_HOME/modules/myorg-conf/main/-Verzeichnis, die folgende XML enthält:

      <module xmlns="urn:jboss:module:1.1" name="myorg-conf">
          <resources>
              <resource-root path="properties"/>
          </resources>
      </module>

2. Bearbeiten Sie das ee-Subsystem in der Server-Konfigurationsdatei. Sie können das JBoss CLI verwenden oder die Datei manuell bearbeiten.
   • Befolgen Sie diese Schritte zur Bearbeitung der Server-Konfigurationsdatei mittels des JBoss CLI.
     1. Starten Sie den Server und verbinden Sie sich mit dem Management-CLI.
        • In Linux geben Sie folgendes in der Befehlszeile ein:

           EAP_HOME/bin/jboss-cli.sh --connect

        • In Windows geben Sie Folgendes in die Befehlszeile ein:

          C:\>EAP_HOME\bin\jboss-cli.bat --connect

        Sie sollten die folgende Antwort sehen:

        Connected to standalone controller at localhost:9999

     2. Um das myorg-conf <global-modules> Element im ee Subsystem zu erstellen, geben Sie folgenden Befehl in die Befehlszeile ein:

        /subsystem=ee:write-attribute(name=global-modules, value=[{"name"=>"myorg-conf","slot"=>"main"}])

        Sie sollten das folgende Ergebnis sehen:

        {"outcome" => "success"}

   • Führen Sie folgende Schritte aus, um die Server-Konfigurationsdatei manuell zu bearbeiten.
     1. Stoppen Sie den Server und öffnen Sie die Server-Konfigurationsdatei in einem Texteditor. Für einen Standalone Server ist dies die EAP_HOME/standalone/configuration/standalone.xml-Datei, für eine Managed Domain ist es die EAP_HOME/domain/configuration/domain.xml-Datei.
     2. Suchen Sie das ee-Subsystem und fügen Sie das allgemeine Modul für myorg-conf hinzu. Nachfolgend sehen Sie ein Beispiel für das ee-Subsystem-Element, das derart bearbeitet wurde, um das myorg-conf-Element zu enthalten:

        Beispiel 3.1. myorg-conf Element

        <subsystem xmlns="urn:jboss:domain:ee:1.0" >            
            <global-modules>
                <module name="myorg-conf" slot="main" />            
            </global-modules>
        </subsystem>

3. Wenn Sie eine Datei namens my.properties in den korrekten Modul-Speicherort kopiert haben, so können Sie jetzt Properties-Dateien mittels Code ähnlich dem folgenden laden:

   Beispiel 3.2. Properties-Datei laden

   Thread.currentThread().getContextClassLoader().getResource("my.properties");

Prozedur 3.4. Aktualisierung des Protokollierungscodes der Applikation

1. Abschnitt 3.1.4.2, »Aktualisierung des Applikationscodes für Protokollierungs-Frameworks von Drittanbietern«
2. Abschnitt 3.1.4.3, »Bearbeitung des Codes zur Verwendung des neuen JBoss Logging Framework«

Prozedur 3.5. Konfigurieren Sie die JBoss EAP 6 zur Verwendung einer log4j.properties- oder log4j.xml-Datei

1. Erstellen Sie eine jboss-deployment-structure.xml mit folgendem Inhalt:

   <jboss-deployment-structure>
       <deployment>
           <!-- Exclusions allow you to prevent the server from automatically adding some dependencies -->
           <exclusions>
               <module name="org.apache.log4j" />
           </exclusions>
       </deployment>
   </jboss-deployment-structure>
   

2. Platzieren Sie die jboss-deployment-structure.xml Datei entweder im META-INF/ oder im WEB-INF/ Verzeichnis, wenn Sie ein WAR deployen, oder im META-INF/ Verzeichnis, wenn Sie ein EAR deployen. Wenn Ihr Deployment abhängige untergeordnete Deployments umfasst, müssen Sie auch die Module für jedes Subdeployment ausschließen.
3. Schließen Sie die log4j.properties- oder log4j.xml-Datei im lib/-Verzeichnis Ihres EAR- oder dem WEB-INF/classes/-Verzeichnis Ihres WAR-Deployment ein. Falls Sie es vorziehen, die Datei in das lib/-Verzeichnis Ihres WAR zu legen, müssen Sie den <resource-root>-Pfad in der jboss-deployment-structure.xml-Datei angeben.

   <jboss-deployment-structure>
       <deployment>
           <!-- Exclusions allow you to prevent the server from automatically adding some dependencies -->
           <exclusions>
               <module name="org.apache.log4j" />
           </exclusions>
           <resources>
               <resource-root path="lib" />
           </resources>
       </deployment>
   </jboss-deployment-structure>
   

4. Starten Sie den JBoss EAP 6 Server mit folgendem Laufzeitargument um zu verhindern, dass eine ClassCastException in der Konsole erscheint, wenn Sie die Applikation deployen:

   -Dorg.jboss.as.logging.per-deployment=false

5. Deployen Sie Ihre Applikation.

Prozedur 3.6. Konfigurieren von Logging Abhängigkeiten für JBoss EAP 6.3 oder spätere Versionen

1. Starten Sie den JBoss EAP 6 Server mit folgendem Laufzeitargument um zu verhindern, dass eine ClassCastException in der Konsole erscheint, wenn Sie die Applikation deployen:

   -Dorg.jboss.as.logging.per-deployment=false

2. Öffnen Sie ein Terminal und verbinden Sie sich mit dem Management-CLI.
   • In Linux geben Sie folgendes in der Befehlszeile ein:

     $ EAP_HOME/bin/jboss-cli.sh --connect
     

   • In Windows geben Sie folgendes in der Befehlszeile ein:

     C:\>EAP_HOME\bin\jboss-cli.bat --connect
     

3. Modifizieren Sie das add-logging-api-dependencies Attribut im Logging Subsystem.
   Dieses Attribut kontrolliert, ob der Container implizite Logging API Abhängigkeiten zu Ihren Deployments hinzufügt.

   • Wenn true gesetzt ist, was der Standardwert ist, sind alle impliziten Logging API Abhängigkeiten hinzugefügt.
   • Wenn false gesetzt ist, wurden die Abhängigkeiten Ihren Deployments nicht hinzugefügt.
   Um die Loggingframework-Abhängigkeiten von Drittanbietern auszuschließen müssen Sie dieses Attribut über folgenden Befehl auf false setzten:

   /subsystem=logging:write-attribute(name=add-logging-api-dependencies, value=false)

   Dieser Befehl fügt das <add-logging-api-dependencies> Element dem logging Subsystem der standalone.xml Konfigurationsdatei hinzu.

   <subsystem xmlns="urn:jboss:domain:logging:1.4">
       <add-logging-api-dependencies value="false"/>
       ....
   </subsystem>
   

4. Deployen Sie Ihre Applikation.

Prozedur 3.7. Bearbeitung von Code und Abhängigkeiten zur Verwendung des JBoss Logging Frameworks

1. Ändern Sie Ihre Importe und Protokollierungscode

   Nachfolgend sehen Sie ein Beispiel für einen Code, der das neue JBoss Logging Framework verwendet:

   import org.jboss.logging.Level;
   import org.jboss.logging.Logger;
   
   private static final Logger logger = Logger.getLogger(MyClass.class.toString());
   
   if(logger.isTraceEnabled()) {
       logger.tracef("Starting...", subsystem);
   }
   

2. Fügen Sie die Protokollierungsabhängigkeit hinzu

   Das die JBoss Protokollierungsklassen enthaltende JAR befindet sich im Modul namens org.jboss.logging. Ihre MANIFEST-MF-Datei sollte wie folgt aussehen:

   Manifest-Version: 1.0
   Dependencies: org.jboss.logging
   

   Weitere Informationen dazu, wie Sie die Modulabhängigkeit finden, finden Sie unter Abschnitt 3.1.2.3, »Aktualisierung der Applikationsabhängigkeiten aufgrund von Klassenladeänderungen« und Abschnitt 4.2.1, »Fehler- und Problembehebung bei der Migration«.

Prozedur 3.8. Bearbeitung des Archiv-Packagings

1. Packaging eines WAR

   Bei einem WAR handelt es sich um ein einzelnes Modul und alle Klassen im WAR werden mit demselben Klassenlader geladen. Das bedeutet, dass im WEB-INF/lib/-Verzeichnis gepackte Klassen genauso behandelt werden wie Klassen im WEB-INF/classes-Verzeichnis.

2. Packaging eines EAR

   Ein EAR besteht aus mehreren Modulen. Das EAR/lib/-Verzeichnis ist ein einzelnes Modul und jedes WAR oder EJB jar-Unterdeployment innerhalb des EAR ist ein separates Modul. Klassen müssen nicht auf Klassen in anderen Modulen innerhalb des EAR zugreifen, falls nicht explizit Abhängigkeiten definiert wurden. Unterdeployments besitzen eine automatische Abhängigkeit am übergeordneten Modul, das ihnen Zugriff auf die Klassen im EAR/lib/-Verzeichnis gibt. Allerdings haben Unterdeployments nicht immer eine automatische Abhängigkeit, die ihnen Zugriff auf einander gibt. Dieses Verhalten wird durch Einstellung des <ear-subdeployments-isolated>-Element in der ee-Subsystemkonfiguration wie folgt gesteuert:

   <subsystem xmlns="urn:jboss:domain:ee:1.0" >            
     <ear-subdeployments-isolated>false</ear-subdeployments-isolated>
   </subsystem>

   Dies ist standardmäßig auf "false" eingestellt, wodurch die Unterdeployments die zu anderen Unterdeployments innerhalb des EAR gehörenden Klassen sehen können.
   Weitere Informationen zum Laden von Klassen finden Sie im Kapitel Class Loading and Modules im Development Guide für die JBoss EAP 6 unter https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/.

1. Falls Ihre Applikation eine Datenquelle verwendet, siehe: Abschnitt 3.1.6.2, »Aktualisierung der Datenquellen-Konfiguration«.
2. Falls Ihre Applikation JPA verwendet und derzeit die Hibernate JARs bündelt, so finden Sie Informationen zu Migrationsoptionen hier: Abschnitt 3.1.6.4, »Konfiguration der Datenquelle für Hibernate oder JPA«.
3. Falls Ihre Applikation einen Ressourcenadapter verwendet, siehe: Abschnitt 3.1.6.5, »Aktualisierung der Ressourcen-Adapter-Konfiguration«.
4. Sehen Sie sich die folgenden Informationen zur Konfiguration von Änderungen für grundlegende Sicherheit an: Abschnitt 3.1.7.1, »Konfiguration der Sicherheitsänderungen der Applikation«.

Prozedur 3.9. Installation und Konfiguration des JDBC-Treibers

1. Installation des JDBC-Treibers.

   1. Installation des JDBC-Treibers als ein Deployment.

      Dies ist die empfohlene Vorgehensweise, auf die der Treiber installiert werden sollte. Wenn der JDBC Treiber als Deployment installiert ist, wird er als normales JAR deployt. Wenn die JBoss EAP 6 Instanz als Standalone Server läuft, so kopieren Sie das JDBC 4.0 kompatible JAR ins EAP_HOME/standalone/deployments/ Verzeichnis. Für eine Managed Domain müssen Sie die Management Konsole oder das Management CLI benutzen um das JAR zu den Servergruppen zu deployen.
      Nachfolgend sehen Sie ein Beispiel für einen als Deployment an einem Standalone Server installierten MySQL JDBC-Treiber:

      $cp mysql-connector-java-5.1.15.jar EAP_HOME/standalone/deployments/

      Jeder JDBC 4.0 kompatible Treiber wird automatisch erkannt und wird nach Namen und Version im System installiert. Ein JDBC 4.0 kompatibles JAR enthält eine Textdatei namens META-INF/services/java.sql.Driver, die den/die Treiberklassenname(n) festlegt. Ist der Treiber nicht JDBC 4.0 kompatibel, so kann er auf eine der folgenden Arten deploybar gemacht werden:

      • Erstellen Sie eine java.sql.Driver-Datei für das JAR und fügen Sie diese unter dem META-INF/services/-Pfad hinzu. Diese Datei sollte den Treiberklassennamen enthalten, zum Beispiel:

        com.mysql.jdbc.Driver

      • Erstellen Sie eine java.sql.Driver Datei im Deployment Verzeichnis. Für eine als Standalone Server laufende JBoss EAP 6 Instanz sollte die Datei hier sein: EAP_HOME/standalone/deployments/META-INF/services/java.sql.Driver. Wenn der Server in einer Managed Domain ist, müssen Sie die Datei über die Managementkonsole oder das Management CLI deployen.
      Die Vorteile dieser Vorgehensweisen sind:

      • Dies ist die einfachste Methode, da kein Modul definiert werden muss.
      • Läuft der Server in einer Managed Domain, so werden nach dieser Vorgehensweise verwendende Deployments automatisch zu allen Servern in der Domain fortgepflanzt. Dies bedeutet, dass der Administrator das Treiber-JAR nicht manuell distribuieren muss.

      Die Nachteile dieser Vorgehensweisen sind:

      • Falls der JDBC-Treiber aus mehr als einem JAR besteht, zum Beispiel dem Treiber-JAR plus einem abhängigen Lizenz-JAR oder Lokalisierungs-JAR, so können Sie den Treiber nicht als Deployment installieren. Sie müssen den JDBC-Treiber als ein Kernmodul installieren.
      • Falls der Treiber nicht JDBC 4.0 kompatibel ist, so muss eine Datei erstellt werden, die die/den Treiberklassennamen enthält und muss in das JAR importiert werden oder im deployments/-Verzeichnis überlagert werden.

   2. Installation des JDBC-Treibers als Kernmodul.

      Um einen JDBC-Treiber als Kernmodul zu installieren, müssen Sie eine Dateipfadstruktur unter dem EAP_HOME/modules/-Verzeichnis erstellen. Diese Struktur enthält das JDBC-Treiber JAR, zusätzliche Anbieter Lizenzen oder Lokalisierungs-JARs und eine module.xml-Datei, um das Modul zu definieren.

      • Installation des MySQL-Treibers als Kernmodul

        1. Erstellen Sie die Verzeichnisstruktur EAP_HOME/modules/com/mysql/main/
        2. Erstellen Sie im main/-Unterverzeichnis eine module.xml-Datei, die die folgende Moduldefinition für den MySQL JDBC-Treiber enthält:

           <?xml version="1.0" encoding="UTF-8"?>
           <module xmlns="urn:jboss:module:1.0" name="com.mysql">
           <resources>
               <resource-root path="mysql-connector-java-5.1.15.jar"/>
           </resources>
           <dependencies>
               <module name="javax.api"/>
           </dependencies>
           </module>
           
           

           Der Modulname "com.mysql" stimmt mit der Verzeichnisstruktur für dieses Modul überein. Das <dependencies>-Element wird zur Festlegung der Abhängigkeiten von anderen Modulen dieses Moduls verwendet. In diesem Fall (wie auch bei allen anderen JDBC-Datenquellen) hängt dies von den Java JDBC APIs ab, die in einem anderen Modul namens javax.api definiert sind. Dieses Modul befindet sich im modules/system/layers/base/javax/api/main/-Verzeichnis.

           Anmerkung

           Stellen Sie sicher, dass sich KEINE Leerstelle am Anfang der module.xml-Datei befindet, da Sie sonst die Fehlermeldung "New missing/unsatisfied dependencies" für diesen Treiber erhalten.
        3. Kopieren Sie das MySQL JDBC-Treiber JAR in das EAP_HOME/modules/com/mysql/main/-Verzeichnis:

           $ cp mysql-connector-java-5.1.15.jar EAP_HOME/modules/com/mysql/main/

      • Installation des IBM DB2 JDBC-Treibers und Lizenz-JAR als Kernmodul.

        Dieses Beispiel zeigt Ihnen nur, wie Treiber deployt werden, die neben dem DBC Driver JAR zusätzliche JARs benötigen.
        1. Erstellen Sie die Verzeichnisstruktur EAP_HOME/modules/com/ibm/db2/main/.
        2. Erstellen Sie im main/-Unterverzeichnis eine module.xml-Datei, die die folgende Moduldefinition für den IBM DB2 JDBC-Treiber und Lizenz enthält:

           <?xml version="1.0" encoding="UTF-8"?>
           <module xmlns="urn:jboss:module:1.1" name="com.ibm.db2">
             <resources>
               <resource-root path="db2jcc.jar"/>
               <resource-root path="db2jcc_license_cisuz.jar"/>
             </resources>
             <dependencies>
               <module name="javax.api"/>
               <module name="javax.transaction.api"/>
             </dependencies>
           </module>
           

           Anmerkung

           Stellen Sie sicher, dass sich KEINE Leerstelle am Anfang der module.xml-Datei befindet, da Sie sonst die Fehlermeldung "New missing/unsatisfied dependencies" für diesen Treiber erhalten.
        3. Kopieren Sie den JDBC-Treiber und das Lizenz-JAR in das EAP_HOME/modules/com/ibm/db2/main/-Verzeichnis.

           $ cp db2jcc.jar EAP_HOME/modules/com/ibm/db2/main/
           $ cp db2jcc_license_cisuz.jar EAP_HOME/modules/com/ibm/db2/main/

      Die Vorteile dieser Vorgehensweisen sind:

      • Dies ist die einzige Vorgehensweise, die funktioniert, wenn der JDBC-Treiber aus mehr als einem JAR besteht.
      • Mit dieser Vorgehensweise können Treiber, die nicht JDBC 4.0 kompatibel sind, installiert werden, ohne dass das Treiber-JAR bearbeitet werden muss oder ein Datei-Overlay erstellt wird.

      Die Nachteile dieser Vorgehensweisen sind:

      • Es ist schwieriger, ein Modul einzurichten.
      • Das Modul muss manuell in jeden in einer Managed Domain laufenden Server kopiert werden.

2. Konfiguration der Datenquelle.

   1. Fügen Sie den Datenbanktreiber hinzu.

      Fügen Sie das <driver>-Element dem <drivers>-Element derselben Datei hinzu. Wieder enthält dies einige derselben Datenquelleninformationen, die zuvor in der *-ds.xml-Datei definiert waren.
      Bestimmen Sie zuerst, ob das Treiber-JAR JDBC 4.0 kompatibel ist. Ein JAR, das JDBC 4.0 kompatibel ist, enthält eine META-INF/services/java.sql.Driver-Datei, die den Treiberklassennamen festelegt. Der Server verwendet diese Datei, um den Namen der Treiberklasse(n) im JAR zu finden. Ein JDBC 4.0 kompatibler Treiber benötigt kein <driver-class>-Element, da es bereits im JAR festgelegt ist. Dies ist ein Beispiel des Treiberelements für einen JDBC 4.0 kompatiblen MySQL-Treiber:

      <driver name="mysql-connector-java-5.1.15.jar" module="com.mysql"/>
      

      Ein Treiber, der nicht JDBC 4.0 kompatibel ist, benötigt ein <driver-class>-Attribut zur Identifikation der Treiberklasse, da es keine META-INF/services/java.sql.Driver-Datei gibt, die den Treiberklassennamen festlegt. Dies ist ein Beispiel für ein Treiberelement für einen Treiber, der nicht JDBC 4.0 kompatibel ist:

      <driver name="mysql-connector-java-5.1.15.jar" module="com.mysql">
      <driver-class>com.mysql.jdbc.Driver</driver-class></driver>
      

   2. Erstellen Sie die Datenquelle.

      Erstellen Sie ein <datasource>-Element im <datasources>-Abschnitt der standalone.xml-Datei. Diese Datei enthält viele derselben Datenquelleninformationen, die zuvor in der *-ds.xml-Datei definiert waren.

      Wichtig

      Sie müssen den Server stoppen, ehe Sie die Server Konfigurations-Datei bearbeiten, damit Ihre Änderungen bei einem Server-Neustart als dauerhaft erstellt werden.
      Nachfolgend sehen Sie ein Beispiel für ein MySQL-Datenquellenelement in der standalone.xml-Datei.

      <datasource jndi-name="java:/YourDatasourceName" pool-name="YourDatasourceName">
        <connection-url>jdbc:mysql://localhost:3306/YourApplicationURL</connection-url>
        <driver>mysql-connector-java-5.1.15.jar</driver>
        <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
        <pool>
          <min-pool-size>100</min-pool-size>
          <max-pool-size>200</max-pool-size>
        </pool>
        <security>
          <user-name>USERID</user-name>
          <password>PASSWORD</password>
        </security>
        <statement>
          <prepared-statement-cache-size>100</prepared-statement-cache-size>
          <share-prepared-statements/>
        </statement>
      </datasource>
      

3. Aktualisieren Sie JNDI Referenzen im Applikationscode.

   Sie müssen abgelaufene JNDI-Lookup Namen im Applikationsquellencode ersetzen um die neuen, von Ihnen definierten JNDI standardisierten Datenquellen-Namen zu benutzen. Weitere Informationen finden Sie unter: Abschnitt 3.1.8.4, »Bearbeitung der Applikation zur Befolgung der neuen JNDI-Namespace Regeln«.
   Sie müssen auch vorhandene @Resource Annotationen ersetzen, die auf die Datenquellen zugreifen, um die neuen JNDI-Namen zu benutzen. Zum Beispiel:

   @Resource(name = "java:/YourDatasourceName").
   

Prozedur 3.10. Entfernen des Hibernate Bündels

1. Entfernen Sie die Hibernate JARs aus den Bibliotheksordnern Ihrer Applikation.
2. Entfernen oder kommentieren Sie das <hibernate.transaction.manager_lookup_class>-Element in Ihrer persistence.xml-Datei aus, da dieses Element nicht benötigt wird.

Prozedur 3.11. Zusätzliche Autorisierungsüberprüfungen deaktivieren

• Sie können die zusätzlichen Autorisierungsüberprüfungen und die vorhandenen PicketLink Deployments über eine der folgenden Methoden deaktivieren.

  • Einrichten einer System-weiten Property

    Sie können zusätzliche Autorisierungsüberprüfungen auf Serverebene deaktivieren, indem Sie den org.jboss.ws.cxf.disableHandlerAuthChecks System-Property Wert auf true setzen. Diese Methode betrifft jedes Deployment, das auf dem Server gemacht wurde.
    Informationen darüber, wie Sie eine System-Property einrichten, finden Sie unter dem Abschnitt Configure System Properties Using the Management CLI imAdministration and Configuration Guide für JBoss EAP.

  • Erstellen einer Property in der Web Services Deskriptor Datei des Deployments

    Sie können zusätzliche Autorisierungsüberprüfungen auf Deploymentebene deaktivieren, indem Sie den org.jboss.ws.cxf.disableHandlerAuthChecks Property Wert auf true in der jboss-webservices.xml Datei setzen. Diese Methode wirkt sich nur auf das spezifische Deployment aus.
    1. Erstellen Sie eine jboss-webservices.xml Datei im META-INF/ Verzeichnis des Deployments, für das Sie die zusätzlichen Autorisierungsüberprüfungen deaktivieren möchten.
    2. Fügen Sie folgenden Inhalt hinzu:

       <?xml version="1.1" encoding="UTF-8"?>
       <webservices xmlns="http://www.jboss.com/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         version="1.2" xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee">
         <property>
           <name>org.jboss.ws.cxf.disableHandlerAuthChecks</name>
           <value>true</value>
         </property>
       </webservices>

Prozedur 3.12. JNDI-Lookups bearbeiten

1. Erfahren Sie mehr über Abschnitt 3.1.8.2, »Portierbare EJB JNDI-Namen«
2. Abschnitt 3.1.8.3, »Übersicht über die JNDI-Namespace Regeln«
3. Abschnitt 3.1.8.4, »Bearbeitung der Applikation zur Befolgung der neuen JNDI-Namespace Regeln«

Prozedur 3.13. Konfiguration der Applikation

1. Kopieren Sie die benötigten Hibernate 3 JARs in Ihre Applikationsbibliothek.

   Sie können dieses Problem möglicherweise beheben, indem Sie die betreffenden, die fehlenden Klassen enthaltenden Hibernate 3 JARs in das lib/-Verzeichnis kopieren oder indem Sie diese mittels einer anderen Methode dem Klassenpfad hinzufügen. In einigen Fällen kann dies aufgrud der Verwendung unterschiedlicher Hibernate-Versionen zu einer ClassCastExceptions oder anderen Problemen beim Klassenladen führen. Ist dies der Fall, so verwenden Sie die nächste Vorgehensweise.

2. Weisen Sie den Server dazu an, nur die Hibernate 3 Bibliotheken zu benutzen.

   Die JBoss EAP 6 gestattet es Ihnen, Hibernate 3.5 (oder höher) Persistenz-Provider-Jars mit der Applikation zu verpacken. Um den Server dazu anzuweisen, nur die Hibernate 3 Bibliotheken zu verwenden und die Hibernate 4 Bibliotheken auszuschließen, müssen Sie das jboss.as.jpa.providerModule in der persistence.xml wie folgt auf hibernate3-bundled setzen:

   <?xml version="1.0" encoding="UTF-8"?>
   <persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0">
       <persistence-unit name="plannerdatasource_pu">
           <description>Hibernate 3 Persistence Unit.</description>
           <jta-data-source>java:jboss/datasources/PlannerDS</jta-data-source>
           <properties>
               <property name="hibernate.show_sql" value="false" />
               <property name="jboss.as.jpa.providerModule" value="hibernate3-bundled" />
           </properties>
       </persistence-unit>
   </persistence>
   

   Der Java Persistence API (JPA) Deployer spürt das Vorhandensein des Persistenz-Providers in der Applikation auf und wird die Hibernate 3 Bibliotheken verwenden. Weitere Informationen zu JPA Persistenz-Properties finden Sie unter Abschnitt 3.2.2.3, »Properties der Persistenzeinheit«.

3. Deaktivieren des Caches der zweiten Ebene von Hibernate

   Das Cache der zweiten Ebene bei Hibernate 3 zeigt mit der JBoss EAP 6 nicht dasselbe Verhalten wie frühere Releases. Falls Sie mit Ihrer Applikation das Hibernate Cache der zweiten Ebene Verwenden, so müssen Sie es bis zum Upgrade auf Hibernate 4 deaktivieren. Um das Cache der zweiten Ebene zu deaktivieren setzen Sie <hibernate.cache.use_second_level_cache> in der persistence.xml-Datei auf false.

Prozedur 3.14. Aktualisieren Sie die Applikation, damit sie Hibernate 4 benutzt

1. Das Standardverhalten des selbstinkrementierenden Sequenzgenerators hat sich bei der JBoss EAP 6 geändert. Für weitere Informationen, siehe Abschnitt 3.2.2.5, »Beibehaltung des bestehenden Verhaltens des selbstgenerierten Wertes der Hibernate-Identität«.
2. Bestimmen Sie die derzeit von der Applikation verwendete Version von Hibernate und wählen Sie unten den passenden Aktualisierungsvorgang aus.
   • Abschnitt 3.2.2.6, »Migration Ihrer Hibernate 3.3.x Applikation zu Hibernate 4.x«
   • Abschnitt 3.2.2.7, »Migration Ihrer Hibernate 3.5.x Applikation zu Hibernate 4.x«
3. Sie Abschnitt 3.2.2.8, »Bearbeiten Sie Persistenz-Properties für migrierte Seam- und Hibernate-Applikationen, die in einer geclusterten Umgebung laufen« falls Ihre Applikation in einer geclusterten Umgebung laufen wird.

1. Mappen Sie Hibernate text-Typen zu JDBC LONGVARCHAR

   In Hibernate-Versionen vor 3.5 war der text-Typ zu JDBC CLOB gemappt. Ein neuer Hibernate-Typ namens materialized_clob ist in Hibernate 4 dazugekommen und mappt Java String-Properties zu JDBC CLOB. Falls Ihre Applikation als type="text" konfigurierte Properties besitzt, die zu JDBC CLOB gemappt werden sollen, so müssen Sie einen der folgenden Schritte durchführen:
   1. Falls Ihre Applikation hbm-Mapping-Dateien verwendet, so ändern Sie die Property zu type="materialized_clob".
   2. Falls Ihre Applikation Annotationen verwendet, so sollten Sie @Type(type = "text") durch @Lob ersetzen.

2. Überprüfen Sie den Code, um Änderungen in den wiedergegebenen Wertetypen zu finden

   Numerische aggregierte Criteria Projections geben jetzt denselben Wertetyp wie ihre HQL-Entsprechungen wieder. Als Folge haben sich die Wiedergabetypen folgender Projections in org.hibernate.criterion geändert.
   1. Aufgrund der Änderungen in CountProjection, Projections.rowCount(), Projections.count(propertyName) und Projections.countDistinct(propertyName), geben die count- und count distinct-Projections jetzt einen Long-Wert wieder.
   2. Aufgrund von Änderungen in Projections.sum(propertyName) geben die sum-Projections einen Wertetyp wieder, der vom Property-Typ abhängt.

      Anmerkung

      Falls Sie Ihren Applikationscode nicht bearbeiten, so kann dies zu einer java.lang.ClassCastException führen.
      1. Für als Long, Short, Integer oder primitive gemappte Integertypen wird ein Long-Wert wiedergegegeben;
      2. Für als Float, Double oder primitive Floating-Point-Typen gemappte Properties wird ein Double-Wert wiedergegeben.

1. Fügen Sie die AnnotationConfiguration in die Konfiguration ein.
   Obwohl AnnotationConfiguration jetzt veraltet ist, sollte dies Ihre Migration nicht beeinflussen.
   Falls Sie noch eine hbm.xml-Datei verwenden so sollten Sie sich dessen bewusst sein, dass die JBoss EAP 6 jetzt org.hibernate.cfg.EJB3NamingStrategy in AnnotationConfiguration statt der org.hibernate.cfg.DefaultNamingStrategy aus früheren Releases verwendet. Falls Ihre Naming-Strategy den Namen einer Assoziationstabelle bestimmt (many-to-many und Collections von Elementen), so begegnen Sie möglicherweise diesem Problem. Um es zu lösen können Sie Hibernate dazu anweisen, die Legacy org.hibernate.cfg.DefaultNamingStrategy durch Aufrufen von Configuration#setNamingStrategy und deren Weitergabe an org.hibernate.cfg.DefaultNamingStrategy#INSTANCE zu verwenden.
2. Bearbeiten Sie die Namespaces, damit sie mit den neuen Hibernate DTD Dateinamen konform sind, wie in der nachstehenden Tabelle ausgewiesen.

   Tabelle 3.6. DTD Namespace Mapping Tabelle

   Früherer DTD Namespace	Neuer DTD Namespace
   http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd	http://www.hibernate.org/dtd/hibernate-configuration-3.0.dtd
   http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd	http://www.hibernate.org/dtd/hibernate-mapping-3.0.dtd

3. Bearbeiten Sie die Umgebungsvariablen.
   1. Falls Sie Oracle und die materialized_clob- oder materialized_blob-Properties verwenden, so muss die allgemeine Umgebungsvariable hibernate.jdbc.use_streams_for_binary auf true eingestellt sein.
   2. Falls Sie PostgreSQL und die CLOB oder BLOB-Properties verwenden, so muss die allgemeine Umgebungsvariable hibernate.jdbc.use_streams_for_binary auf false eingestellt sein.

Prozedur 3.15. Stellen Sie Persistenz-Properties zum Betrieb in einer geclusterten Umgebung ein

1. Setzen Sie den hibernate.session_factory_name-Wert auf einen eindeutigen Namen. Dieser Name muss über alle Applikations-Deployments auf der JBoss EAP 6 Instanz hinweg eindeutig sein. Zum Beispiel:

   <property name="hibernate.session_factory_name" value="jboss-seam-booking.ear_session_factory"/>
   

2. Setzen Sie den hibernate.ejb.entitymanager_factory_name-Wert auf einen eindeutigen Namen. Dieser Name muss über alle Applikations-Deployments auf der JBoss EAP 6 Instanz hinweg eindeutig sein. Zum Beispiel:

   <property name="hibernate.ejb.entitymanager_factory_name" value="seam-booking.ear_PersistenceUnitName"/>
   

Prozedur 3.16. Bearbeiten Sie die persistence.xml-Datei zur Verwendung von Infinispan

1. Konfiguration von Infinispan für eine JPA-Applikation in der JBoss EAP 6

   Auf diese Weise legen Sie Properties fest, um dieselbe Konfiguration für eine JPA-Applikation mittels Infinispan bei der JBoss EAP 6 zu erreichen:

   <property name="hibernate.cache.use_second_level_cache" value="true"/>
   

   Zusätzlich müssen Sie einen shared-cache-mode mit einem Wert von ENABLE_SELECTIVE oder ALL wie folgt festlegen:
   • ENABLE_SELECTIVE ist der Standard und der empfohlene Wert. Es bedeutet, dass Entities nicht gecacht werden, wenn Sie diese nicht explizit als cachbar kennzeichnen.

     <shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode>
     

   • ALL bedeutet, dass Entities immer gecacht werden, selbst wenn Sie diese als nicht cachbar kennzeichnen.

     <shared-cache-mode>ALL</shared-cache-mode>
     

2. Konfiguration von Infinispan für eine native Hibernate Applikation in der JBoss EAP 6

   Auf diese Weise legen Sie dieselbe Konfiguration für eine native Hibernate Applikation mittels Infinispan bei der JBoss EAP 6 fest:

   <property name="hibernate.cache.region.factory_class"
        value="org.jboss.as.jpa.hibernate4.infinispan.InfinispanRegionFactory"/>
   <property name="hibernate.cache.infinispan.cachemanager"
        value="java:jboss/infinispan/container/hibernate"/>     
   <property name="hibernate.transaction.manager_lookup_class"
        value="org.hibernate.transaction.JBossTransactionManagerLookup"/>
   <property name="hibernate.cache.use_second_level_cache" value="true"/>
   
   

   Sie müssen der MANIFEST.MF-Datei die folgenden Abhängigkeiten hinzufügen:

   Manifest-Version: 1.0
   Dependencies: org.infinispan, org.hibernate
   

Prozedur 3.17. Sie müssen eine oder mehrere der folgenden Aufgaben ausführen

1. Zugreifen auf die standardmäßige ValidatorFactory

   Die JBoss EAP 6 bindet eine standardmäßige ValidatorFactory unter dem Namen java:comp/ValidatorFactory an den JNDI-Kontext.

2. Vom Lebenszylus ausgelöste Validierung verstehen

   Wenn in Verbindung mit Hibernate Core 4 eingesetzt, so wird die Lebenszyklus basierte Validierung automatisch durch Hibernate Core aktiviert.
   1. Die Validierung erfolgt an Entity INSERT, UPDATE und DELETE-Operationen.
   2. Sie können die nach Ereignistyp zu validierenden Gruppen mittels der folgenden Properties konfigurieren:

      • javax.persistence.validation.group.pre-persist,
      • javax.persistence.validation.group.pre-update, and
      • javax.persistence.validation.group.pre-remove.

      Die Werte dieser Properties sind durch Kommas getrennt, voll qualifizierte Klassennamen der zu validierenden Gruppen.
      Validierungsgruppen sind ein neues Feature der Bean Validierungsspezifikation. Falls Sie dieses neue Feature nicht nutzen möchten, so sind bei der Migration zum Hibernate Validator 4 keine Änderungen notwendig.
   3. Sie können die Lebenszylus-basierte Validierung durch Einstellung der javax.persistence.validation.mode-Property auf none deaktivieren. Andere gültige Werte für diese Property sind auto (der Standard), callback und ddl.

3. Konfigurieren Sie Ihre Applikation zur Verwendung manueller Validierung

   1. Falls Sie die Validierung manuell steuern möchten, so können Sie auf eine der folgenden Weisen einen Validator erstellen:

      • Erstellen Sie eine Validator-Instanz aus der ValidatorFactory mittels der getValidator()-Methode.
      • Speisen Sie die Validator-Instanzen in Ihr EJB, Ihr CDI-Bean oder eine andere einspeisbare Java EE Ressource ein.
   2. Sie können den von der ValidatorFactory.usingContext() wiedergegeben ValidatorContext zur Anpassung Ihrer Validator-Instanz verwenden. Mittels dieses API können Sie benutzerdefinierte MessageInterpolator, TraverableResolver und ConstraintValidatorFactory konfigurieren. Diese Interfaces sind in der Bean Validierungsspezifikation festgelegt und neu im Hibernate Validator 4.

4. Bearbeiten Sie den Code, der mit den neuen Bean Validierungsbedingungen verwendet werden soll

   Die neuen Validierungsbedingungen auf Bean-Ebene erfordern Code-Änderungen wenn Sie zum Hibernate Validator 4 migrieren.
   1. Um ein Upgracde zu Hibernate Validator 4 durchzuführen müssen Sie die Bedingungen in den folgenden Paketen Verwenden:

      • javax.validation.constraints
      • org.hibernate.validator.constraints
   2. Alle Bedingungen, die im Hibernate Validator 3 vorhanden waren, gibt es auch im Hibernate Validator 4. Um diese zu verwenden, müssen Sie die festgelegte Klasse importieren und - in manchen Fällen - den Namen oder den Typ des Bedingungsparameters ändern.

5. Verwendung benutzerdefinierter Bedingungen

   Beim Hibernate Validator 3 musste eine benutzerdefinierte Bedingung im org.hibernate.validator.Validator-Interface implementiert werden. Beim Hibernate Validator 4 müssen Sie das javax.validation.ConstraintValidator-Interface implementieren. Dieses Interface enthält dieselben initialize()- und isValid()-Methoden wie das vorherige Interface, wobei sich allerdings die Methodensignatur geändert hat. Desweiteren wird DDL-Änderung beim Hibernate Validator 4 nicht mehr unterstützt.

Prozedur 3.18. JMS Bridge erstellen

1. Konfigurieren der Bridge auf dem Source JBoss EAP 5.x Server

   Um Konflikte in Klassen zwischen Releases zu vermeiden, müssen Sie die folgenden Schritte zur Konfiguration der JMS Bridge auf JBoss EAP 5.x verwenden. Die Namen des SAR Verzeichnisses und der Bridge sind arbiträr und können auf Wunsch geändert werden.
   1. Erstellen Sie ein Unterverzeichnis im JBoss EAP 5 Deployment-Verzeichnis, das das SAR enthält, zum Beispiel: EAP5_HOME/server/PROFILE_NAME/deploy/myBridge.sar/.
   2. Erstellen Sie ein Unterverzeichnis namens META-INF in EAP5_HOME/server/PROFILE_NAME/deploy/myBridge.sar/.
   3. Erstellen Sie eine jboss-service.xml Datei im EAP5_HOME/server/PROFILE_NAME/deploy/myBridge.sar/META-INF/ Verzeichnis. Sie sollte Informationen ähnlich dem folgendem Beispiel enthalten.

      <server>
         <loader-repository>
            com.example:archive=unique-archive-name
            <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
         </loader-repository> 
      
         <!-- JBoss EAP 6 JMS Provider --> 
         <mbean code="org.jboss.jms.jndi.JMSProviderLoader" name="jboss.messaging:service=JMSProviderLoader,name=EnterpriseApplicationPlatform6JMSProvider">
            <attribute name="ProviderName">EnterpriseApplicationPlatform6JMSProvider</attribute>
            <attribute name="ProviderAdapterClass">org.jboss.jms.jndi.JNDIProviderAdapter</attribute>
            <attribute name="FactoryRef">jms/RemoteConnectionFactory</attribute> 
            <attribute name="QueueFactoryRef">jms/RemoteConnectionFactory</attribute>  
            <attribute name="TopicFactoryRef">jms/RemoteConnectionFactory</attribute>      
            <attribute name="Properties">
               java.naming.factory.initial=org.jboss.naming.remote.client.InitialContextFactory
               java.naming.provider.url=remote://EnterpriseApplicationPlatform6host:4447
               java.naming.security.principal=jbossuser
               java.naming.security.credentials=jbosspass
            </attribute>
         </mbean> 
      
         <mbean code="org.jboss.jms.server.bridge.BridgeService" name="jboss.jms:service=Bridge,name=MyBridgeName" xmbean-dd="xmdesc/Bridge-xmbean.xml">      
            <depends optional-attribute-name="SourceProviderLoader">jboss.messaging:service=JMSProviderLoader,name=JMSProvider</depends>          
            <depends optional-attribute-name="TargetProviderLoader">jboss.messaging:service=JMSProviderLoader,name=EnterpriseApplicationPlatform6JMSProvider</depends>          
            <attribute name="SourceDestinationLookup">/queue/A</attribute>      
            <attribute name="TargetDestinationLookup">jms/queue/test</attribute>       
            <attribute name="QualityOfServiceMode">1</attribute>           
            <attribute name="MaxBatchSize">1</attribute>      
            <attribute name="MaxBatchTime">-1</attribute>           
            <attribute name="FailureRetryInterval">60000</attribute>      
            <attribute name="MaxRetries">-1</attribute>      
            <attribute name="AddMessageIDInHeader">false</attribute>
            <attribute name="TargetUsername">jbossuser</attribute>
            <attribute name="TargetPassword">jbosspass</attribute>
         </mbean>
      </server>
      
      

      Anmerkung

      Das load-repository ist präsent um sicherzustellen, dass das SAR einen isolierten Klassenlader besitzt. Beachten Sie auch, dass sowohl das JNDI Look-up als auch das Bridge "Ziel" Sicherheitsberechtigungen für den Benutzer "jbossuser" mit dem Passwort "jbosspass" beinhalten. Der Grund hierfür ist, dass JBoss EAP 6 standardmäßig gesichert ist. Der Benutzer namens "jbossuser" mit dem Passwort "jbosspass" wurde im ApplicationRealm mit der Rolle guest mittels EAP_HOME/bin/add_user.sh-Skript erstellt.
   4. Kopieren Sie die folgende JARs vom EAP_HOME/modules/system/layers/base/-Verzeichnis in das EAP5_HOME/server/PROFILE_NAME/deploy/myBridge.sar/-Verzeichnis. Ersetzen Sie jede VERSION_NUMBER durch die tatsächliche Versionsnummer in Ihrer JBoss EAP 6 Distribution.

      • org/hornetq/main/hornetq-core-VERSION_NUMBER.jar
      • org/hornetq/main/hornetq-jms-VERSION_NUMBER.jar
      • org/jboss/ejb-client/main/jboss-ejb-client-VERSION_NUMBER.jar
      • org/jboss/logging/main/jboss-logging-VERSION_NUMBER.jar
      • org/jboss/logmanager/main/jboss-logmanager-VERSION_NUMBER.jar
      • org/jboss/marshalling/main/jboss-marshalling-VERSION_NUMBER.jar
      • org/jboss/marshalling/river/main/jboss-marshalling-river-VERSION_NUMBER.jar
      • org/jboss/remote-naming/main/jboss-remote-naming-VERSION_NUMBER.jar
      • org/jboss/remoting3/main/jboss-remoting-VERSION_NUMBER.jar
      • org/jboss/sasl/main/jboss-sasl-VERSION_NUMBER.jar
      • org/jboss/netty/main/netty-VERSION_NUMBER.jar
      • org/jboss/remoting3/remote-jmx/main/remoting-jmx-VERSION_NUMBER.jar
      • org/jboss/xnio/main/xnio-api-VERSION_NUMBER.jar
      • org/jboss/xnio/nio/main.xnio-nio-VERSION_NUMBER.jar

      Anmerkung

      Kopieren Sie das EAP_HOME/bin/client/jboss-client.jar nicht einfach, da die javax API Klassen mit denen in JBoss EAP 5.x in Konflikt stehen.

2. Konfigurieren der Bridge auf dem Destination JBoss EAP 6 Server

   Bei der JBoss EAP 6.1 und später kann die JMS Bridge zur Überbrückung von Nachrichten von jedem JMS 1.1 konformen Server verwendet werden. Weil die Quell- und Ziel JMS Ressourcen mittels JNDI aufgesucht werden, müssen die JNDI Lookup-Klassen des Quell-Messaging Providers oder Nachrichten-Brokers in einem JBoss Modul gebündelt sein. Die folgenden Schritte verwenden den fiktiven 'MyCustomMQ' Message Broker als ein Beispiel.
   1. Erstellen eines JBoss Moduls für den Messaging Provider.
      1. Erstellen Sie eine Verzeichnisstruktur unter EAP_HOME/modules/system/layers/base/ für das neue Modul. Das main/-Unterverzeichnis enthält die Client JARs und die module.xml-Datei. Nachfolgend sehen Sie ein Beispiel der Verzeichnisstruktur, die für den MyCustomMQ Messaging Provider erstellt wurde: EAP_HOME/modules/system/layers/base/org/mycustommq/main/
      2. Erstellen Sie im main/-Unterverzeichnis eine module.xml-Datei, die die Moduldefinition für den Messaging Provider enthält. Nachfolgend sehen Sie ein Beispiel der module.xml, die für den MyCustomMQ Messaging Provider erstellt wurde.

         <?xml version="1.0" encoding="UTF-8"?>
         <module xmlns="urn:jboss:module:1.1" name="org.mycustommq">
             <properties>
                 <property name="jboss.api" value="private"/>
             </properties> 
         
             <resources>
                 <!-- Insert resources required to connect to the source or target   -->
                 <resource-root path="mycustommq-1.2.3.jar" />
                 <resource-root path="mylogapi-0.0.1.jar" />
             </resources> 
         
             <dependencies>
                <!-- Add the dependencies required by JMS Bridge code                 -->
                <module name="javax.api" />
                <module name="javax.jms.api" />
                <module name="javax.transaction.api"/>
                <!-- Add a dependency on the org.hornetq module since we send         -->
                <!-- messages tothe HornetQ server embedded in the local EAP instance -->
                <module name="org.hornetq" />
             </dependencies>
         </module>
         

      3. Kopieren Sie die Messaging Provider JARs, die für den JNDI Lookup der Quellressourcen benötigt werden, in das main/-Unterverzeichnis des Moduls. Die Verzeichnisstruktur des MyCustomMQ Moduls sollte jetzt wie folgt aussehen.

         modules/
         `-- system
             `-- layers
                 `-- base
                     `-- org
                           `-- mycustommq
                               `-- main
                                   |-- mycustommq-1.2.3.jar
                                   |-- mylogapi-0.0.1.jar
                                   |-- module.xml
         

   2. Konfigurieren Sie die JMS Bridge im messaging Untersystem des JBoss EAP 6 Servers.
      1. Ehe Sie anfangen, stoppen Sie den Server und erstellen Sie eine Sicherungskopie der aktuellen Serverkonfigurationsdateien. Falls Sie einen Standalone Server betreiben ist dies die EAP_HOME/standalone/configuration/standalone-full-ha.xml-Datei. In einer Managed Domain erstellen Sie eine Sicherungskopie von sowohl der EAP_HOME/domain/configuration/domain.xml- als auch der EAP_HOME/domain/configuration/host.xml-Datei.
      2. Fügen Sie das jms-bridge-Element dem messaging-Subsystem in der Server Konfigurationsdatei hinzu. Die source und <target>-Elemente liefern die Namen der JMS-Ressourcen, die für JNDI Lookups verwendet werden. Falls user und password Berechtigungen festgelegt sind, so sind sie Argumente bei der Erstellung der JMS-Verbindung.
         Nachfolgend sehen Sie ein Beispiel für das jms-bridge-Element, das für den MyCustomMQ Messaging Provider konfiguriert ist:

         <subsystem xmlns="urn:jboss:domain:messaging:1.3">
            ...
            <jms-bridge name="myBridge" module="org.mycustommq">
               <source>
                  <connection-factory name="ConnectionFactory"/>
                  <destination name="sourceQ"/>
                  <user>user1</user>
                  <password>pwd1</password>
                  <context>
                     <property key="java.naming.factory.initial" value="org.mycustommq.jndi.MyCustomMQInitialContextFactory"/>
                     <property key="java.naming.provider.url"    value="tcp://127.0.0.1:9292"/>
                  </context>
               </source>
               <target>
                  <connection-factory name="java:/ConnectionFactory"/>
                  <destination name="/jms/targetQ"/>
               </target>
               <quality-of-service>DUPLICATES_OK</quality-of-service>
               <failure-retry-interval>500</failure-retry-interval>
               <max-retries>1</max-retries>
               <max-batch-size>500</max-batch-size>
               <max-batch-time>500</max-batch-time>
               <add-messageID-in-header>true</add-messageID-in-header>
            </jms-bridge>
         </subsystem>
         

         Im Beispiel oben sind die JNDI-Properties im context-Element für die source definiert. Wird das context-Element weggelassen, wie im target-Beispiel oben, so wird in der lokalen Instanz nach JMS-Ressourcen gesucht.

Prozedur 3.19. Ehe Sie starten

1. Fahren Sie den Client und den Server herunter.
2. Erstellen Sie ein Backup sämtlicher JBoss Messaging Daten. Die Nachrichtendaten befinden sich in der Datenbank in Tabellen, denen ein JBM_ vorangestellt ist.

Prozedur 3.20. Ändern Sie Ihren Provider zu HornetQ

1. Übertragen Sie die Konfigurationen

   Übertragen Sie die bestehenden JBoss Messaging Konfigurationen auf die JBoss EAP Konfiguration. Die folgenden Konfigurationen befinden sich in Deployment-Deskriptoren auf dem JBoss Mesaging Server:
   • Connection Factories Dienstkonfiguration
     Diese Konfiguration beschreibt die JMS-Connection-Factories, die mit dem JBoss Messaging Server deployt werden. JBoss Messaging konfiguriert Connection Factories in einer Datei namens connection-factories-service.xml, die sich im Deployment-Verzeichnis des Applikationsservers befindet.
   • Zielkonfiguration
     Diese Konfiguration beschreibt mit dem JBoss Messaging Server deployte JMS-Warteschlangen und Topics. Standardmäßig konfiguriert JBoss Messaging Destinationen in einer Datei namens destinations-service.xml, die sich im Deployment-Verzeichnis des Applikationsservers befindet.
   • Message Bridge Dienstkonfiguration
     Diese Konfiguration beinhaltet Bridge-Dienste, die mit dem JBoss Messaging Server deployt werden. Es werden keine Bridges standardmäßig deployt, so dass der Name der Deployment-Datei je nach Ihrer JBoss Messaging Installation variiert.

2. Bearbeitung Ihres Applikationscodes

   Falls der Applikationscode Standard-JMS verwendet, so sind keine Codeänderungen erforderlich. Falls sich die Applikation jedoch mit einem Cluster verbindet, so müssen Sie die HornetQ Dokumentation sorgfältig auf Clustering-Semantik prüfen. Clustering liegt außerhalb des Rahmens der JMS-Spezifikation und HornetQ und JBoss Messaging haben eine maßgeblich unterschiedliche Vorgehensweise in ihren jeweiligen Implementierungen der Clustering Funktionalität.
   Falls die Applikation jedoch Features verwendet, die spezifisch für JBoss Messaging sind, so müssen Sie den Code so bearbeiten, dass er die äquivalenten Features in HornetQ nutzt.
   Für weitere Informationen zur Konfiguration von Messaging mit HornetQ siehe Abschnitt 3.2.7.5, »Konfigurieren Nachrichten-Vermittlung für HornetQ«

3. Migration bestehender Nachrichten

   Verschieben Sie alle Nachrichten in der JBoss Messaging Datenbank in das HornetQ Journal mittels einer JMS-Bridge. Eine Anleitung zur Konfiguration der JMS-Bridge finden Sie hier: Abschnitt 3.2.7.2, »Konfiguration einer JMS-Bridge zur Migration bestehender JMS-Nachrichten zur JBoss EAP 6«.

1. Starten Sie die JBoss EAP 6 mit aktiviertem Clustering

   Um Clustering in der JBoss EAP 5.x zu aktivieren müssen Sie Ihre Serverinstanzen mittels des all-Profils oder einer von dessen Ableitungen wie folgt starten:

   $ EAP5_HOME/bin/run.sh -c all

   In der JBoss EAP 6 hängt die Methode zur Aktivierung des Clustering davon ab, ob die Servers standalone sind oder in einer Managed Domain laufen.

   1. Aktivierung von Clustering für in einer Managed Domain laufenden Servern

      Um Clustering für mittels des Domain Controllers gestarteten Servern zu aktivieren, aktualisieren Sie Ihre domain.xml und designieren Sie eine Servergruppe zur Verwendung des ha-Profils und der ha-sockets-Socket-Binding-Gruppe. Zum Beispiel:

      <server-groups>
        <server-group name="main-server-group" profile="ha">
          <jvm name="default">
            <heap size="64m" max-size="512m"/>
          </jvm>
          <socket-binding-group ref="ha-sockets"/>
        </server-group>
      </server-group>

   2. Aktivierung von Clustering für Standalone Server

      Zur Aktivierung von Clustering für Standalone Server starten Sie den Server unter Verwendung der passenden Konfigurationsdatei wie folgt:

      $ EAP_HOME/bin/standalone.sh --server-config=standalone-ha.xml -Djboss.node.name=UNIQUE_NODE_NAME

2. Spezifizieren Sie die Bind-Adresse

   Bei der JBoss EAP 5.x würden Sie normalerweise die für das Clustering zu verwendende Bind-Adresse unter Verwendung des -b-Befehlszeilenarguments wie folgt angeben:

   $ EAP5_HOME/bin/run.sh -c all -b 192.168.0.2

   JBoss EAP 6 bindet Sockets an die IP-Adressen und Interfaces, die in den <interfaces> Elementen in standalone.xml, domain.xml und host.xml Dateien enthalten sind. Die mit der JBoss EAP gelieferten Standardkonfigurationen umfassen zwei Interface-Konfigurationen:

   <interfaces>
       <interface name="management">
           <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
       </interface>
       <interface name="public">
          <inet-address value="${jboss.bind.address:127.0.0.1}"/>
       </interface>
   </interfaces>

   Diese Interface-Konfigurationen benutzen die Werte der System-Properties jboss.bind.address.management und jboss.bind.address. Wenn diese System-Properties nicht gesetzt wurden, wird für jeden Wert der Standardwert 127.0.0.1 benutzt.
   Sie können auch die Bind-Adresse bei Serverstart als Befehlszeilenargument angeben, oder sie explizit innerhalb der JBoss EAP 6 Serverkonfigurationsdatei definieren.
   • Bind-Argument auf der Befehlszeile bei Start des JBoss EAP Standalone Servers angeben.
     Es folgt ein Beispiel für die Angabe einer Bind-Adresse in der Befehlszeile für einen Standalone Server:

     EAP_HOME/bin/standalone.sh -Djboss.bind.address=127.0.0.1

     Anmerkung

     Sie können auch das -b Argument benutzen, eine Abkürzung für -Djboss.bind.address=127.0.0.1:

     EAP_HOME/bin/standalone.sh -b=127.0.0.1

     Das JBoss EAP 5 Syntaxformat wird ebenfalls noch unterstützt:

     EAP_HOME/bin/standalone.sh -b 127.0.0.1

     Beachten Sie, dass das -b Argument nur das public Interface ändert. Es beeinflusst nicht das management Interface.
   • Spezifizieren Sie die Bind-Adresse in der Server-Konfigurationsdatei.
     Geben Sie die Bind-Adressen für Server, die in einer Managed Domain laufen, in der domain/configuration/host.xml Datei an. Für Standalone Server geben Sie die Bind-Adressen in der standalone-ha.xml Datei an.
     Im folgenden Beispiel ist das public-Interface als das Standard-Interface für alle Sockets innerhalb der ha-sockets-Socket-Binding-Gruppe festgelegt.

     <interfaces>
       <interface name="management">
         <inet-address value="192.168.0.2"/>
       </interface>
       <interface name="public">
         <inet-address value="192.168.0.2"/>
       </interface>
     </interfaces>

     <socket-binding-groups>
       <socket-binding-group name="ha-sockets" default-interface="public">
         <!-- ... -->
       </socket-binding-group>
     </socket-binding-groups>

     Anmerkung

     Wenn Sie die Bind-Adressen als hartcodierten Wert anstatt als System Property in der Konfigurationsdatei angeben, können Sie sie nicht mit einem Befehlszeilenargument außer Kraft setzen.

3. Konfiguration von jvmRoute zur Unterstützung von mod_jk und mod_proxy

   Bei der JBoss EAP 5 wurde der Webserver jvmRoute mittels einer Property in der server.xml-Datei konfiguriert. Bei der JBoss Enterprise Application Platform 6 wird das jvmRoute-Attribut im Web-Untersystem der Serverkonfigurationsdatei unter Verwendung des instance-id-Attributs wie folgt konfiguriert:

   <subsystem xmlns="urn:jboss:domain:web:1.1" default-virtual-server="default-host" native="false" instance-id="{JVM_ROUTE_SERVER}">
   

   Das {JVM_ROUTE_SERVER} oben sollte durch die jvmRoute Server-ID ersetzt werden.
   Die instance-id kann auch mittels der Management-Konsole eingestellt werden.

4. Festlegung von Multicast-Adresse und Port

   Bei der JBoss EAP 5.x konnten Sie die für intra-Cluster verwendete Multicast-Adresse und den Port mittels der Befehlszeilenargumente -u und -m wie folgt festlegen:

   $ EAP5_HOME/bin/run.sh -c all -u 228.11.11.11 -m 45688

   Bei der JBoss EAP 6 sind die für intra-Cluster-Kommunikation verwendete Multicast-Adresse und der Port mittels des von dem relevanten JGroups Protokoll-Stacks referenzierten Socket-Binding wie folgt definiert:

   <subsystem xmlns="urn:jboss:domain:jgroups:1.0" default-stack="udp">
       <stack name="udp">
           <transport type="UDP" socket-binding="jgroups-udp"/>
           <!-- ... -->
       </stack>
   </subsystem>

   <socket-binding-groups>
       <socket-binding-group name="ha-sockets" default-interface="public">
           <!-- ... -->
           <socket-binding name="jgroups-udp" port="55200" multicast-address="228.11.11.11" multicast-port="45688"/>
           <!-- ... -->
       </socket-binding-group>
   </socket-binding-groups>
   

   Falls Sie die Multicast-Adresse und den Port lieber in der Befehlszeile festlegen möchten, so können Sie die Multicast-Adresse und Ports als System-Properties definieren und diese Properties an der Befehlszeile verwenden, wenn Sie den Server starten. Im folgenden Beispiel ist jboss.mcast.addr der Variablenname für die Multicast-Adresse und jboss.mcast.port ist der Variablenname für den Port.

   <socket-binding name="jgroups-udp" port="55200"
    multicast-address="${jboss.mcast.addr:230.0.0.4}" multicast-port="${jboss.mcast.port:45688}"/>
   

   Sie können dann Ihren Server mittels folgender Befehlszeilenargumente starten:

   $ EAP_HOME/bin/domain.sh -Djboss.mcast.addr=228.11.11.11 -Djboss.mcast.port=45688

5. Verwendung eines anderen Protocol-Stacks

   Bei der JBoss EAP 5.x konnten Sie das standardmäßige Protocol-Stack, das für alle die jboss.default.jgroups.stack System-Property verwendenden Clustering-Dienst verwendet wurde, bearbeiten.

   $ EAP5_HOME/bin/run.sh -c all -Djboss.default.jgroups.stack=tcp

   Bei der JBoss EAP 6 ist das standardmäßige Protocol-Stack durch das JGroups-Subsystem innerhalb der domain.xml oder standalone-ha.xml definiert.

   <subsystem xmlns="urn:jboss:domain:jgroups:1.0" default-stack="udp">
       <stack name="udp">
           <!-- ... -->
       </stack>
   </subsystem>

6. Buddy-Replikation ersetzen

   JBoss EAP 5.x benutzte JBoss Cache Buddy Replication um die Replikation von Daten zu allen Instanzen eines Clusters zu unterdrücken.
   Bei der JBoss EAP 6 wurde Buddy Replication mit dem verteilten Cache von Infinispan, auch als DIST Modus bekannt, ersetzt. Verteilung ist ein starker Clusteringmodus, der es Infinispan ermöglicht linear zu skalieren, wenn dem Cluster mehr Server hinzugefügt werden. Es folgt ein Beispiel für die Konfiguration des Servers zur Verwendung des DIST Cachingmodus.
   1. Öffnen Sie eine Befehlszeile und starten Sie den Server mit HA oder Full Profile, zum Beispiel:

      EAP_HOME/bin/standalone.sh -c standalone-ha.xml

   2. Öffnen Sie eine weitere Befehlszeile und verbinden Sie sich mit dem Management-CLI.
      • In Linux geben Sie folgendes in der Befehlszeile ein:

        $ EAP_HOME/bin/jboss-cli.sh --connect
        

      • In Windows geben Sie folgendes in der Befehlszeile ein:

        C:\>EAP_HOME\bin\jboss-cli.bat --connect
        

      Sie sollten die folgende Antwort sehen:

      Connected to standalone controller at localhost:9999

   3. Geben Sie die folgenden Befehle ein:

      /subsystem=infinispan/cache-container=web/:write-attribute(name=default-cache,value=dist)
      /subsystem=infinispan/cache-container=web/distributed-cache=dist/:write-attribute(name=owners,value=3)
      :reload
      

      Sie sollten die folgende Antwort nach jedem Befehl sehen:

      "outcome" => "success"
      

      Diese Befehle ändern das dist <distributed-cache>-Element in der web <cache-container>-Konfiguration im infinispan-Subsystem der standalone-ha.xml-Datei wie folgt:

      <cache-container name="web" aliases="standard-session-cache" default-cache="dist" module="org.jboss.as.clustering.web.infinispan">
          <transport lock-timeout="60000"/>
          <replicated-cache name="repl" mode="ASYNC" batching="true">
              <file-store/>
          </replicated-cache>
          <replicated-cache name="sso" mode="SYNC" batching="true"/>
          <distributed-cache name="dist" owners="3" l1-lifespan="0" mode="ASYNC" batching="true">
              <file-store/>
          </distributed-cache>
      </cache-container>
      

      Weitere Informationen finden Sie im Kapitel Clustering in Web Applications im Development Guide für die JBoss EAP 6 im Kundenportal unter https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/.

Prozedur 3.21. Implementierung eines HA-Singleton-Dienstes

1. Schreiben Sie die HA-Singleton-Dienst-Applikation.

   Nachfolgend sehen Sie ein einfaches Beispiel für einen Service, der mit dem SingletonService Decorator eingebunden ist um als Singleton Dienst deployt zu werden. Ein vollständiges Beispiel finden Sie im cluster-ha-singleton Quickstart, der zusammen mit Red Hat JBoss Enterprise Application Platform 6 geliefert wird. Dieser Quickstart enthält sämtliche Anweisungen um die Applikation zu erstellen und zu deployen.

   1. Erstellen Sie einen Dienst.

      Nachfolgend sehen Sie ein Beispiel für einen Dienst:

      package org.jboss.as.quickstarts.cluster.hasingleton.service.ejb;
      
      import java.util.Date;
      import java.util.concurrent.atomic.AtomicBoolean;
      
      import javax.naming.InitialContext;
      import javax.naming.NamingException;
      
      import org.jboss.logging.Logger;
      import org.jboss.msc.service.Service;
      import org.jboss.msc.service.ServiceName;
      import org.jboss.msc.service.StartContext;
      import org.jboss.msc.service.StartException;
      import org.jboss.msc.service.StopContext;
      
      
      /**
       * @author <a href="mailto:wfink@redhat.com">Wolf-Dieter Fink</a>
       */
      public class HATimerService implements Service<String> {
          private static final Logger LOGGER = Logger.getLogger(HATimerService.class);
          public static final ServiceName SINGLETON_SERVICE_NAME = ServiceName.JBOSS.append("quickstart", "ha", "singleton", "timer");
      
          /**
           * A flag whether the service is started.
           */
          private final AtomicBoolean started = new AtomicBoolean(false);
      
          /**
           * @return the name of the server node
           */
          public String getValue() throws IllegalStateException, IllegalArgumentException {
              LOGGER.infof("%s is %s at %s", HATimerService.class.getSimpleName(), (started.get() ? "started" : "not started"), System.getProperty("jboss.node.name"));
              return "";
          }
      
          public void start(StartContext arg0) throws StartException {
              if (!started.compareAndSet(false, true)) {
                  throw new StartException("The service is still started!");
              }
              LOGGER.info("Start HASingleton timer service '" + this.getClass().getName() + "'");
      
              final String node = System.getProperty("jboss.node.name");
              try {
                  InitialContext ic = new InitialContext();
                  ((Scheduler) ic.lookup("global/jboss-cluster-ha-singleton-service/SchedulerBean!org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.Scheduler")).initialize("HASingleton timer @" + node + " " + new Date());
              } catch (NamingException e) {
                  throw new StartException("Could not initialize timer", e);
              }
          }
      
          public void stop(StopContext arg0) {
              if (!started.compareAndSet(true, false)) {
                  LOGGER.warn("The service '" + this.getClass().getName() + "' is not active!");
              } else {
                  LOGGER.info("Stop HASingleton timer service '" + this.getClass().getName() + "'");
                  try {
                      InitialContext ic = new InitialContext();
                      ((Scheduler) ic.lookup("global/jboss-cluster-ha-singleton-service/SchedulerBean!org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.Scheduler")).stop();
                  } catch (NamingException e) {
                      LOGGER.error("Could not stop timer", e);
                  }
              }
          }
      }
      

   2. Erstellen Sie einen Aktivator, der den Service als geclustertes Singleton installiert.

      Die folgende Liste ist ein Beispiel für einen Service Aktivator, der den HATimerService als geclusterten Singleton Dienst installiert:

      package org.jboss.as.quickstarts.cluster.hasingleton.service.ejb;
      
      import org.jboss.as.clustering.singleton.SingletonService;
      import org.jboss.logging.Logger;
      import org.jboss.msc.service.DelegatingServiceContainer;
      import org.jboss.msc.service.ServiceActivator;
      import org.jboss.msc.service.ServiceActivatorContext;
      import org.jboss.msc.service.ServiceController;
      
      
      /**
       * Service activator that installs the HATimerService as a clustered singleton service
       * during deployment.
       *
       * @author Paul Ferraro
       */
      public class HATimerServiceActivator implements ServiceActivator {
          private final Logger log = Logger.getLogger(this.getClass());
      
          @Override
          public void activate(ServiceActivatorContext context) {
              log.info("HATimerService will be installed!");
      
              HATimerService service = new HATimerService();
              SingletonService<String> singleton = new SingletonService<String>(service, HATimerService.SINGLETON_SERVICE_NAME);
              /*
               * To pass a chain of election policies to the singleton, for example, 
               * to tell JGroups to prefer running the singleton on a node with a
               * particular name, uncomment the following line:
               */
              // singleton.setElectionPolicy(new PreferredSingletonElectionPolicy(new SimpleSingletonElectionPolicy(), new NamePreference("node2/cluster")));
      
              singleton.build(new DelegatingServiceContainer(context.getServiceTarget(), context.getServiceRegistry()))
                      .setInitialMode(ServiceController.Mode.ACTIVE)
                      .install()
              ;
          }
      }
      

      Anmerkung

      Das oben angegebene Codebeispiel benutzt eine Klasse, org.jboss.as.clustering.singleton.SingletonService, die Teil des JBoss EAP private APIs ist. Ein öffentliches API wird in der EAP 7 Release verfügbar sein und die private Klasse wird überholt sein, aber diese Klassen werden für die Dauer des EAP 6.x Releasezyklus erhalten und verfügbar bleiben.

   3. Erstellen einer ServiceActivator Datei

      Erstellen Sie eine Datei namens org.jboss.msc.service.ServiceActivator im resources/META-INF/services/ Verzeichnis der Applikation. Fügen Sie eine Zeile hinzu, die den im vorherigen Schritt erstellten, vollqualifizierten Namen der ServiceActivator Klasse enthält.

      org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATimerServiceActivator 

   4. Erstellen Sie eine Singleton Bean, die einen Timer implementiert, der als Cluster-weiter Singleton Timer dient.

      Diese Singleton Bean darf kein Remote Interface haben und Sie dürfen keine Verweise auf sein lokales Interface aus anderen EJB irgendwelcher Applikationen anbringen. Dies verhindert einen Lookup durch einen Client oder andere Komponenten und stellt sicher, dass der SingletonService vollkommene Kontrolle über das Singleton hat.

      1. Erstellen des Scheduler Interface

         package org.jboss.as.quickstarts.cluster.hasingleton.service.ejb;
         
         /**
          * @author <a href="mailto:wfink@redhat.com">Wolf-Dieter Fink</a>
          */
         public interface Scheduler {
         
             void initialize(String info);
         
             void stop();
         
         }
         

      2. Erstellen Sie die Singleton Bean, die den Cluster-weiten Singleton Timer implementiert.

         package org.jboss.as.quickstarts.cluster.hasingleton.service.ejb;
         
         import javax.annotation.Resource;
         import javax.ejb.ScheduleExpression;
         import javax.ejb.Singleton;
         import javax.ejb.Timeout;
         import javax.ejb.Timer;
         import javax.ejb.TimerConfig;
         import javax.ejb.TimerService;
         
         import org.jboss.logging.Logger;
         
         
         /**
          * A simple example to demonstrate a implementation of a cluster-wide singleton timer.
          *
          * @author <a href="mailto:wfink@redhat.com">Wolf-Dieter Fink</a>
          */
         @Singleton
         public class SchedulerBean implements Scheduler {
             private static Logger LOGGER = Logger.getLogger(SchedulerBean.class);
             @Resource
             private TimerService timerService;
         
             @Timeout
             public void scheduler(Timer timer) {
                 LOGGER.info("HASingletonTimer: Info=" + timer.getInfo());
             }
         
             @Override
             public void initialize(String info) {
                 ScheduleExpression sexpr = new ScheduleExpression();
                 // set schedule to every 10 seconds for demonstration
                 sexpr.hour("*").minute("*").second("0/10");
                 // persistent must be false because the timer is started by the HASingleton service
                 timerService.createCalendarTimer(sexpr, new TimerConfig(info, false));
             }
         
             @Override
             public void stop() {
                 LOGGER.info("Stop all existing HASingleton timers");
                 for (Timer timer : timerService.getTimers()) {
                     LOGGER.trace("Stop HASingleton timer: " + timer.getInfo());
                     timer.cancel();
                 }
             }
         }
         

2. Starten Sie jede JBoss EAP 6 Instanz mit aktiviertem Clustering.

   Um Clustering für Standalone Server zu aktivieren, müssen Sie jeden Server mit dem HA Profil starten, indem Sie einen eindeutigen Knotennamen und Port Offset für jede Instanz benutzen.
   • Benutzen Sie in Linux folgende Befehlssyntax um die Server zu starten:

     EAP_HOME/bin/standalone.sh --server-config=standalone-ha.xml -Djboss.node.name=UNIQUE_NODE_NAME -Djboss.socket.binding.port-offset=PORT_OFFSET

     Beispiel 3.3. Start mehrerer Standalone Server in Linux

     $ EAP_HOME/bin/standalone.sh --server-config=standalone-ha.xml -Djboss.node.name=node1
     $ EAP_HOME/bin/standalone.sh --server-config=standalone-ha.xml -Djboss.node.name=node2 -Djboss.socket.binding.port-offset=100

   • Benutzen Sie in Microsoft Windows folgende Befehlssyntax um den Server zu starten:

     EAP_HOME\bin\standalone.bat --server-config=standalone-ha.xml -Djboss.node.name=UNIQUE_NODE_NAME -Djboss.socket.binding.port-offset=PORT_OFFSET

     Beispiel 3.4. Start mehrerer Standalone Server in Microsoft Windows

     C:> EAP_HOME\bin\standalone.bat --server-config=standalone-ha.xml -Djboss.node.name=node1
     C:> EAP_HOME\bin\standalone.bat --server-config=standalone-ha.xml -Djboss.node.name=node2 -Djboss.socket.binding.port-offset=100

   Anmerkung

   Wenn Sie die Befehlszeilenargumente lieber nicht benutzen wollen, können Sie die standalone-ha.xml Datei für jede Serverinstanz darauf konfigurieren, auf einem separaten Interface zu binden.

3. Deployment der Applikation auf die Server

   Folgender Maven Befehl deployt die Applikation auf einem Standalone Server, der auf Standardports läuft.

   mvn clean install jboss-as:deploy

   Übertragen Sie die Servernamen um zusätzliche Server zu deployen. Wenn es auf einem anderen Host ist, übertragen Sie Hostnamen und Portnummer auf die Befehlszeile:

   mvn clean package jboss-as:deploy -Djboss-as.hostname=localhost -Djboss-as.port=10099

   Siehe cluster-ha-singleton Quickstart, welches mit JBoss EAP 6 für Maven Konfiguration und Deployment Details geliefert wird.

Prozedur 3.22. Hinzufügen der Maven Projektkonfiguration für Remote-Aufrufe von Session Beans

1. Fügen Sie die erforderlichen Projektabhängigkeiten hinzu

   Die pom.xml für das Projekt muss aktualisiert werden, um die notwendigen Abhängigkeiten zu enthalten.

2. Fügen Sie die jboss-ejb-client.properties-Datei hinzu

   Das JBoss EJB Client-API erwartet eine Datei im root des Projekts namens jboss-ejb-client.properties, die die Verbindungsinformationen für den JNDI-Dienst enthält. Fügen Sie diese Datei dem src/main/resources/-Verzeichnis Ihres Projekts mit folgendem Inhalt hinzu.

   # In the following line, set SSL_ENABLED to true for SSL
   remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
   remote.connections=default
   # Uncomment the following line to set SSL_STARTTLS to true for SSL
   # remote.connection.default.connect.options.org.xnio.Options.SSL_STARTTLS=true
   remote.connection.default.host=localhost
   remote.connection.default.port = 4447
   remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
   # Add any of the following SASL options if required
   # remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
   # remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT=false
   # remote.connection.default.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS=JBOSS-LOCAL-USER
   

   Ändern Sie den Host-Namen und Port so, dass diese mit Ihrem Server übereinstimmen. 4447 ist die Standardportnummer. Für eine sichere Verbindung setzen Sie die SSL_ENABLED-Zeile auf true und kommentieren Sie die SSL_STARTTLS-Zeile aus. Das Remoting-Interface im Container unterstützt gesicherte und ungesicherte Verbindungen am selben Port.

3. Fügen Sie Abhängigkeiten für die Remote Business Interfaces hinzu

   Fügen Sie die Maven-Abhängigkeiten der pom.xml für die Remote Business-Interfaces der Session-Beans hinzu.

   <dependency>
      <groupId>org.jboss.as.quickstarts</groupId>
      <artifactId>jboss-ejb-remote-server-side</artifactId>
      <type>ejb-client</type>
      <version>${project.version}</version>
   </dependency>

Prozedur 3.23. Erhalt eines Bean-Proxy mittels JNDI und Methodenaufruf des Bean

1. Handhabung geprüfter Ausnahmen

   Zwei der im folgenden Code (InitialContext() und lookup()) verwendeten Methoden, besitzen eine geprüfte Ausnahme vom Typ javax.naming.NamingException. Diese Methodenaufrufe müssen entweder in einem "try/catch"-Block eingeschlossen sein, der die NamingException auffängt oder in einer Methode, die zur Meldung der NamingException deklariert ist. Der ejb-remote-Quickstart verwendet die zweite Variante.

2. Erstellen Sie einen JNDI-Kontext

   Ein JNDI-Kontextobjekt liefert den Mechanismus zum Anfragen von Ressourcen vom Server. Erstellen Sie einen JNDI-Kontext mittels folgendem Code:

   final Hashtable jndiProperties = new Hashtable();
   jndiProperties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
   final Context context = new InitialContext(jndiProperties);

   Die Verbindungseigenschaften für den JNDI-Dienst werden aus der jboss-ejb-client.properties-Datei gelesen.

3. Verwenden Sie die lookup() Methode des JNDI-Kontexts zum Erhalt eines Bean Proxy

   Rufen Sie die lookup()-Methode des Bean-Proxy auf und geben sie dieser den JNDI-Name des benötigten Session-Beans. Dies gibt ein Objekt wieder, das an den Typ des Remote Business-Interface verteilt werden muss, das die Methoden enthält, die Sie aufzurufen wünschen.

   
   final RemoteCalculator statelessRemoteCalculator = (RemoteCalculator) context.lookup(
       "ejb:/jboss-ejb-remote-server-side//CalculatorBean!" + 
       RemoteCalculator.class.getName());
   

   Session-Bean JNDI-Namen werden unter Verwendung einer besonderen Syntax definiert. Weitere Informationen finden Sie unter Abschnitt 3.2.10.3, »EJB JNDI Namengebungsreferenz« .

4. Aufrufen von Methoden

   Jetzt da Sie ein Proxy-Bean-Objekt besitzen, können Sie jede beliebige der im Remote Business-Interface enthaltenen Methoden aufrufen.

   int a = 204;
   int b = 340;
   System.out.println("Adding " + a + " and " + b + " via the remote stateless calculator deployed on the server");
   int sum = statelessRemoteCalculator.add(a, b);
   System.out.println("Remote calculator returned sum = " + sum);

   Das Proxy-Bean gibt die Methodenaufrufanfrage an das Session-Bean auf dem Server, wo es ausgeführt wird. Das Ergebnis wird an das Proxy-Bean wiedergegeben, das es dann an den Aufrufer wiedergibt. Die Kommunikation zwischen dem Proxy-Bean und dem Remote Session Bean is für den Aufrufer transparent.

Prozedur 3.25. Migration der Seam 2.2 Archive

1. Aktualisierung der Datenquellen-Konfiguration

   Einige Seam 2.2 Beispiele verwenden die standardmäßige JDBC-Datenquelle namens java:/ExampleDS. Diese Standard-Datenquelle hat sich bei der JBoss EAP 6 zu java:jboss/datasources/ExampleDS geändert. Falls Ihre Applikation die Beispieldatenbank verwendet, so so können Sie eine der folgenden Vorgehensweisen wählen:

   • Falls Sie die mit der JBoss EAP 6 gelieferte Beispieldatenbank verwenden möchten, so bearbeiten Sie die META-INF/persistence.xml-Datei, damit sie das bestehende jta-data-source-Element mit dem Datenquellen JNDI-Namen der Beispieldatenbank ersetzt:

     <!-- <jta-data-source>java:/ExampleDS</jta-data-source> -->
     <jta-data-source>java:jboss/datasources/ExampleDS</jta-data-source>

   • Falls Sie Ihre bestehende Datenbank lieber behalten möchten, so können Sie die Datenquellendefinition der EAP_HOME/standalone/configuration/standalone.xml-Datei hinzufügen.

     Wichtig

     Sie müssen den Server stoppen, ehe Sie die Server Konfigurations-Datei bearbeiten, damit Ihre Änderungen bei einem Server-Neustart als dauerhaft erstellt werden.
     Die folgende Definition ist eine Kopie der standardmäßigen HSQL Datenquelle, die in der JBoss EAP 6 definiert ist:

     <datasource name="ExampleDS" jndi-name="java:/ExampleDS" enabled="true" jta="true" use-java-context="true" use-ccm="true">
        <connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1</connection-url>
        <driver>h2</driver>
        <security>
           <user-name>sa</user-name>
           <password>sa</password>
        </security>
     </datasource>

   • Sie können die Datenquellen-Definition auch mittels der Management-CLI-Befehlszeilen-Interface hinzufügen. Nachfolgend sehen Sie ein Beispiel für die Syntax, mit der Sie eine Datenquelle hinzufügen. Der "\" am Ende der Zeile zeigt die Fortsetzung des Befehls in der folgenden Zeile an.

     Beispiel 3.5. Beispiel der Syntax für die Hinzufügung der Datenquellen-Definition

     $ EAP_HOME/bin/jboss-cli --connect 
     [standalone@localhost:9999 /] data-source add --name=ExampleDS --jndi-name=java:/ExampleDS \ 
           --connection-url=jdbc:h2:mem:test;DB_CLOSE_DELAY=-1 --driver-name=h2 \ 
           --user-name=sa --password=sa
     

   Weitere Informationen zur Konfiguration einer Datenquelle finden Sie unter Abschnitt 3.1.6.2, »Aktualisierung der Datenquellen-Konfiguration«.

2. Fügen Sie die erforderlichen Abhängigkeiten hinzu

   Da Seam 2.2 Applikationen JSF 1.2 verwenden, müssen Sie Abhängigkeiten für die JSF 1.2 Module hinzufügen und die JSF 2.0 Module ausschließen. Um dies zu bewerkstelligen, müssen Sie eine jboss-deployment-structure.xml-Datei im META-INF/-Verzeichnis des EAR erstellen, das folgende Daten enthält:

   <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0">
     <deployment>
         <dependencies>
           <module name="javax.faces.api" slot="1.2" export="true"/>
                 <module name="com.sun.jsf-impl" slot="1.2" export="true"/>
         </dependencies>
     </deployment>
     <sub-deployment name="jboss-seam-booking.war">
       <exclusions>
           <module name="javax.faces.api" slot="main"/>
                 <module name="com.sun.jsf-impl" slot="main"/>
         </exclusions>
         <dependencies>
           <module name="javax.faces.api" slot="1.2"/>
                 <module name="com.sun.jsf-impl" slot="1.2"/>
         </dependencies>
     </sub-deployment>
   </jboss-deployment-structure>

   Falls Ihre Applikation Protokollierungs-Frameworks von Drittanbietern verwendet, so müssen Sie diese Abhängigkeiten wie hier beschrieben hinzufügen: Abschnitt 3.1.4.1, »Bearbeitung von Protokollierungsabhängigkeiten«.

3. Falls Ihre Applikation Hibernate 3.x verwendet, so versuchen Sie die Applikation zunächst unter Verwendung von Hibernate 4 Bibliotheken auszuführen

   Falls Ihre Applikation Seam Managed Persistence Context, Hibernate Suche, Validierung und andere Features, die sich in Hibernate 4 geändert haben, nicht verwendet, so können Sie möglicherweise die Hibernate 4 Bibliotheken verwenden. Falls Sie jedoch ClassNotFoundExceptions oder ClassCastExceptions sehen, die auf Hibernate Klassen verweisen oder Fehler ähnlich dem folgenden sehen, so folgen Sie den Anweisungen im nachfolgenden Schritt und bearbeiten Sie die Applikation dahingehend, dass sie Hibernate 3.3 Bibliotheken verwendet.

           Caused by: java.lang.LinkageError: loader constraint violation in interface itable initialization: when resolving method "org.jboss.seam.persistence.HibernateSessionProxy.getSession(Lorg/hibernate/EntityMode;)Lorg/hibernate/Session;" the class loader (instance of org/jboss/modules/ModuleClassLoader) of the current class, org/jboss/seam/persistence/HibernateSessionProxy, and the class loader (instance of org/jboss/modules/ModuleClassLoader) for interface org/hibernate/Session have different Class objects for the type org/hibernate/Session used in the signature
   

4. Kopieren Sie abhängige Archive von außerhalb liegenden Frameworks oder anderen Orten

   Falls Ihre Applikation Hibernate 3.x verwendet und Sie Hibernate 4 nicht erfolgreich mit Ihrer Applikation verwenden können, so müssen Sie die Hibernate 3.x JARs in das /lib-Verzeichnis kopieren und das Hibernate-Modul im Deployments-Abschnitt der META-INF/jboss-deployment-structure.xml wie folgt ausschließen:

   <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0">
    <deployment>
      <exclusions>
        <module name="org.hibernate"/>
      </exclusions>
    <deployment>
   </jboss-deployment-structure>

   Hier sind zusätzliche Schritte, die Sie beim bündeln von Hibernate 3.x mit Ihrer Applikation vornehmen müssen. Weitere Informationen finden Sie unter Abschnitt 3.2.2.2, »Konfiguration der Änderungen bei Applikationen, die Hibernate und JPA verwenden«.

5. Fehlerbehebung und Auflösung von Seam 2.2 JNDI-Fehlern

   Bei der Migration einer Seam 2.2 Applikation kann es sein, dass Sie javax.naming.NameNotFoundExceptionFehler wie den folgenden im Protokoll sehen:

   javax.naming.NameNotFoundException: Name 'jboss-seam-booking' not found in context ''

   Falls Sie JNDI-Lookups nicht durch den Code hindurch bearbeiten wollen, so können Sie die components.xml-Datei der Applikation wie folgt bearbeiten:

   1. Ersetzen Sie das bestehende core-init Element

      Zuerst müssen Sie das bestehende core-init Element wie folgt ersetzen:

      <!-- <core:init jndi-pattern="jboss-seam-booking/#{ejbName}/local" debug="true" distributable="false"/>   -->
      <core:init debug="true" distributable="false"/>
      

   2. Finden Sie die JNDI-Binding INFO-Nachrichten im Serverprotokoll

      Anschließend finden Sie die JNDI-Binding INFO-Nachrichten im Serverprotokoll, die beim Deployment der Applikation gedruckt wurden. Die JNDI-Binding-Nachrichten sollten in etwa so aussehen:

      INFO org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor (MSC service thread 1-1) JNDI bindings for session bean
      named AuthenticatorAction in deployment unit subdeployment "jboss-seam-booking.jar" of deployment "jboss-seam-booking.ear" are as follows:
          java:global/jboss-seam-booking/jboss-seam-booking.jar/AuthenticatorAction!org.jboss.seam.example.booking.Authenticator
          java:app/jboss-seam-booking.jar/AuthenticatorAction!org.jboss.seam.example.booking.Authenticator
          java:module/AuthenticatorAction!org.jboss.seam.example.booking.Authenticator
          java:global/jboss-seam-booking/jboss-seam-booking.jar/AuthenticatorAction
          java:app/jboss-seam-booking.jar/AuthenticatorAction
          java:module/AuthenticatorAction
      

   3. Fügen Sie Komponentenelemente hinzu

      Für jede JNDI-Binding INFO-Nachricht im Protokoll fügen Sie dem components.xml-Datei ein entsprechendes component-Element hinzu:

      <component class="org.jboss.seam.example.booking.AuthenticatorAction" jndi-name="java:app/jboss-seam-booking.jar/AuthenticatorAction" />

   Weitere Informationen zur Fehlerbehebung und Auflösung von Migrationsproblemen finden Sie unter Abschnitt 4.2.1, »Fehler- und Problembehebung bei der Migration«.
   Eine Liste bekannter Migrationsprobleme mit Seam 2 Archiven finden Sie unter Abschnitt 3.2.13.2, »Seam 2.2 Archiv-Migrationsprobleme«.