Die Red Hat JBoss Enterprise Application Platform 7 (JBoss EAP) ist eine Middleware-Plattform, die auf offenen Standards basiert und mit der Java Enterprise Edition 7 Spezifikation konform geht. Sie integriert den WildFly Application Server 10 mit Messaging, Hochverfügbarkeits-Clustering und anderen Technologien.

Die JBoss EAP hat eine modulare Struktur, die es ermöglicht, Dienste erst bei Bedarf zu aktivieren und so den Systemstart zu beschleunigen.

Die Management-Konsole und das Management Command-Line Interface (CLI) machen das Bearbeiten von XML-Konfigurationsdateien überflüssig und ermöglichen die Verwendung von Skripten und die Automatisierung von Aufgaben.

Die JBoss EAP bietet zwei Betriebsmodi für JBoss EAP Instanzen: den Betrieb als Standalone-Server oder als Managed Domain. Der Betriebsmodus Standalone-Server steht für die Ausführung der JBoss EAP als einzelne Serverinstanz. Der Betriebsmodus Managed Domain ermöglicht die Verwaltung mehrerer JBoss EAP Instanzen von einem einzigen Kontrollpunkt aus.

Des Weiteren beinhaltet die JBoss EAP APIs und Entwicklungs-Frameworks zur schnellen Entwicklung sicherer und skalierbarer Java EE Anwendungen.

The purpose of this guide is to document the changes that are required to successfully run and deploy Red Hat JBoss Enterprise Application Platform 6 applications on Red Hat JBoss Enterprise Application Platform 7. It provides information about the new features available in this release, the deprecated and unsupported features, and any application and server configuration updates that might be required to prevent changes in application behavior.

Zudem bietet es Informationen über Tools, die bei der Migration helfen können, wie z.B. Windup, was die Migration von Java-Applikationen vereinfacht, oder das JBoss Server Migration Tool, welches die Serverkonfiguration aktualisiert.

Sobald die Applikation erfolgreich bereitgestellt wurde und läuft, können Sie mit der Planung der Upgrades einzelner Komponenten beginnen, um die neuen Funktionen und Features der JBoss EAP 6 zu nutzen.

Falls Sie beabsichtigen, Ihre JBoss EAP 5 Applikationen direkt zu JBoss EAP 7 zu migrieren, werfen Sie bitte einen Blick auf Migrieren von älteren JBoss EAP Releases.

In diesem Dokument wird die Variable EAP_HOME verwendet, um den Pfad zur Installation der Red Hat JBoss EAP anzugeben. Ersetzen Sie diese Variable durch den tatsächlichen Pfad zu Ihrer JBoss EAP Installation.

In JBoss EAP 7, an effort was made to provide backward compatibility for JBoss EAP 6 applications. However, if your application uses features that were deprecated or functionality that was removed from JBoss EAP 7, you might need to make changes to your application code.

In addition, a number of things have changed in this release that might impact deployment of JBoss EAP 7 applications. It is recommended that you do some research and planning before you attempt to migrate your application.

Wenn Sie sich mit den Änderungen der Funktionen, den Entwicklungsmaterialien und den Tools zur Migration vertraut gemacht haben, können Sie mit der Evaluierung Ihrer Anwendungen und Ihrer Serverkonfiguration beginnen, um bestimmen zu können, welche Änderungen zur Ausführung der JBoss EAP 7 notwendig sind.

Java EE 7 enthält viele Verbesserungen, die das Entwickeln und Betreiben funktionsreicher Applikationen in Private und Public Clouds erleichtern. Es beinhaltet neue Features und die neuesten Standards wie HTML5, WebSocket, JSON, Batch und Concurrency Utilities. Aktualisierungen umfassen JPA 2.1, JAX-RS 2.0, Servlet 3.1, Expression Language 3.0, JMS 2.0. JSF 2.2, EJB 3.2, CDI 1.2 und Bean Validation 1.1.

Weitere Information über Java EE 7, einschließlich Tutorials, finden Sie auf der Oracle-Website: Java EE at a Glance

JBoss EAP 7 enthält einige nennenswerte Aktualisierungen und Verbesserungen im Vergleich zur Vorgängerrelease.

For a complete list of new features, see New Features and Enhancements in the JBoss EAP 7 Release Notes.

Before you migrate your application, be aware that some features that were available in previous releases of JBoss EAP might be deprecated or no longer supported.

Der Support wurde aufgrund hoher Wartungskosten, geringem Interesse der Community und besseren Alternativlösungen für manche Technologien entfernt. Die folgenden Funktionen werden in JBoss EAP 7 nicht unterstützt.

For a comprehensive list of deprecated and unsupported features, see Unsupported and Deprecated Functionality in the JBoss EAP 7 Release Notes.

Be sure to review the JBoss EAP Getting Started Guide. It contains the following important information:

Each application and server configuration is unique and you must thoroughly understand the components and architecture of the existing application and server platform before you attempt the migration. Your migration plan should include a detailed roadmap for testing and roll out to production that takes into account the following information.

Bevor Sie Ihre Applikation migrieren, sollten Sie sich der folgenden Risiken bewusst sein.

Vergewissern Sie sich, dass auch die aktuelle Serverkonfiguration und Applikationen vor Beginn der Migration gesichert wurden.

To install JBoss EAP 7 using RPMs, see the JBoss EAP Installation Guide.

The migration advice in this guide also applies to migrating RPM installations of JBoss EAP, but you might need to alter some steps (such as how to start JBoss EAP) to suit an RPM installation compared to a ZIP or installer installation.

If you run JBoss EAP 6 as a service, be sure to review Configuring JBoss EAP to Run as a Service in the JBoss EAP Installation Guide for updated configuration instructions for JBoss EAP 7.

Windup (im Red Hat JBoss Migration Toolkit enthalten) ist ein erweiterbares und konfigurierbares regelbasiertes Tool, das die Migration von Java-Applikationen vereinfacht. Es analysiert die APIs, Technologien und Architekturen, die von den zu migrierenden Applikationen verwendet werden, und liefert detaillierte Migrationsberichte für jede Applikation. Diese Berichte liefern die folgenden Informationen.

Sie können Windup zur Analyse des Codes und der Architektur Ihrer JBoss EAP 6 Applikationen verwenden, bevor Sie diese zu JBoss EAP 7 migrieren. Das Windup-Regelset zur Migration von JBoss EAP 6 zu JBoss EAP 7 untersucht XML-Deskriptoren sowie speziellen Applikationscode und Parameter, die durch eine alternative Konfiguration ersetzt werden müssen, wenn zu JBoss EAP 7 migriert wird.

Weitere Informationen über die Verwendung von Windup zur Analyse Ihrer JBoss EAP 6 Applikationen finden Sie im Windup User Guide.

Das JBoss Server Migration Tool, was sich derzeit in der Entwicklung befindet, wird in Zukunft die bevorzugte Methode zur Aktualisierung Ihrer Konfiguration sein, um die neuen Features und Einstellungen in JBoss EAP 7 zu implementieren und gleichzeitig Ihre vorhandene Konfiguration beizubehalten.

Das JBoss Server Migration Tool liest Ihre vorhandene JBoss EAP 6 Serverkonfigurationsdatei und fügt Konfigurationen für die neuen Subsysteme hinzu, aktualisiert vorhandene Subsystemkonfigurationen mit neuen Features und entfernt hinfällige Subsystemkonfigurationen.

