Kapitel 5. Änderungen bei Applikationsmigration

Die Java-API für XML-basierte RPC (JAX-RPC) gilt seit Java EE 6 als veraltet und ist in Java EE 7 optional. In JBoss EAP 7 ist sie nicht mehr verfügbar und wird nicht mehr unterstützt. Applikationen, die JAX-RPC verwenden, müssen zu JAX-WS migriert werden, dem aktuellen Java EE Standard Webservices-Framework.

Auf die Verwendung von JAX-RPC Webservices kann eine der folgenden Tatsachen hinweisen:

In früheren Releases von JBoss EAP konnten Sie die Integration von JBossWS und Apache CXF anpassen, indem Sie eine jbossws-cxf.xml-Konfigurationsdatei im Endpunkt-Deployment-Archiv implementierten. Ein Anwendungsfall hierfür war die Konfiguration von Interzeptor-Ketten für Webservice-Client- und -Server-Endpunkte auf dem Apache CXF-Bus. Diese Integration erfordert, dass Spring auf dem JBoss EAP Server deployt ist.

Die Spring-Integration wird in JBoss EAP 7 nicht länger unterstützt. Jegliche Applikationen, die eine jbossws-cxf.xml-Deskriptor-Konfigurationsdatei enthalten, müssen bearbeitet werden, um die angepasste Konfiguration in dieser Datei zu ersetzen. Zwar ist es weiterhin möglich, direkt auf die Apache CXF-API zuzugreifen, seien Sie sich jedoch bewusst, dass die Applikation nicht portierbar sein wird.

Wir empfehlen, wo möglich die angepassten Spring-Konfigurationen durch die neuen JBossWS Deskriptor-Konfigurationsoptionen zu ersetzen. Die JBossWS Deskriptor-basierte Herangehensweise bietet eine ähnliche Funktionalität, ohne Änderungen am Client-Endpunkt-Code zu erfordern. In einigen Fällen können Sie Spring durch Context Dependency Injection (CDI) ersetzen.

Apache CXF-Interzeptoren

Der JBossWS-Deskriptor bietet neue Konfigurationsoptionen, die es Ihnen ermöglichen, die Interzeptoren zu deklarieren, ohne den Client-Endpunkt-Code zu ändern. Stattdessen deklarieren Sie Interzeptoren innerhalb der vordefinierten Client- und Endpunkt-Konfigurationen, indem Sie eine Liste von Interzeptor-Klassennamen für die Eigenschaften cxf.interceptors.in und cxf.interceptors.out angeben.

Nachfolgend sehen Sie ein Beispiel für eine jaxws-endpoint-config.xml-Datei, die Interzeptoren mithilfe dieser Eigenschaften deklariert.

<?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>

Apache CXF-Features

Der JBossWS-Deskriptor ermöglicht es Ihnen, Features innerhalb von vordefinierten Client- und Endpunktkonfigurationen zu deklarieren, indem Sie eine Liste von Feature-Klassennamen für die cxf.features-Eigenschaft angeben.

Nachfolgend sehen Sie ein Beispiel für eine jaxws-endpoint-config.xml-Datei, die ein Feature mithilfe dieser Eigenschaft deklariert.

<?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>

Apache CXF HTTP-Transport

In Apache CXF wird die HTTP-Transportkonfiguration erreicht, indem die org.apache.cxf.transport.http.HTTPConduit-Optionen angegeben werden. Die JBossWS-Integration ermöglicht die befehlsgesteuerte Änderung von Conduits unter Verwendung der Apache CXF-API wie folgt.

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);
...

Sie können die Apache CXF HTTPConduit-Standardwerte auch steuern und außer Kraft setzen, indem Sie Systemeigenschaften einstellen.

Die JARs cxf-api und cxf-rt-core wurden in ein JAR namens cxf-core zusammengelegt. Infolgedessen enthält das org.apache.cxf-Modul in JBoss EAP nun das cxf-core-JAR und bietet mehr Klassen als in der vorherigen Release.

Falls Sie AES-Verschlüsselung mit Galois/Counter-Modus (GCM) für symmetrische Verschlüsselung in XML/WS-Security verwenden möchten, müssen Sie den BouncyCastle-Sicherheitsprovider nutzen.

