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«