Die aktuelle Vorab-Release der Binärdistribution des JBoss Server Migration Tools steht zum Download zur Verfügung unter https://github.com/wildfly/wildfly-server-migration/releases. Diese Version unterstützt die Migration von eigenständigen Servern von JBoss EAP 6.4 zu JBoss EAP 7.0. Allgemeine Informationen über die Nutzung des Tools finden Sie im JBoss Server Migration Tool User Guide.

Um Ihre Server-Konfiguration von JBoss EAP 6 zu JBoss EAP 7 zu migrieren, können Sie entweder das JBoss Server Migration Tool verwenden oder mithilfe der migrate-Operation der Management-CLI eine manuelle Migration durchführen.

JBoss Server Migration Tool

Das JBoss Server Migration Tool, was sich derzeit in der Entwicklung befindet, wird in Zukunft die bevorzugte Methode zur Aktualisierung Ihrer Konfiguration sein, um die neuen Features und Einstellungen in JBoss EAP 7 zu implementieren und gleichzeitig Ihre vorhandene Konfiguration beizubehalten.

migrate-Operation der Management-CLI

Sie können die migrate-Operation der Management-CLI verwenden, um die Subsysteme jacorb, messaging und web in der JBoss EAP 6 Serverkonfigurationsdatei zu aktualisieren, sodass diese unter der neuen Release laufen können. Beachten Sie jedoch, dass das Ergebnis keine vollständige JBoss EAP 7 Konfiguration darstellt. Zum Beispiel:

Weitere Informationen über die Verwendung der migrate-Operation zur Migration der Serverkonfiguration finden Sie unter migrate-Operation der Management-CLI.

Sie können die Management-CLI dazu verwenden, um Ihre JBoss EAP 6 Serverkonfigurationsdateien für die Verwendung mit JBoss EAP 7 zu aktualisieren. Die Management-CLI bietet eine migrate-Operation, um automatisch die Subsysteme jacorb, messaging und web von der vorherigen Release auf die neue Konfiguration zu aktualisieren. Sie können auch die Operation describe-migration für die Subsysteme jacorb, messaging und web ausführen, um die vorgeschlagenen Konfigurationsänderungen zu überprüfen, bevor Sie die Migration durchführen. Es gibt keinen Ersatz für die Subsysteme cmp, jaxr und threads, weshalb diese aus der Serverkonfiguration entfernt werden müssen.

Starten des Servers und der Management-CLI

Folgen Sie den nachstehenden Schritten, um Ihre JBoss EAP 6 Serverkonfiguration für die Ausführung auf JBoss EAP 7 zu aktualisieren.

Migrieren der JacORB-, Messaging- und Web-Subsysteme

Protokollnachrichten tragen ein Präfix mit dem Projektcode für das Subsystem, das die Nachricht meldet. Die Präfixe für alle Protokolleinträge haben sich in JBoss EAP 7 geändert.

For a complete list of the new log message project code prefixes used in JBoss EAP 7, see Project Codes Used in JBoss EAP in the JBoss EAP Development Guide.

If you use the management CLI migrate operation to upgrade your existing configuration, you might see exceptions in the server log when you deploy your EJB applications.

DuplicateServiceException

Die folgende DuplicateServiceException wird durch Änderungen beim Cache-Verhalten in JBoss EAP 7 verursacht.

ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.unit."mdb-1.0-SNAPSHOT.jar".cache-dependencies-installer: org.jboss.msc.service.StartException in service jboss.deployment.unit."mdb-1.0-SNAPSHOT.jar".cache-dependencies-installer: Failed to start service
...
Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.infinispan.ejb."mdb-1.0-SNAPSHOT.jar".config is already registered

Sie müssen den Cache neu konfigurieren, um diesen Fehler zu beseitigen.

In JBoss EAP 7 ersetzt ActiveMQ Artemis nun HornetQ als JMS-Support-Provider. Dieser Abschnitt beschreibt, wie die Konfiguration und die zugehörigen Messaging-Daten migriert werden können.

/subsystem=messaging:migrate

/subsystem=messaging:describe-migration

/subsystem=messaging:describe-migration(add-legacy-entries=true)
/subsystem=messaging:migrate(add-legacy-entries=true)

java -jar -mp MODULE_PATH org.hornetq.exporter MESSAGING_BINDINGS_DIRECTORY MESSAGING_JOURNAL_DIRECTORY MESSAGING_PAGING_DIRECTORY MESSAGING_LARGE_MESSAGES_DIRECTORY > OUTPUT_DATA.xml

<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.1" name="org.hornetq.exporter">
    <main-class name="org.hornetq.jms.persistence.impl.journal.XmlDataExporter"/>
    <properties>
        <property name="jboss.api" value="deprecated"/>
    </properties>
    <dependencies>
        <module name="org.hornetq"/>
    </dependencies>
</module>

/subsystem=messaging-activemq/server=default:import-journal(file=OUTPUT_DIRECTORY/OldMessagingData.xml)

<hornetq-server>
  ...
  <jms-destinations>
     <jms-queue name="testQueue">
        <entry name="queue/test"/>
         <entry name="java:jboss/exported/jms/queue/test"/>
      </jms-queue>
  </jms-destinations>
  ...
</hornetq-server>

<server name="default">
  ...
  <jms-queue name="testQueue" entries="queue/test java:jboss/exported/jms/queue/test"/>
  ...
</server>

<subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
  <server name="default">
    ...
    <incoming-interceptors>
      <class name="com.mycompany.incoming.myInterceptor" module="com.mycompany" />
      <class name="com.othercompany.incoming.myOtherInterceptor" module="com.othercompany" />
    </incoming-interceptors>
    <outgoing-interceptors>
      <class name="com.mycompany.outgoing.myInterceptor" module="com.mycompany" />
      <class name="com.othercompany.outgoing.myOtherInterceptor" module="com.othercompany" />
    </outgoing-interceptors>
  </server>
</subsystem>

The HornetQ component in JBoss EAP 6 provided its own JMX management; however, it was not recommended and is now deprecated and no longer supported. If you relied on this feature in JBoss EAP 6, you must migrate your management tooling to use either the JBoss EAP management CLI or the JMX management provided with JBoss EAP 7.

You must also upgrade your client libraries to use the jboss-client.jar that ships with JBoss EAP 7.

The following is an example of HornetQ JMX management code that was used in JBoss EAP 6.

JMXConnector connector = null;
try {
    HashMap environment = new HashMap();
    String[] credentials = new String[]{"admin", "Password123!"};
    environment.put(JMXConnector.CREDENTIALS, credentials);

    // HornetQ used the protocol "remoting-jmx" and port "9999"
    JMXServiceURL beanServerUrl = new JMXServiceURL("service:jmx:remoting-jmx://127.0.0.1:9999");

    connector = JMXConnectorFactory.connect(beanServerUrl, environment);
    MBeanServerConnection mbeanServer = connector.getMBeanServerConnection();

    // The JMX object name pointed to the HornetQ JMX management
    ObjectName objectName = new ObjectName("org.hornetq:type=Server,module=JMS");

    // The invoked method name was "listConnectionIDs"
    String[] connections = (String[]) mbeanServer.invoke(objectName, "listConnectionIDs", new Object[]{}, new String[]{});
    for (String connection : connections) {
        System.out.println(connection);
    }
} finally {
    if (connector != null) {
      connector.close();
   }
}

The following is an example of the equivalent code needed for ActiveMQ Artemis in JBoss EAP 7.