JBoss EAP 7 enthält das org.bouncycastle-Modul, und JBossWS ist nun dazu in der Lage, mithilfe seines Klassenladers den BouncyCastle-Sicherheitsprovider zu erhalten und zu verwenden. Es ist daher nicht mehr nötig, BouncyCastle statisch in der aktuellen JVM zu installieren. Für Applikationen, die außerhalb des Containers laufen, kann der Sicherheitsprovider für JBossWS verfügbar gemacht werden, indem eine BouncyCastle-Bibliothek zum Klassenpfad hinzugefügt wird.

Sie können dieses Verhalten deaktivieren, indem Sie den Eigenschaftswert org.jboss.ws.cxf.noLocalBC auf true setzen in der Deployment-Deskriptordatei jaxws-endpoint-config.xml für den Server oder in der Deskriptordatei jaxws-client-config.xml für Clients.

Falls Sie eine andere Version als die in JBoss EAP enthaltene Version verwenden möchten, können Sie nach wie vor BouncyCastle statisch in der JVM installieren. In diesem Fall wird der statisch installierte BouncyCastle-Sicherheitsprovider gewählt anstelle des Providers im Klassenpfad. Um Probleme zu vermeiden, müssen Sie BouncyCastle 1.49, 1.51 oder höher verwenden.

Die standardmäßige Strategie zur Bus-Auswahl für Clients, die im Container ausgeführt werden, hat sich geändert von THREAD_BUS zu TCCL_BUS. Für Clients, die außerhalb des Containers ausgeführt werden, ist die Standardstrategie noch immer THREAD_BUS. Sie können zum Verhalten der vorherigen Release zurückkehren, indem Sie eine der beiden folgenden Maßnahmen durchführen.

Container müssen Konstruktoren im JAX-WS 2.2 Stil nutzen, unter Verwendung der WebServiceFeature-Klasse, um Clients zu erstellen, die in Webservice-Referenzen injiziert werden. Das bedeutet, dass vom Benutzer angegebene Serviceklassen, die vom Container injiziert wurden, JAX-WS 2.2 oder höher implementieren müssen.

In früheren Releases konnten Sie deaktivieren, dass der HTTPS URL-Hostname anhand des Common Name (CN) eines Services, der in dessen Zertifikat angegeben ist, überprüft wird. Sie erreichten dies durch Einstellen der Systemeigenschaft org.jboss.security.ignoreHttpsHost auf true. Diese Systemeigenschaft wurde ersetzt durch cxf.tls-client.disableCNCheck.

As a consequence of enabling injections into service endpoint and service client handlers, it is no longer possible to automatically load handler classes from the org.jboss.as.webservices.server.integration JBoss module. If your application depends on a given predefined configuration, you might need to explicitly define new module dependencies for your deployment. For more information, see Migrate Explicit Module Dependencies

Der Java Endorsed Standards Override Mechanism gilt seit JDK 1.8_40 als veraltet und wird in JDK 9 planmäßig entfernt. Dieser Mechanismus erlaubte es Entwicklern, Bibliotheken für alle deployten Applikationen verfügbar zu machen, indem JARs in ein entsprechendes Verzeichnis innerhalb der JRE platziert wurden.

Falls Ihre Applikation die JBossWS-Implementierung von Apache CXF verwendet, gewährleistet JBoss EAP 7, dass die erforderlichen Abhängigkeiten in der richtigen Reihenfolge hinzugefügt werden, weshalb diese Änderung keine Auswirkungen auf Sie haben sollte. Falls Ihre Applikation direkt auf Apache CXF zugreift, müssen Sie nun die Apache CXF Abhängigkeiten nach den JBossWS-Abhängigkeiten hinzufügen im Rahmen Ihres Applikations-Deployments.

In früheren Releases von JBoss EAP konnten Sie die Deployment-Deskriptordatei jboss-webservices.xml für EJB-Webservice-Deployments im Verzeichnis META-INF/ von JAR-Archiven oder im Verzeichnis WEB-INF/ für POJO-Webservice-Deployments und EJB-Webservice-Endpunkte gebündelt in WAR-Archiven konfigurieren.

In JBoss EAP 7 können Sie nun die Deployment-Deskriptordatei jboss-webservices.xml im Verzeichnis META-INF/ eines EAR-Archivs konfigurieren. Falls eine jboss-webservices.xml-Datei sowohl im EAR-Archiv als auch im JAR- oder WAR-Archiv gefunden wird, dann setzen die Konfigurationsdaten in der jboss-webservices.xml-Datei aus dem JAR oder WAR die entsprechenden Daten aus der EAR-Deskriptordatei außer Kraft.