JMXConnector connector = null;
try {
    HashMap environment = new HashMap();
    String[] credentials = new String[]{"admin", "Password123!"};
    environment.put(JMXConnector.CREDENTIALS, credentials);

    // ActiveMQ Artemis uses the protocol "remote+http" and port "9990"
    JMXServiceURL beanServerUrl = new JMXServiceURL("service:jmx:remote+http://127.0.0.1:9990");

    connector = JMXConnectorFactory.connect(beanServerUrl, environment);
    MBeanServerConnection mbeanServer = connector.getMBeanServerConnection();

    // The JMX object name points to the new JMX management in the `messaging-activemq` subsystem
    ObjectName objectName = new ObjectName("jboss.as:subsystem=messaging-activemq,server=default");

    // The invoked method name is now "listConnectionIds"
    String[] connections = (String[]) mbeanServer.invoke(objectName, "listConnectionIds", new Object[]{}, new String[]{});
    for (String connection : connections) {
        System.out.println(connection);
    }
} finally {
    if (connector != null) {
      connector.close();
   }
}

Notice that the method names and parameters have changed in the new implementation. You can find the new method names in the JConsole by following these steps.

Die JacORB-Implementierung wurde in JBoss EAP 7 ersetzt durch eine Downstream-Version von OpenJDK ORB.

Das Erweiterungsmodul org.jboss.as.jacorb in EAP_HOME/modules/system/layers/base/ wurde durch das Erweiterungsmodul org.wildfly.iiop-openjdk ersetzt.

Der Namespace urn:jboss:domain:jacorb:1.4 der Subsystemkonfiguration in der Serverkonfigurationsdatei wurde ersetzt durch den Namespace urn:jboss:domain:iiop-openjdk:1.0.

Nachfolgend sehen Sie ein Beispiel der standardmäßigen Konfiguration für das jacorb-Subsystem in JBoss EAP 6.

<subsystem xmlns="urn:jboss:domain:jacorb:1.4">
    <orb socket-binding="jacorb" ssl-socket-binding="jacorb-ssl">
        <initializers security="identity" transactions="spec"/>
    </orb>
</subsystem>

Nachfolgend sehen Sie ein Beispiel der standardmäßigen Konfiguration für das iiop-openjdk-Subsystem in JBoss EAP 6.

<subsystem xmlns="urn:jboss:domain:iiop-openjdk:1.0">
    <orb socket-binding="jacorb" ssl-socket-binding="jacorb-ssl" />
    <initializers security="identity" transactions="spec" />
</subsystem>

Die neue iiop-openjdk-Subsystemkonfiguration akzeptiert nur eine Untergruppe der bisherigen Elemente und Parameter. Nachfolgend sehen Sie ein Beispiel einer Konfiguration für das jacorb-Subsystem in der bisherigen Release von JBoss EAP, die alle gültigen Elemente und Parameter enthält:

<subsystem xmlns="urn:jboss:domain:jacorb:1.4">
   <orb name="JBoss" print-version="off" use-imr="off" use-bom="off"  cache-typecodes="off"
       cache-poa-names="off" giop-minor-version="2" socket-binding="jacorb" ssl-socket-binding="jacorb-ssl">
       <connection retries="5" retry-interval="500" client-timeout="0" server-timeout="0"
           max-server-connections="500" max-managed-buf-size="24" outbuf-size="2048"
           outbuf-cache-timeout="-1"/>
       <initializers security="off" transactions="spec"/>
   </orb>
   <poa monitoring="off" queue-wait="on" queue-min="10" queue-max="100">
       <request-processors pool-size="10" max-threads="32"/>
   </poa>
   <naming root-context="JBoss/Naming/root" export-corbaloc="on"/>
   <interop sun="on" comet="off" iona="off" chunk-custom-rmi-valuetypes="on"
       lax-boolean-encoding="off" indirection-encoding-disable="off" strict-check-on-tc-creation="off"/>
   <security support-ssl="off" add-component-via-interceptor="on" client-supports="MutualAuth"
       client-requires="None" server-supports="MutualAuth" server-requires="None"/>
   <properties>
       <property name="some_property" value="some_value"/>
   </properties>
</subsystem>

Die folgenden Elementparameter werden nicht mehr unterstützt und müssen entfernt werden.

Die folgenden on/off-Parameter werden nicht mehr unterstützt und werden nicht migriert, wenn Sie die migrate-Operation der Management-CLI ausführen. Falls diese auf on gesetzt sind, erhalten Sie eine Migrationswarnung. Andere on/off-Parameter, die nicht in dieser Tabelle erwähnt werden, wie z.B. <security support-ssl="on|off">, werden nach wie vor unterstützt und können erfolgreich migriert werden. Der einzige Unterschied besteht darin, dass deren Werte von on/off auf true/false geändert werden.

Die JBoss EAP 6 Serverkonfiguration enthielt ein threads-Subsystem, das zur Verwaltung von Thread-Pools in den verschiedenen Subsystemen im Server verwendet wurde.

Das threads-Subsystem steht in JBoss EAP 7 nicht mehr zur Verfügung. Stattdessen ist jedes Subsystem für die Verwaltung seines eigenen Thread-Pools verantwortlich.

For information about how to configure thread pools for the infinispan subsystem, see Configure Infinispan Thread Pools in the JBoss EAP Configuration Guide.

For information about how to configure thread pools for the jgroups subsystem, see Configure JGroups Thread Pools in the JBoss EAP Configuration Guide.

In JBoss EAP 6, you configured thread pools for connectors and listeners for the web subsystem by referencing an executor that was defined in the threads subsystem. In JBoss EAP 7, you now configure thread pools for the undertow subsystem by referencing a worker that is defined in the io subsystem. For more information, see Configuring the IO Subsystem in the JBoss EAP Configuration Guide.

For information about about changes to thread pool configuration in the remoting subsystem, see Migrate the Remoting Subsystem Configuration in this guide, and Configuring the Endpoint in the JBoss EAP Configuration Guide.

In JBoss EAP 6 wurde der Thread-Pool für das remoting-Subsystem konfiguriert, indem verschiedene worker-*-Parameter festgelegt wurden. In JBoss EAP 7 wird der Worker-Thread-Pool nicht mehr im remoting-Subsystem konfiguriert, und falls Sie versuchen, die vorhandene Konfiguration zu ändern, erhalten Sie die folgende Meldung.

WFLYRMT0022: Worker-Konfiguration wird nicht mehr verwendet, bitte verwenden Sie Endpunkt-Worker-Konfiguration

In JBoss EAP 7 wurde der Worker-Thread-Pool ersetzt durch eine Endpunktkonfiguration, die einen worker referenziert, der im io-Subsystem definiert ist.

For information about how to configure the endpoint, see Configuring the Endpoint in the JBoss EAP Configuration Guide.

Um WebSockets in JBoss EAP 6 zu verwenden, mussten Sie das nicht blockierende Java NIO2 Connector-Protokoll für den http-Connector im web-Subsystem der JBoss EAP Serverkonfigurationsdatei aktivieren mithilfe eines Befehls ähnlich dem folgenden.

/subsystem=web/connector=http/:write-attribute(name=protocol,value=org.apache.coyote.http11.Http11NioProtocol)

Um WebSockets in einer Applikation zu verwenden, mussten Sie zudem ein <enable-websockets>-Element in der WEB-INF/jboss-web.xml-Datei der Applikation erstellen und dieses auf true setzen.

In JBoss EAP 7 müssen Sie den Server nicht mehr für die standardmäßige WebSocket-Unterstützung konfigurieren oder die Applikation zu deren Verwendung einstellen. WebSockets sind eine Voraussetzung der Java EE 7 Spezifikation und die erforderlichen Protokolle werden standardmäßig konfiguriert. Komplexere WebSocket-Konfigurationen erfolgen im servlet-container des undertow-Subsystems in der JBoss EAP Serverkonfigurationsdatei. Mithilfe des folgenden Befehls können Sie die verfügbaren Einstellungen anzeigen.