Die proprietären JMS-Ressourcen-Deployment-Deskriptordateien mit dem Namensformat -jms.xml gelten in JBoss EAP 7 als veraltet. Nachfolgend sehen Sie ein Beispiel für eine JMS-Ressourcen-Deployment-Deskriptordatei in JBoss EAP 6.

<?xml version="1.0" encoding="UTF-8"?>
<messaging-deployment xmlns="urn:jboss:messaging-deployment:1.0">
  <hornetq-server>
    <jms-destinations>
      <jms-queue name="testQueue">
        <entry name="queue/test"/>
        <entry name="java:jboss/exported/jms/queue/test"/>
      </jms-queue>
      <jms-topic name="testTopic">
        <entry name="topic/test"/>
        <entry name="java:jboss/exported/jms/topic/test"/>
      </jms-topic>
    </jms-destinations>
  </hornetq-server>
</messaging-deployment>

Falls Sie in der früheren Release -jms.xml JMS-Deployment-Deskriptoren in Ihrer Applikation verwendet haben, können Sie Ihre Applikation entweder zur Verwendung des standardmäßigen Java EE 7 Deployment-Deskriptors konvertieren (siehe Abschnitt EE.5.18 der Java EE 7 specification) oder Sie können die Deployment-Deskriptoren auf das messaging-activemq-Subsystem in JBoss EAP 7 aktualisieren.

Falls Sie sich dazu entscheiden, den Deskriptor zu aktualisieren, müssen Sie die folgenden Änderungen vornehmen.

Die aktualisierte Datei sollte etwa wie das folgende Beispiel aussehen.

<?xml version="1.0" encoding="UTF-8"?>
<messaging-deployment xmlns="urn:jboss:messaging-activemq-deployment:1.0">
  <server>
    <jms-destinations>
      <jms-queue name="testQueue">
        <entry name="queue/test"/>
        <entry name="java:jboss/exported/jms/queue/test"/>
      </jms-queue>
      <jms-topic name="testTopic">
        <entry name="topic/test"/>
        <entry name="java:jboss/exported/jms/topic/test"/>
      </jms-topic>
    </jms-destinations>
  </server>
</messaging-deployment>

Weitere Informationen über Änderungen der Serverkonfiguration hinsichtlich Messaging finden Sie unter Änderungen der Messaging-Serverkonfiguration.

JBoss EAP 7 unterstützt weiterhin die JMS 1.1 API, Sie brauchen Ihren Code also nicht zu ändern.

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 Ihre Serverkonfiguration mithilfe der migrate-Operation migrieren, werden die alten Einstellungen bewahrt und Sie müssen Ihre PROVIDER_URL nicht aktualisieren. Wenn Sie dagegen die neue JBoss EAP 7 Standardkonfiguration verwenden, müssen Sie die PROVIDER_URL im Client-Code ändern, um die neue Einstellung http-remoting://localhost:8080 zu verwenden. Weitere Informationen finden Sie unter Migrieren von Remote-Naming-Client-Code.

Falls Sie planen, Ihren Code zur JMS 2.0 API zu migrieren, werfen Sie einen Blick auf den helloworld-jms-Quickstart für ein Arbeitsbeispiel.

JBoss EAP 6 enthielt das org.hornetq-Modul, das Ihnen die Verwendung der HornetQ-API in Ihrem Applikationsquellcode ermöglichte.

Apache ActiveMQ Artemis ersetzt HornetQ in JBoss EAP 7, weshalb Sie jeglichen Code, der die HornetQ-API verwendete, zur Apache ActiveMQ Artemis API migrieren müssen. Die Bibliotheken für diese API sind im Modul org.apache.activemq.artemis enthalten.

ActiveMQ Artemis ist eine Weiterentwicklung von HornetQ; viele der Grundlagen gelten weiterhin.

Interzeptor- und MessageBody-Klassen

JSR 311: JAX-RS: The Java™ API für RESTful-Webservices enthielt kein Interzeptor-Framework, weshalb RESTEasy 2 eines bereitstellte. JSR 339: JAX-RS 2.0: Die Java-API für RESTful-Webservices führte ein offizielles Interzeptor- und Filter-Framework ein, weshalb das in RESTEasy 2 enthaltene Interzeptor-Framework nun als veraltet gilt und durch die JAX-RS 2.0 konforme Interzeptor-Facility in RESTEasy 3.x. ersetzt wurde. Die relevanten Schnittstellen werden im Paket javax.ws.rs.ext des Moduls jaxrs-api definiert.

For more information about interceptors, see RESTEasy Interceptors in Developing Web Services Applications for JBoss EAP.

Weitere Informationen über die neue Ersatz-API finden Sie unter RESTEasy JAX-RS 3.0.13.Final API oder höher.

Client-API

Das RESTEasy-Client-Framework in resteasy-jaxrs wurde ersetzt durch das JAX-RS 2.0 konforme resteasy-client-Modul. Infolgedessen sind einige RESTEasy-Client-API-Klassen und -Methoden nun veraltet.

StringConverter

Die Klasse org.jboss.resteasy.spi.StringConverter gilt in RESTEasy 3.x als veraltet. Diese Funktionalität kann ersetzt werden durch Verwendung der JAX-RS 2.0 Klasse jax.ws.rs.ext.ParamConverterProvider.

ResteasyProviderFactory Add-Methoden

Die meisten der add()-Methoden von org.jboss.resteasy.spi.ResteasyProviderFactory wurden in RESTEasy 3.0 entfernt oder geschützt. Beispielsweise wurden die Methoden addBuiltInMessageBodyReader() und addBuiltInMessageBodyWriter() entfernt und die Methoden addMessageBodyReader() und addMessageBodyWriter() geschützt.

Sie sollten nun die Methoden registerProvider() und registerProviderInstance() verwenden.

Weitere von RESTEasy 3 entfernte Klassen

Die Annotation @org.jboss.resteasy.annotations.cache.ServerCached, die angibt, dass die Antwort auf die JAX-RS-Methode auf dem Server gecacht werden soll, wurde aus RESTEasy 3 entfernt und muss aus dem Applikationscode entfernt werden.

SignedInput und SignedOuput

Sicherheitsfilter

Die Sicherheitsfilter für @RolesAllowed, @PermitAll und @DenyAll geben nun »403 Forbidden« statt »401 Unauthorized« zurück.

Clientseitige Filter

Die neuen JAX-RS 2.0 clientseitigen Filter werden nicht gebunden und ausgeführt, wenn Sie die RESTEasy-Client-API aus der vorherigen Release verwenden.

Asynchrone HTTP-Unterstützung

Because the JAX-RS 2.0 specification adds asynchronous HTTP support using the @Suspended annotation and the AsynResponse interface, the RESTEasy proprietary API for asynchronous HTTP has been deprecated and might be removed as soon as RESTEasy 3.1. The asynchronous Tomcat and asynchronous JBoss Web modules have also been removed from the server installation. If you are not using the Servlet 3.0 container or higher, asynchronous HTTP server-side processing will be simulated and run synchronously in same request thread.

Serverseitiger Cache

Die Einrichtung des serverseitigen Caches hat sich verändert. Siehe RESTEasy-Dokumentation für weitere Informationen.

SPI-Ausnahmen

Alle SPI-Fehlerausnahmen gelten nun als veraltet und werden intern nicht mehr verwendet. Sie wurden durch entsprechende JAX-RS 2.0 Ausnahmen ersetzt.

InjectorFactory und Registry

Die InjectorFactory- und Registry-SPIs haben sich verändert. Dies sollte keinerlei Probleme verursachen, sofern Sie RESTEasy wie dokumentiert und unterstützt einsetzen.

Die in JBoss EAP enthaltene Version von Jackson hat sich geändert. Die vorherige Version von JBoss EAP umfasste Jackson 1.9.9. JBoss EAP 7 enthält nun Jackson 2.6.3 oder höher. Infolgedessen hat sich der Jackson-Provider geändert von resteasy-jackson-provider auf resteasy-jackson2-provider.

Das Upgrade auf resteasy-jackson2-provider erfordert einige Paketänderungen. Beispielsweise hat sich das Jackson-Annotationspaket geändert von org.codehaus.jackson.annotate auf com.fasterxml.jackson.annotation.

To switch your application to use the default provider that was included in the previous release of JBoss EAP, see Switching the Default Jackson Provider in Developing Web Services Applications for JBoss EAP.