/subsystem=undertow/servlet-container=default/setting=websockets:read-resource(recursive=true)
{
   "outcome" => "success",
   "result" => {
       "buffer-pool" => "default",
       "dispatch-to-worker" => true,
       "worker" => "default"
   }
}

Codebeispiele für WebSockets finden Sie auch in den Quickstarts, die in JBoss EAP integriert sind.

The infinispan subsystem still provides distributed caching support for HA services in the form of Infinispan caches in JBoss EAP 7; however the caching and distribution of authentication information is handled differently than in previous releases.

Wenn in JBoss EAP 6 dem Single Sign-On (SSO) kein Infinispan-Cache zur Verfügung gestellt wurde, dann wurde der Cache nicht verteilt.

In JBoss EAP 7 ist SSO automatisch verteilt, wenn Sie das HA-Profil wählen. Wenn Sie das HA-Profil ausführen, hat jeder Host seinen eigenen Infinispan-Cache, der auf dem Standard-Cache des Web-Cache-Containers basiert. Dieser Cache speichert die relevanten Sitzungs- und SSO-Cookie-Daten für den Host. JBoss EAP handhabt die Übertragung der jeweiligen Cache-Daten auf alle Hosts. In JBoss EAP 7 gibt es keine Möglichkeit, einen Infinispan-Cache speziell zu SSO zuzuweisen.

In JBoss EAP 7 wird SSO im undertow-Subsystem der Serverkonfigurationsdatei konfiguriert.

Bei der Migration zu JBoss EAP 7 sind für SSO keine Änderungen am Applikationscode erforderlich.

For information about Java Security Manager server configuration changes, see Considerations Moving from Previous Versions in How To Configure Server Security for JBoss EAP.

Einige der Konfigurationsparameter für den Transaktionsmanager, die im transactions-Subsystem in JBoss EAP 6 verfügbar waren, haben sich in JBoss EAP 7 geändert.

Removed Transactions Subsystem Attributes

Die folgende Tabelle führt die JBoss EAP 6 Parameter auf, die aus dem transactions-Subsystem in JBoss EAP 7 entfernt wurden, sowie deren jeweilige Ersatzparameter.

Veraltete Parameter des Transaktionssubsystems

The following attributes that were available in the transactions subsystem in JBoss EAP 6 are deprecated in JBoss EAP 7. The deprecated attributes might be removed in a future release of the product. The following table lists the equivalent replacement attributes.

Die Konfiguration für statische Proxy-Listen in mod_cluster hat sich in JBoss EAP 7 geändert.

In JBoss EAP 6 haben Sie den proxy-list-Parameter konfiguriert, bei dem es sich um eine kommagetrennte Liste der httpd-Proxy-Adressen handelte, die im Format hostname:port angegeben wurden.

Der proxy-list-Parameter ist in JBoss EAP 7 veraltet. Er wurde ersetzt durch den proxies-Parameter, bei dem es sich um eine Liste von ausgehenden Socket-Binding-Namen handelt.

This change impacts how you define a static proxy list, for example, when disabling advertising for mod_cluster. For information about how to disable advertising for mod_cluster, see Disable Advertising for mod_cluster in the JBoss EAP Configuration Guide.

For more information about mod_cluster attributes, see ModCluster Subsystem Attributes in the JBoss EAP Configuration Guide.

JBossWS 5 bringt neue Funktionalitäten und Performance-Verbesserungen in JBoss EAP 7 Webservices ein, hauptsächlich aufgrund von Upgrades der Komponenten Apache CXF, Apache WSS4J und Apache Santuario.

<?xml version="1.0" encoding="UTF-8"?>
<jaxws-config xmlns="urn:jboss:jbossws-jaxws-config:4.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:javaee="http://java.sun.com/xml/ns/javaee"
  xsi:schemaLocation="urn:jboss:jbossws-jaxws-config:4.0 schema/jbossws-jaxws-config_4_0.xsd">
  <endpoint-config>
    <config-name>org.jboss.test.ws.jaxws.cxf.interceptors.EndpointImpl</config-name>
    <property>
      <property-name>cxf.interceptors.in</property-name>
      <property-value>org.jboss.test.ws.jaxws.cxf.interceptors.EndpointInterceptor,org.jboss.test.ws.jaxws.cxf.interceptors.FooInterceptor</property-value>
    </property>
    <property>
      <property-name>cxf.interceptors.out</property-name>
      <property-value>org.jboss.test.ws.jaxws.cxf.interceptors.EndpointCounterInterceptor</property-value>
    </property>
  </endpoint-config>
</jaxws-config>

<?xml version="1.0" encoding="UTF-8"?>
<jaxws-config xmlns="urn:jboss:jbossws-jaxws-config:4.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:javaee="http://java.sun.com/xml/ns/javaee"
  xsi:schemaLocation="urn:jboss:jbossws-jaxws-config:4.0 schema/jbossws-jaxws-config_4_0.xsd">
  <endpoint-config>
    <config-name>Custom FI Config</config-name>
    <property>
      <property-name>cxf.features</property-name>
      <property-value>org.apache.cxf.feature.FastInfosetFeature</property-value>
    </property>
  </endpoint-config>
</jaxws-config>

import org.apache.cxf.frontend.ClientProxy;
import org.apache.cxf.transport.http.HTTPConduit;
import org.apache.cxf.transports.http.configuration.HTTPClientPolicy;

// Set chunking threshold before using a JAX-WS port client
...
HTTPConduit conduit = (HTTPConduit)ClientProxy.getClient(port).getConduit();
HTTPClientPolicy client = conduit.getClient();

client.setChunkingThreshold(8192);
...

In JBoss EAP 7 wurde der Standard-Connector geändert von remote auf http-remoting und der standardmäßige Remote-Verbindungsport wurde geändert von 4447 auf 8080. Die JNDI-Provider-URL für die Standardkonfiguration wurde geändert von remote://localhost:4447 auf http-remoting://localhost:8080.

If you use the JBoss EAP 7 migrate operation to update your configuration, you do not need to modify the remote connector, remote port, or JNDI provider URLs because the migration operation preserves the JBoss EAP 6 remoting connector and 4447 port configuration settings in the subsystem configuration. For more information about the migrate operation, see Management CLI Migration Operation.

Falls Sie die migrate-Operation nicht verwenden und stattdessen die neue JBoss EAP 7 Standardkonfiguration ausführen, müssen Sie den Remote-Connector, Remote-Port und die JNDI-Provider-URL auf die oben genannten neuen Einstellungen ändern.

Die vorherige Release von JBoss EAP umfasste RESTEasy 2, was eine Implementierung von JAX-RS 1.x war. JBoss EAP 7 enthält RESTEasy 3, was eine Implementierung von JAX-RS 2.0 ist, wie von der Spezifikation JSR 339: JAX-RS 2.0: The Java API for RESTful Web Services definiert. Weitere Informationen über die Java API für RESTful Webservices finden Sie unter JAX-RS 2.0 API Specification.

Die in JBoss EAP enthaltene Version von Jackson hat sich geändert. Die vorherige Version von JBoss EAP enthielt Jackson 1.9.9, JBoss EAP 7 enthält jetzt Jackson 2.6.3 oder höher.