Das Spring 4.0 Framework führte Unterstützung für Java 8 ein. Falls Sie planen, die RESTEasy 3.x Integration mit Spring zu verwenden, stellen Sie sicher, dass Sie 4.2.x als Mindestversion für Spring in Ihrem Deployment spezifizieren, da dies die früheste stabile Version ist, die von JBoss EAP 7 unterstützt wird.

Der RESTEasy Jettison JSON-Provider gilt in JBoss EAP 7 als veraltet und wird standardmäßig nicht mehr zu Deployments hinzugefügt. Wir raten Ihnen, auf den empfohlenen RESTEasy Jackson-Provider zu wechseln. Falls Sie es vorziehen, weiterhin den Jettison-Provider zu verwenden, müssen Sie eine explizite Abhängigkeit dafür in der Datei jboss-deployment-descriptor.xml definieren, wie im folgenden Beispiel veranschaulicht.

<?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>

For more information about how to define explicit dependencies, see Add an Explicit Module Dependency to a Deployment in the JBoss EAP Development Guide.

Die Integrationsklassen, die eine Verwendung von Hibernate ORM 3 in der vorherigen Release erleichtert haben, wurden aus JBoss EAP 7 entfernt. Falls Ihre Applikation noch Hibernate ORM 3 Bibliotheken verwendet, empfehlen wir Ihnen dringend, Ihre Applikation auf Hibernate ORM 5 zu migrieren, da Hibernate ORM 3 nicht mehr ohne Weiteres in JBoss EAP funktionieren wird. Falls Sie nicht zu Hibernate ORM 5 migrieren können, müssen Sie ein angepasstes JBoss-Modul für die Hibernate ORM 3 JARs definieren und die Hibernate ORM 5 Klassen aus Ihrer Applikation ausschließen.

Falls Ihre Applikation einen aktiven Second-Level-Cache benötigt, sollten Sie zu Hibernate ORM 5 migrieren, was in Infinispan 8.x integriert ist.

Applikationen, die mit Hibernate ORM 4.x geschrieben wurden, können weiterhin Hibernate ORM 4.x verwenden. Sie müssen ein angepasstes JBoss-Modul für die Hibernate ORM 4.x JARs definieren und die Hibernate ORM 5 Klassen aus Ihrer Applikation ausschließen. Allerdings empfehlen wir Ihnen dringend, Ihren Applikationscode zur Verwendung von Hibernate ORM 5 umzuschreiben. Informationen über die Migration zu Hibernate ORM 5 finden Sie unter Migrieren zu Hibernate ORM 5.

Falls Ihre Applikation eine persistence.xml-Datei enthält oder der Code die Annotationen @PersistenceContext oder @PersistenceUnit verwendet, so spürt JBoss EAP 7 dies während des Deployments auf und geht davon aus, dass die Applikation JPA verwendet. es fügt dem Klassenpfad Ihrer Applikation implizit die Hibernate ORM 5 Bibliotheken sowie ein paar andere Abhängigkeiten hinzu und verwendet standardmäßig diese Bibliotheken.

Dieser Abschnitt behandelt die erforderlichen Änderungen für die Migration von Hibernate ORM Version 4.3 zu Version 5. Weitere Informationen über die Veränderungen von Hibernate ORM 5 im Vergleich zu Hibernate ORM 4 finden Sie im Hibernate ORM 5.0 Migration Guide.

Entfernte und veraltete Klassen

Die folgenden veralteten Klassen wurden aus Hibernate ORM 5 entfernt.

Sonstige Änderungen an Klassen und Paketen

Typenhandhabung

Transaktionsverwaltung

Sonstige Hibernate ORM 5 Änderungen

Ändern Sie den Wert für den Remote-Verbindungsport von 4447 auf 8080 in der Datei jboss-ejb-client.properties.

Nachfolgend sehen Sie Beispiele für eine jboss-ejb-client.properties-Datei in der vorherigen und in der aktuellen Release.

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

Falls Sie die neue JBoss EAP 7 Konfiguration ausführen, hat sich der Standard-Connector von remote auf http-remoting geändert. Diese Änderung betrifft Clients, die Bibliotheken aus einer Release von JBoss EAP nutzen und mit einem Server in einer anderen Release verbinden.

Falls Sie die neue standardmäßige JBoss EAP 7 Konfiguration ausführen, müssen Sie Ihren Client-Code zur Verwendung des neuen standardmäßigen Remote-Ports und -Connectors konfigurieren.