This section describes how these changes might impact applications that use RESTEasy or JAX-RS.

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
  <deployment>
    <exclusions>
      <module name="org.jboss.resteasy.resteasy-jackson2-provider"/>
      <module name="org.jboss.resteasy.resteasy-jackson-provider"/>
    </exclusions>
    <dependencies>
      <module name="org.jboss.resteasy.resteasy-jettison-provider" services="import"/>
    </dependencies>
  </deployment>
</jboss-deployment-structure>

JBoss EAP 7 includes support for CDI 1.2. As a result, applications written using CDI 1.0 might see some changes in behavior when migrated to JBoss EAP 7. This section summarizes only a few of those changes.

Weitere Informationen über Weld und CDI 1.2 finden Sie in den folgenden Quellen:

Bean-Archive

Bean-Klassen mit aktivierten Beans müssen in Bean-Archiven deployt sein, um zu gewährleisten, dass sie vom CDI überprüft werden und die Bean-Klassen somit gefunden und verarbeitet werden.

In CDI 1.0 war ein Archiv definiert als ein explizites Bean-Archiv, wenn es eine beans.xml-Datei im Verzeichnis META-INF/ eines Applikations-Clients, EJB oder Bibliothek-JAR enthielt, oder wenn es eine beans.xml-Datei im Verzeichnis WEB-INF/ für ein WAR enthielt.

CDI 1.1 führte implizite Bean-Archive ein, bei denen es sich um Archive handelt, die eine oder mehrere Bean-Klassen mit einer Annotation zur Bean-Definition haben, oder eine oder mehrere Session-Beans. Implizite Bean-Archive werden von CDI geprüft, und während der Typerkennung werden nur Klassen mit Annotationen zur Bean-Definition gefunden. Weitere Informationen finden Sie unter Type and Bean Discovery in Contexts and Dependency Injection for the Java EE platform.

Ein Bean-Archiv hat den Bean-Discovery-Modus all, annotated oder none. Ein Bean-Archiv, das eine beans.xml-Datei ohne Version enthält, hat standardmäßig den Bean-Discovery-Modus all. Ein Bean-Archiv, das eine beans.xml-Datei der Version 1.1 oder höher enthält, muss den Parameter bean-discovery-mode angeben. Der Standardwert für diesen Parameter lautet annotated.

In den folgenden Fällen ist ein Archiv ist kein Bean-Archiv:

In den folgenden Fällen ist ein Archiv ein explizites Bean-Archiv:

In den folgenden Fällen ist ein Archiv ein implizites Bean-Archiv:

CDI 1.2 beschränkt Annotationen zur Bean-Definition auf die folgenden:

Weitere Informationen über Bean-Archive finden Sie unter Bean Archives in Contexts and Dependency Injection for the Java EE platform.

Klärung der Konversationsauflösung

Der Lebenszyklus des Konversationskontexts wurde geändert, um Konflikte mit der Servlet-Spezifikation (wie in CDI Specification Issue CDI-411 beschrieben) zu vermeiden. Der Konversations-Scope ist während jeglicher Servlet-Anfragen aktiv und sollte andere Servlets oder Servlet-Filter nicht daran hindern, den Anfrage-Body oder die Zeichenkodierung einzustellen.

Observer-Auflösung

Die Ereignisauflösung wurde in CDI 1.2 teilweise umgeschrieben. In CDI 1.0 wurde ein Ereignis an eine Observer-Methode übergeben, wenn die Observer-Methode alle Ereignis-Qualifier besitzt. In CDI 1.2 wird ein Ereignis an eine Observer-Methode übergeben, wenn die Observer-Methode keine Ereignis-Qualifier oder nur eine Untermenge der Ereignis-Qualifier besitzt.

Die Einführung des modularen Klassenladesystems und JBoss Modules in der vorherigen Release von JBoss EAP ermöglichte eine genaue Steuerung der Klassen, die Applikationen zur Verfügung stehen. Dieses Feature ermöglichte Ihnen die Konfiguration expliziter Modulabhängigkeiten mithilfe der MANIFEST.MF-Datei oder der jboss-deployment-structure.xml Deployment-Deskriptordatei der Applikation.

Falls Sie explizite Modulabhängigkeiten in Ihrer Applikation definiert haben, sollten Sie sich der folgenden Änderungen in JBoss EAP 7 bewusst sein.

Überprüfen der Abhängigkeiten auf Verfügbarkeit

Die Module, die in JBoss EAP enthalten sind, haben sich geändert. Wenn Sie Ihre Applikation zu JBoss EAP 7 migrieren, prüfen Sie Ihre MANIFEST.MF- und jboss-deployment-structure.xml-Dateieinträge, um sicherzustellen, dass diese keine Module referenzieren, die aus dieser Produktrelease entfernt wurden.

Abhängigkeiten, die Annotations-Prüfung erfordern

Falls Ihre Abhängigkeiten Annotationen enthielten, die während der Annotationsprüfung verarbeitet werden mussten (z.B. beim Deklarieren von EJB-Interzeptoren), dann mussten Sie in der vorherigen Version von JBoss EAP einen Jandex-Index in einer neuen JAR-Datei generieren und einbeziehen und anschließend ein Flag in der MANIFEST.MF oder jboss-deployment-structure.xml Deployment-Deskriptordatei setzen.

JBoss EAP 7 generiert nun automatisch zur Laufzeit Annotationsindizes für statische Module, sodass Sie diese nicht mehr manuell erstellen müssen. Allerdings müssen Sie noch das annotations-Flag zur MANIFEST.MF-Datei oder zur jboss-deployment-structure.xml-Deployment-Deskriptordatei der Applikation hinzufügen, wie unten veranschaulicht.

Dependencies: com.company.my-ejb annotations, com.company.other

<jboss-deployment-structure>
  <deployment>
    <dependencies>
      <module name="com.company.my-ejb" annotations="true"/>
      <module name="com.company.other"/>
    </dependencies>
  </deployment>
</jboss-deployment-structure>

Die in JBoss EAP 7 integrierte Version von Hibernate Search hat sich geändert. Die vorherige Release von JBoss EAP enthielt Hibernate Search 4.6.x. JBoss EAP 7 enthält nun Hibernate Search 5.5.x.

Hibernate Search 5.5 is built upon Apache Lucene 5.3.1. If you use any native Lucene APIs, be sure to align with this version. The Hibernate Search 5.5 API wraps and hides the complexity of many of the Lucene API changes made between version 3 and version 5, however, some classes are now deprecated, renamed, or repackaged. This section describes how these changes might impact your application code.

Änderungen des Hibernate Search Mappings

Indexierung von ID-Feldern in eingebetteten Objekten

Wenn eine @IndexedEmbedded-Annotation verwendet wird, um Felder von einem zugehörigen Objekt einzubinden, dann ist die id des zugehörigen Objekts nicht mehr enthalten. Sie können die Einbeziehung der id aktivieren, indem Sie den Parameter includeEmbeddedObjectId der Annotation @IndexedEmbedded verwenden.

@IndexedEmbedded(includeEmbeddedObjectId=true)

Änderungen der Formatierung von Zahlen- und Datumsindexierung

Zahlen und Daten werden nun standardmäßig als numerische Felder indiziert. Eigenschaften des Typs int, long, float, double und deren jeweiligen Wrapper-Klassen werden nicht mehr als Zeichenketten (Strings) indiziert. Stattdessen werden sie nun unter Verwendung von Lucenes numerischer Kodierung indiziert. Die id-Felder stellen eine Ausnahme von dieser Regel dar. Selbst wenn es sich bei ihnen um einen numerischen Typ handelt, werden sie standardmäßig dennoch als Zeichenketten indiziert. Die Verwendung von @NumericField ist nun obsolet, es sei denn, Sie möchten eine angepasste Länge für die numerische Kodierung festlegen. Sie können das alte stringbasierte Indexformat behalten, indem Sie explizit eine Feld-Bridge zur String-Kodierung angeben. Für Integer ist dies die org.hibernate.search.bridge.builtin.IntegerBridge. Im Paket org.hibernate.search.bridge.builtin finden Sie andere öffentlich verfügbare Bridges.

Date und Calendar werden nicht mehr als Zeichenketten indiziert. Stattdessen werden sie nun als Long-Werte kodiert, die für die Anzahl der Millisekunden seit dem 1. Januar 1970, 00:00:00 GMT stehen. Sie können das Indexierungsformat ändern, indem Sie die neue EncodingType-Aufzählung verwenden. Zum Beispiel:

@DateBridge(encoding=EncodingType.STRING)
@CalendarBridge(encoding=EncodingType.STRING)

Die geänderte Kodierung für Zahlen und Daten ist wichtig und kann weitreichende Auswirkungen auf das Applikationsverhalten haben. Falls Sie eine Anfrage haben, die auf ein Feld abzielt, das bislang stringkodiert war, jetzt jedoch numerisch kodiert wird, müssen Sie die Anfrage entsprechend umschreiben. Numerische Felder müssen mit einer NumericRangeQuery durchsucht werden. Sie müssen auch sicherstellen, dass alle Felder, auf die die Facettierung abzielt, nun stringkodiert sind. Falls Sie die Search Query DSL verwenden, sollte die korrekte Anfrage automatisch für Sie erstellt werden.

Sonstige Änderungen hinsichtlich Hibernate Search

Unbenannte und neu paketierte Klassen in Hibernate Search

Nachfolgend sehen Sie eine Liste mit Hibernate Search Klassen, die neu paketiert oder umbenannt wurden.

Unbenannte und neu paketierte Klassen in Lucene

Anfragen-Parser wurden in ein neues Modul verlegt, weshalb sich das Paket geändert hat von org.apache.lucene.queryParser.QueryParser auf org.apache.lucene.queryparser.classic.QueryParser.

Viele der Lucene-Analyzers wurden refaktoriert, weshalb sich deren Pakete geändert haben. Siehe Apache Lucene Documentation für Einzelheiten zu den neuen Paketen.

Einige Apache Solr-Dienstklassen wie beispielsweise TokenizerFactory oder TokenFilterFactory wurden in Apache Lucene verlegt. Falls Ihre Applikation diese Dienste oder angepasste Analyzer verwendet, müssen Sie die neuen Paketnamen in Apache Lucene suchen.

Siehe Apache Lucene Migration Guide für weitere Informationen.

Veraltete APIs in Hibernate Search

Eine vollständige Liste der veralteten Schnittstellen, Klassen, Aufzählungstypen, Methoden, Konstruktoren und Aufzählungskonstanten finden Sie unter Hibernate Search Deprecated API.

Veraltete Schnittstellen in Hibernate Search

Veraltete Klassen in Hibernate Search

Veraltete Aufzählungen in Hibernate Search

Veraltete Annotationen in Hibernate Search

Veraltete Methoden in Hibernate Search

Veraltete Konstruktoren in Hibernate Search

Änderungen mit Auswirkungen auf erweiterte Integratoren

Dieser Abschnitt beschreibt Änderungen, die nicht Teil der öffentlichen API sind. Sie sollten keinerlei Auswirkungen auf normale Entwickler haben, da auf diese Artefakte nur von Integratoren zugegriffen wird, die das Hibernate Search Framework erweitern.

Unterstützung für EJB-Entity-Beans ist optional in Java EE 7, und sie werden in JBoss EAP 7 nicht unterstützt. Das bedeutet, dass Container-Managed Persistence (CMP) und Bean-Managed Persistence (BMP) Entity-Beans für die Migration zu JBoss EAP 7 umgeschrieben werden müssen, um Java-Persistence-API (JPA) Entitys zu verwenden.

In früheren Releases von JBoss EAP wurden Entity-Beans im Applikations-Quellcode erstellt, indem die Klasse javax.ejb.EntityBean erweitert und die erforderlichen Methoden implementiert wurden. Anschließend wurden Sie in der Datei ejb-jar.xml konfiguriert. Eine CMP-Entity-Bean wurde spezifiziert mithilfe eines <entity>-Elements, das ein <persistence-type>-Unterelement mit dem Wert Container enthielt. Eine BMP-Entity-Bean wurde spezifiziert mithilfe eines <entity>-Elements, das ein <persistence-type>-Unterelement mit dem Wert Bean enthielt.

In JBoss EAP 7 müssen Sie jegliche CMP- und BMP-Entity-Beans in Ihrem Code durch Java Persistence API (JPA) Entitys ersetzen. JPA-Entitys werden erstellt mithilfe von javax.persistence.*-Klassen und werden in der Datei persistence.xml definiert.

Nachfolgend sehen Sie ein Beispiel für eine JPA-Entity-Klasse

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;
import javax.persistence.Table;

@Entity
// User is a keyword in some SQL dialects!
@Table(name = "MyUsers")
public class MyUser {
    @Id
    @GeneratedValue
    private Long id;

    @Column(unique = true)
    private String username;
    private String firstName;
    private String lastName;

    public Long getId() {
        return id;
    }
    public String getUsername() {
        return username;
    }
    public void setUsername(String username) {
        this.username = username;
    }
    public String getFirstName() {
        return firstName;
    }
    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }
    public String getLastName() {
        return lastName;
    }
    public void setLastName(String lastName) {
        this.lastName = lastName;
    }

Nachfolgend sehen Sie ein Beispiel für eine persistence.xml-Datei.

<persistence version="2.1"
      xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="
        http://xmlns.jcp.org/xml/ns/persistence
        http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd">
  <persistence-unit name="my-unique-persistence-unit-name">
    <properties>
      // properties...
    </properties>
  </persistence-unit>
</persistence>

Beispiele für JPA-Entitys finden Sie in den Quickstarts bmt, cmt und hibernate5, die in JBoss EAP 7 enthalten sind.

Eine neue Persistenzeigenschaft namens jboss.as.jpa.deferdetach wurde hinzugefügt, um Kompatibilität mit dem Persistenzverhalten früherer Releases von JBoss EAP zu bieten.

Die Eigenschaft jboss.as.jpa.deferdetach steuert, ob der transaktionsweite Persistenzkontext, der in einem nicht-JTA-Transaktions-Thread verwendet wird, geladene Entitys nach jedem EntityManager-Aufruf löst, oder ob er wartet, bis der Persistenzkontext geschlossen wird, beispielsweise wenn der Session-Bean-Aufruf beendet ist. Der Standardwert der Eigenschaft ist false, was bedeutet, dass Entitys nach jedem EntityManager-Aufruf gelöst oder gelöscht werden. Dies ist das korrekte Standardverhalten gemäß JPA-Spezifikation. Ist der Eigenschaftswert auf true gesetzt, dann werden die Entitys nicht gelöst, ehe der Persistenzkontext geschlossen wurde.

In JBoss EAP 5 verhielt sich die Persistenz, als sei die Eigenschaft jboss.as.jpa.deferdetach auf true eingestellt. Um dasselbe Verhalten zu erreichen, wenn Sie Ihre Applikation von JBoss EAP 5 zu JBoss EAP 7 migrieren, müssen Sie den Eigenschaftswert jboss.as.jpa.deferdetach auf true einstellen in Ihrer persistence.xml, wie im folgenden Beispiel veranschaulicht.