Nachfolgend sehen Sie ein Beispiel dafür, wie Remote-Naming-Eigenschaften im Client-Code in JBoss EAP 6 spezifiziert wurden.

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

Nachfolgend sehen Sie ein Beispiel dafür, wie Remote-Naming-Eigenschaften im Client-Code in JBoss EAP 7 spezifiziert werden.

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

Authentifikations-Valves müssen manuell ersetzt werden durch die integrierten Undertow-Authentifizierungsmechanismen. In den folgenden Abschnitten finden Sie weitere Informationen über das Migrieren von Authentifikations-Valves.

For information about the changes required for SSO with SAML v2 configuration, see Changes from Previous Versions of JBoss EAP in How to Set Up SSO with SAML v2 for JBoss EAP.

For information about the differences in SSO configuration with Kerberos, see Differences from Configuring Previous Versions JBoss EAP in How to Set Up SSO with Kerberos for JBoss EAP.

Die folgende Liste beschreibt einige der neuen Clustering-Features, die Sie kennen sollten, wenn Sie Ihre Applikation von JBoss EAP 6 zu JBoss EAP 7 migrieren.

The remainder of this section describes how clustering changes might impact the migration of your applications to JBoss EAP 7.

JBoss EAP 7 führt eine neue Implementierung für Web-Session-Clustering ein. Diese ersetzt die vorherige Implementierung, die eng mit dem veralteten JBoss Web Subsystem-Quellcode verknüpft war.

Infolge der neuen Implementierung für Web-Session-Clustering verändert sich auch die Konfiguration der Applikation in der jboss-web.xml JBoss proprietären Webapplikation-XML-Deskriptordatei. Die nachfolgend aufgeführten sind die einzigen, in der Datei noch verbliebenen Clustering-Konfigurationselemente.

<jboss-web>
  ...
  <max-active-sessions>...</max-active-sessions>
  ...
  <replication-config>
    <replication-granularity>...</replication-granularity>
    <cache-name>...</cache-name>
  </replication-config>
  ...
</jboss-web>

Die folgende Tabelle beschreibt, wie für Elemente in der jboss-web.xml-Datei, die nun veraltet sind, ein ähnliches Verhalten erreicht werden kann.

Diese neue Implementierung unterstützt zudem Write-Through Cache-Speicher sowie Cache-Speicher nur mit Passivierung. Üblicherweise wird ein Write-Through Cache-Speicher zusammen mit einem Invalidierungs-Cache eingesetzt. Die Web-Session-Clustering-Implementierung in JBoss EAP 6 funktionierte nicht einwandfrei zusammen mit einem Invalidierungs-Cache.

In JBoss EAP 6 war es erforderlich, das Clustering-Verhalten für Stateful Session Beans (SFSBs) auf einer der folgenden Arten zu aktivieren.

In JBoss EAP 7 ist es nicht mehr erforderlich, das Clustering-Verhalten zu aktivieren. Wenn der Server unter Verwendung eines HA-Profils startet, wird der Zustand von SFSBs standardmäßig automatisch repliziert.

Sie können dieses Standardverhalten auf eine der folgenden Weisen deaktiveren.

In JBoss EAP 6 befanden sich die APIs für Clustering-Services in privaten Modulen und wurden nicht unterstützt.

JBoss EAP 7 führte eine öffentliche Clustering-Service-API für die Applikationen ein. Die neuen Services wurden konzipiert mit einem schlanken Design, sind einfach einzuspeisen, und erfordern keine externe Abhängigkeiten.

Diese Services ersetzen ähnliche APIs, die in vorherigen Releases verfügbar waren, nämlich HAPartition aus JBoss EAP 5 und GroupCommunicationService, GroupMembershipNotifier und GroupRpcDispatcher in JBoss EAP 6.

For more information, see Public API for Clustering Services in the JBoss EAP Development Guide.

In JBoss EAP 6 gab es keine öffentliche API für den clusterweiten HA-Singleton-Service. Wenn Sie die privaten org.jboss.as.clustering.singleton.* Klassen verwendet haben, müssen Sie für die Migration Ihrer Applikationen zu JBoss EAP 7 Ihren Code ändern, um die neuen öffentlichen org.wildfly.clustering.singleton.* Pakete zu verwenden.

For more information about how to implement an HA singleton, see HA Singleton Service in the Development Guide for JBoss EAP.