<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0">
    <persistence-unit name="EAP5_COMPAT_PU">
    <jta-data-source>java:jboss/datasources/ExampleDS</jta-data-source>
    <properties>
         <property name="jboss.as.jpa.deferdetach" value="true" />
    </properties>
  </persistence-unit>
</persistence>

In JBoss EAP 6 verhielt sich die Persistenz, als sei die Eigenschaft jboss.as.jpa.deferdetach auf false eingestellt. Dies ist dasselbe Verhalten wie in JBoss EAP 7, also sind keinerlei Änderungen nötig, wenn Sie Ihre Applikation migrieren.

Der standardmäßige Remote-Connector und Port wurde in JBoss EAP 7 geändert. Details über diese Änderung finden Sie unter Änderungen des Remote-URL-Connectors und -Ports.

Falls Sie die migrate-Operation zur Migration der Serverkonfiguration verwenden, werden die alten Einstellungen bewahrt, sodass die unten beschriebenen Änderungen nicht notwendig sind. Wenn Sie allerdings die neue JBoss EAP 7 Standardkonfiguration ausführen, müssen Sie die folgenden Änderungen vornehmen.

remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=localhost
remote.connection.default.port=4447
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=localhost
remote.connection.default.port=8080
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

java.naming.factory.initial=org.jboss.naming.remote.client.InitialContextFactory
java.naming.provider.url=remote://localhost:4447

java.naming.factory.initial=org.jboss.naming.remote.client.InitialContextFactory
java.naming.provider.url=http-remoting://localhost:8080

Die Java EE Spezifikation für Applikations-Deployment (JSR-88) wurde dazu entworfen, um einen Vertrag zu definieren, der es Tools verschiedener Anbieter ermöglichen sollte, Applikationen auf jeder beliebigen Java EE Plattform zu konfigurieren und bereitzustellen. Der Vertrag erforderte von den Anbietern der Java EE Produkte, DeploymentManager und andere javax.enterprise.deploy.spi-Schnittstellen bereitzustellen für den Zugriff durch die Tool-Anbieter. Im Falle von JBoss EAP 6 besteht ein Deployment-Plan aus einem XML-Deskriptor namens deployment-plan.xml, der in einem ZIP- oder JAR-Archiv gebündelt ist.

Diese Spezifikation fand nur wenig Anwendung, da die meisten Applikationsserver-Produkte ihre eigenen, funktionsreicheren Deployment-Lösungen bereitstellten. Aus diesem Grund wurde die Unterstützung für JSR-88 in Java EE 7 aufgegeben und infolgedessen auch in JBoss EAP 7.

If you used JSR-88 to deploy your application, you must now use another method to deploy the application. The JBoss EAP management CLI deploy command provides a standard way to deploy archives to standalone servers or to server groups in a managed domain. For more information about the management CLI, see the Management CLI Guide.

Sie müssen angepasste Valves und jegliche Valves, die in der XML-Datei jboss-web.xml definiert sind, manuell migrieren. Dazu gehören Valves, die erstellt wurden durch Erweitern der org.apache.catalina.valves.ValveBase-Klasse und Konfigurieren des <valve>-Elements in der jboss-web.xml-Deskriptordatei.

Migrieren der in Deployments konfigurierten Valves

In JBoss EAP 6 konnten Sie auf Applikationsebene angepasste Valves definieren, indem Sie die diese in der jboss-web.xml-Webapplikations-Deskriptordatei konfigurierten. In JBoss EAP 7 ist dies ebenfalls möglich mithilfe von Undertow-Handlern.

Nachfolgend sehen Sie ein Beispiel für eine Valve, die in der jboss-web.xml-Datei in JBoss EAP 6 konfiguriert ist.

<jboss-web>
    <valve>
        <class-name>org.jboss.examples.MyValve</class-name>
​        <param>
    ​        <param-name>myParam</param-name>
​            <param-value>foobar</param-value>
    ​    </param>
    </valve>
</jboss-web>

For more information about how to create and configure custom handlers in JBoss EAP, see Creating Custom Handlers in the JBoss EAP Development Guide.

Migrieren von angepassten Authentifikations-Valves

Weitere Informationen über die Migration von Authentifikations-Valves finden Sie unter Sicherheitsrelevante Applikationsänderungen

Aufgrund des Wechsels von JBoss Web nach Undertow sind Änderungen an der Sicherheitskonfiguration in JBoss EAP 7 erforderlich.

Falls Ihre Applikation JBoss-Protokollierung verwendet, beachten Sie, dass die Annotationen im org.jboss.logging-Paket in JBoss EAP 7 nunmehr als veraltet gelten. Sie wurden in das org.jboss.logging.annotations-Paket verlegt, weshalb Sie Ihren Quellcode zum Import des neuen Pakets ändern müssen.

Die Annotationen wurden zudem in eine separate Maven groupId:artifactId:version (GAV) ID verlegt, sodass Sie eine neue Projektabhängigkeit für org.jboss.logging:jboss-logging-annotations in der pom.xml-Datei Ihres Projekts hinzufügen müssen.

Die folgende Tabelle führt die veralteten Annotationsklassen und entsprechenden Ersatz auf.

Beendete Unterstützung für JSF 1.2

JBoss EAP 6 ermöglichte es Ihnen, weiterhin JSF 1.2 in Ihrem Applikations-Deployment zu verwenden, indem Sie eine jboss-deployment-structure.xml-Datei erstellten.

JBoss EAP 7 enthält JSF 2.2 und unterstützt die JSF 1.2 API nicht mehr. Falls Ihre Applikation JSF 1.2 verwendet, müssen Sie diese auf JSF 2.2 umschreiben.

Kompatibilitätsprobleme zwischen JSF 2.1 und JSF 2.2

Die JSF 2.1 und JSF 2.2 APIs sind nicht vollständig kompatibel. Der Wert der Konstante FACELET_CONTEXT_KEY hat sich geändert von com.sun.faces.facelets.FACELET_CONTEXT auf javax.faces.FACELET_CONTEXT in der neuen Releases. Der Compiler führt für diesen Wert eine Inline-Ersetzung durch – Code, der für eine Release kompiliert wurde, kann nicht für eine anderen Release funktionieren.

Applikationen, die ähnlichen Code wie im folgenden Beispiel enthalten und mit der JSF 2.1 API kompiliert wurden, jedoch in JBoss EAP 7 (was die JSF 2.2 API verwendet) ausgeführt werden, verursachen eine NullPointerException. Um dieses Problem zu beheben, müssen Sie die Applikation mit der JSF 2.2 API neu kompilieren.

Object obj = FacesContext.getCurrentInstance().getAttributes().get(FaceletContext.FACELET_CONTEXT_KEY);

Siehe JAVASERVERFACES_SPEC_PUBLIC-1257 für weitere Informationen.

In JBoss EAP 7 hat sich das Verhalten des Klassenladens geändert in Fällen, in denen mehrere Module dieselben Klassen oder Pakete enthalten.

Angenommen es gibt zwei Module, MODULE_A und MODULE_B, die voneinander abhängen und zum Teil die gleichen Pakete enthalten. In JBoss EAP 6 hatten die Klassen oder Pakete, die von den Abhängigkeiten geladen wurden, Vorrang vor jenen, die im resource-root der module.xml-Datei angegeben wurden. Das bedeutet, dass MODULE_A die Pakete für MODULE_B sah und MODULE_B die Pakete für MODULE_A sah. Dieses Verhalten war verwirrend und ein Grund für mögliche Konflikte, weshalb es in JBoss EAP 7 geändert wurde. Jetzt haben die Klassen oder Pakete, die im resource-root in der module.xml-Datei angegeben werden, Vorrang vor jenen, die von der Abhängigkeit spezifiziert werden. Das bedeutet, dass MODULE_A die Pakete für MODULE_A sieht und MODULE_B die Pakete für MODULE_B sieht. Dies vermeidet Konflikte und sorgt für ein angemesseneres Verhalten.

If you have defined custom modules that include resource-root libraries or packages that contain classes that are duplicated in their module dependencies, you might see ClassCastException, LinkageError, class loading errors, or other changes in behavior when you migrate to JBoss EAP 7. To resolve these issues, you must configure your module.xml file to ensure only one version of a class is used. This can be accomplished by using either of the following approaches.

Falls Sie es vorziehen, Ihr derzeitiges Verhalten beizubehalten, müssen Sie die Pakete der Abhängigkeiten von der abhängigen resource-root in der module.xml-Datei mithilfe des filter-Elements filtern. Dies ermöglicht es Ihnen, das derzeitige Verhalten beizubehalten, ohne manche Schleifen, die unter JBoss EAP 6 auftreten würden. Nachfolgend sehen Sie ein Beispiel für ein root-resource, das Klassen in einem angegebenen Paket filtert.

<resource-root path="mycompany.jar">
  <filter>
    <exclude path="com/mycompany/duplicateclassespath"/>
  </filter>
</resource-root>

For more information about modules and class loading, see Class Loading and Modules in the JBoss EAP Development Guide.

JBoss EAP 7 Natives werden in dieser Release anders geliefert als früher. Einige werden jetzt mit dem neuen Produkt Red Hat JBoss Core Services geliefert, eine Auswahl zusätzlicher Software, die in vielen Red Hat JBoss Middleware-Produkten gebräuchlich sind. Das neue Produkt ermöglicht Ihnen eine schnellere und einheitlichere Verteilung von Updates. Das Produkt JBoss Core Services steht an einer anderen Stelle im Red Hat Kundenportal als Download zur Verfügung.

A number of changes have been made to the Amazon Machine Images (AMI) in JBoss EAP 7. This section briefly summarizes some of those changes.

For details on deploying JBoss EAP 7 on Amazon EC2, see Deploying Red Hat JBoss Enterprise Application Platform on Amazon EC2.

The add-user script behavior has changed in JBoss EAP 7 due to a change in password policy. JBoss EAP 6 had a strict password policy. As a result, the add-user script rejected weak passwords that did not satisfy the minimum requirements. In JBoss EAP 7, weak passwords are accepted and a warning is issued. For more information, see Setting Add-User Utility Password Restrictions in the JBoss EAP Configuration Guide.

Als JBoss EAP 6.0 GA zuerst veröffentlicht wurde, war JBoss OSGi – eine Implementierung der OSGi-Spezifikation – als Technologievorschau enthalten. Seit JBoss EAP 6.1.0 hat JBoss OSGi den Status einer Technologievorschau verloren und wird nicht mehr unterstützt.

In JBoss EAP 6.1.0 wurden die configadmin- und osgi-Erweiterungsmodule und Subsystemkonfigurationen für einen Standalone-Server in die separate Konfigurationsdatei EAP_HOME/standalone/configuration/standalone-osgi.xml verlegt. Da Sie diese nicht unterstützte Konfigurationsdatei nicht migrieren sollten, dürfte die Entfernung der JBoss OSGi Unterstützung keine Auswirkungen auf die Migration einer Standalone-Serverkonfiguration haben. Falls Sie andere Standalone-Konfigurationsdateien zum Konfigurieren von osgi oder configadmin verändert haben, müssen Sie diese Konfigurationen entfernen.

Für eine verwaltete Domain wurde die osgi-Erweiterung und Subsystemkonfiguration aus der Datei EAP_HOME/domain/configuration/domain.xml in der JBoss EAP 6.1.0 Release entfernt. Allerdings verbleibt das configadmin-Erweiterungsmodul und die Subsystemkonfiguration in der Datei EAP_HOME/domain/configuration/domain.xml. Diese Konfiguration wird in JBoss EAP 7 nicht mehr unterstützt und muss entfernt werden.

Dieses Handbuch konzentriert sich auf die notwendigen Änderungen, um JBoss EAP 6 Applikationen erfolgreich auf JBoss EAP 7 bereitzustellen und auszuführen. Falls Sie dagegen beabsichtigen, Ihre Applikationen direkt von JBoss EAP 5 zu JBoss EAP 7 zu migrieren, gibt es eine Reihe von Informationsquellen, die Ihnen bei der Planung und Durchführung der Migration helfen. Wir empfehlen Ihnen die folgende Herangehensweise.

Bevor Sie Ihre Migration planen, sollten Sie sich über die Änderungen im Klaren sein, die an JBoss EAP 6 und JBoss EAP 7 vorgenommen wurden.

Das JBoss EAP 6 Migrationshandbuch behandelt Änderungen, die zwischen JBoss EAP 5 und JBoss EAP 6 vorgenommen wurden. Nachfolgend sehen Sie eine verkürzte Liste der bedeutsamsten Änderungen in JBoss EAP 6.

Siehe Was ist neu und anders bei der JBoss EAP 6? im JBoss EAP 6 Migrationshandbuch für eine detaillierte Liste der Änderungen an dieser Release.

JBoss EAP 7 basiert auf derselben modularen Struktur wie JBoss EAP 6 und verwendet dieselben Grundlagen für Domain-Management, Deployment-Konfiguration, Verzeichnisstruktur und Skripte. Es verwendet auch dieselben standardisierten JNDI-Namespaces. Allerdings führt JBoss EAP 7 die folgenden Änderungen ein.

Eine vollständige Liste der Änderungen finden Sie unter Was ist neu JBoss EAP 7?

Lesen Sie das gesamte Migrationshandbuch für jede Release, um über neue oder veraltete Features im Bilde zu sein und um die Serverkonfigurationen und Änderungen an Applikationen zu erfahren, die notwendig sind, um vorhandene Applikationen erfolgreich auf dieser Release auszuführen.

Da sich die zugrunde liegende Architektur von JBoss EAP 6 auf JBoss EAP 7 nicht geändert hat, haben viele der im JBoss EAP 6 Migrationshandbuch dokumentierten Änderungen noch Gültigkeit. Beispielsweise beziehen sich die in Von den meisten Applikationen benötigte Änderungen dokumentierten Änderungen auf die Neuerungen der zugrunde liegenden Architektur in JBoss EAP 6, und treffen somit ebenfalls auf diese Release zu. Die Änderungen am neuen, modularen Klassenladersystem sind beträchtlich und wirken sich auf die Paketierung und die Abhängigkeiten von fast allen JBoss EAP 5 Applikationen aus. Viele der unter Von Ihrer Applikationsarchitektur und -komponenten abhängige Änderungen aufgeführten Änderungen gelten ebenfalls weiterhin. Da JBoss EAP 7 jedoch den Webserver, ORB und Messaging-Provider ersetzt hat, die cmp, threads und jaxr Subsysteme entfernt sowie Unterstützung für EJB Entity Beans gestoppt hat, müssen Sie dieses Handbuch für jegliche Änderungen hinsichtlich dieser Komponenten zu Rate ziehen. Achten Sie besonders auf die Änderungen der Serverkonfiguration und die Änderungen bei Applikationsmigration, die in diesem Handbuch beschrieben werden, bevor Sie beginnen.

In der folgenden Tabelle finden Sie Informationen über das Migrieren von bestimmten Features oder Komponenten von JBoss EAP 5 zu JBoss EAP 7.