Red Hat JBoss Enterprise Application Platform 7.0 ... · Red Hat JBoss Enterprise Application...

Red Hat JBoss Enterprise ApplicationPlatform 7.0

Migrationshandbuch

For Use with Red Hat JBoss Enterprise Application Platform 7.0

Last Updated: 2018-01-05

Red Hat JBoss Enterprise Application Platform 7.0 Migrationshandbuch

For Use with Red Hat JBoss Enterprise Application Platform 7.0

Rechtlicher Hinweis

Copyright © 2018 Red Hat, Inc.

The text of and illustrations in this document are licensed by Red Hat under a Creative CommonsAttribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA isavailable athttp://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you mustprovide the URL for the original version.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert,Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinitylogo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and othercountries.

Linux ® is the registered trademark of Linus Torvalds in the United States and other countries.

Java ® is a registered trademark of Oracle and/or its affiliates.

XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United Statesand/or other countries.

MySQL ® is a registered trademark of MySQL AB in the United States, the European Union andother countries.

Node.js ® is an official trademark of Joyent. Red Hat Software Collections is not formally related toor endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack ® Word Mark and OpenStack logo are either registered trademarks/service marksor trademarks/service marks of the OpenStack Foundation, in the United States and other countriesand are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed orsponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

Zusammenfassung

In diesem Handbuch finden Sie Informationen zur Migration von früheren Versionen der Red HatJBoss Enterprise Application Platform.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Inhaltsverzeichnis

KAPITEL 1. EINFÜHRUNG1.1. ÜBER DIE RED HAT JBOSS ENTERPRISE APPLICATION PLATFORM 71.2. ÜBER DAS MIGRATIONSHANDBUCH1.3. ÜBER MIGRATIONEN UND UPGRADES1.4. ZUR VERWENDUNG DER EAP_HOME IN DIESEM DOKUMENT

KAPITEL 2. VORBEREITUNG DER MIGRATION2.1. VORBEREITUNG IM ÜBERBLICK2.2. JAVA EE 7 FEATURES2.3. WAS IST NEU IN JBOSS EAP 7?2.4. LISTE VERALTETER UND NICHT UNTERSTÜTZTER FEATURES2.5. INFORMATIONEN IM JBOSS EAP GETTING STARTED GUIDE2.6. MIGRATIONSANALYSE UND PLANUNG2.7. SICHERN WICHTIGER DATEN UND PRÜFEN DES SERVERSTATUS2.8. MIGRIEREN EINER RPM-INSTALLATION2.9. MIGRIEREN VON JBOSS EAP ALS DIENST

KAPITEL 3. TOOLS FÜR DIE MIGRATION3.1. VERWENDEN VON WINDUP ZUR ANALYSE VON APPLIKATIONEN ZUR MIGRATION3.2. VERWENDEN DES JBOSS SERVER MIGRATION TOOLS ZUR MIGRATION VONSERVERKONFIGURATIONEN

KAPITEL 4. ÄNDERUNGEN DER SERVERKONFIGURATION4.1. OPTIONEN ZUR MIGRATION DER SERVERKONFIGURATION

JBoss Server Migration Toolmigrate-Operation der Management-CLI

4.2. MIGRATE-OPERATION DER MANAGEMENT-CLIStarten des Servers und der Management-CLIMigrieren der JacORB-, Messaging- und Web-Subsysteme

4.3. GEÄNDERTE PRÄFIXE FÜR PROTOKOLLEINTRÄGE4.4. ÄNDERUNGEN DER WEBSERVERKONFIGURATION

4.4.1. Ersetzen des Web-Subsystems durch Undertow4.4.2. Migrieren von JBoss Web Rewrite-Bedingungen4.4.3. Migrieren von JBoss Web Systemeigenschaften4.4.4. Migrate JBoss Web jboss-web.xml Overlay4.4.5. Migrieren von globalen Valves

Migrieren von JBoss Web ValvesManuelles Migrationsverfahren für JDBCAccessLogValve

4.5. ÄNDERUNGEN DER JGROUPS-SERVERKONFIGURATION4.5.1. Private Netzwerkschnittstelle als Standard in JGroups4.5.2. Änderungen der JGroups-Channels

4.6. ÄNDERUNGEN DER INFINISPAN-SERVERKONFIGURATION4.6.1. Änderungen der standardmäßigen Infinispan-Cache-Konfiguration4.6.2. Änderungen der Infinispan-Cache-Strategie

4.7. ÄNDERUNGEN DER EJB-SERVERKONFIGURATIONDuplicateServiceException

4.8. ÄNDERUNGEN DER MESSAGING-SERVERKONFIGURATION4.8.1. Änderungen der Messaging-Subsystem-Serverkonfiguration

Management-ModellMigration und Aufwärtskompatibilität des Messaging-SubsystemsGeändertes Verhalten des forward-when-no-consumers AttributsÄnderungen der Messaging-Subsystem-XML-Konfiguration

66667

88889

1010121212

1313

13

141414141415162020202124242425262727272727272828282929293030

Inhaltsverzeichnis

1

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.8.2. Migrieren von Messaging-Daten4.8.2.1. Migrieren von Messaging-Daten mittels Export und Import

Exportieren der Messaging-Daten der vorherigen ReleaseImportieren der XML-formatierten Messaging-Daten

4.8.2.2. Migrieren von Messaging-Daten mittels JMS-BridgeKonfigurieren des JBoss EAP 6 ServersKonfigurieren des JBoss EAP 7 ServersMigrieren der Daten

4.8.2.3. Zuordnung der Messaging-Verzeichnisnamen4.8.3. Migrieren von JMS-Zielen4.8.4. Migrieren von Messaging-Interzeptoren4.8.5. Ersetzen der Netty-Servlet-Konfiguration

4.9. JMX MANAGEMENT CHANGES4.10. ÄNDERUNGEN DER ORB-SERVERKONFIGURATION4.11. MIGRIEREN DER THREADS-SUBSYSTEMKONFIGURATION4.12. MIGRIEREN DER REMOTING-SUBSYSTEMKONFIGURATION4.13. ÄNDERUNGEN DER WEBSOCKET-SERVERKONFIGURATION4.14. ÄNDERUNGEN DES SINGLE SIGN-ON SERVERS4.15. ÄNDERUNGEN DER DATASOURCE-KONFIGURATION

4.15.1. JBDC-Datasource-TreibernameTreiber mit einer einzelnen KlasseTreiber mit mehreren Klassen

4.16. SICHERHEITSRELEVANTE SERVER-KONFIGURATIONSÄNDERUNGEN4.17. ÄNDERUNGEN AM TRANSAKTIONSSUBSYSTEM

Removed Transactions Subsystem AttributesVeraltete Parameter des Transaktionssubsystems

4.18. ÄNDERUNGEN DER MOD_CLUSTER KONFIGURATION

KAPITEL 5. ÄNDERUNGEN BEI APPLIKATIONSMIGRATION5.1. ÄNDERUNGEN DER WEBSERVICES-APPLIKATION

5.1.1. Änderungen der JAX-RPC-Unterstützung5.1.2. Änderungen der Apache CXF Spring Webservices

Apache CXF-InterzeptorenApache CXF-FeaturesApache CXF HTTP-Transport

5.1.3. Änderungen der WS-Security5.1.4. Änderungen der JBoss-Modulstruktur5.1.5. Änderungen und Voraussetzungen von BouncyCastle5.1.6. Apache CXF-Bus Auswahlstrategie5.1.7. JAX-WS 2.2 Anforderungen für WebServiceRef5.1.8. Änderungen der IgnoreHttpsHost CN-Überprüfung5.1.9. Serverseitige Konfiguration und Klassenladen5.1.10. Auslaufen des »Java Endorsed Standards Override Mechanism«5.1.11. Spezifikation von Deskriptor in EAR-Archiv

5.2. ÄNDERUNGEN DES REMOTE-URL-CONNECTORS UND -PORTS5.3. ÄNDERUNGEN DER MESSAGING-APPLIKATION

5.3.1. Ersetzen oder Aktualisieren von JMS-Deployment-Deskriptoren5.3.2. Aktualisieren der externen JMS-Clients5.3.3. Ersetzen der HornetQ-API

5.4. ÄNDERUNGEN DER JAX-RS UND RESTEASY-APPLIKATION5.4.1. Veraltete Klassen in RESTEasy

Interzeptor- und MessageBody-KlassenClient-API

303131323232333636363737383942424343444444444445454545

46464646474748494949505050505050515151525253535355


2

StringConverter5.4.2. Entfernte oder geschützte RESTEasy-Klassen

ResteasyProviderFactory Add-MethodenWeitere von RESTEasy 3 entfernte Klassen

5.4.3. Weitere RESTEasy-ÄnderungenSignedInput und SignedOuputSicherheitsfilterClientseitige FilterAsynchrone HTTP-UnterstützungServerseitiger Cache

5.4.4. Änderungen der RESTEasy SPISPI-AusnahmenInjectorFactory und Registry

5.4.5. Änderungen des Jackson-Providers5.4.6. Änderungen der Spring RESTEasy-Integration5.4.7. Änderungen des RESTEasy Jettison JSON-Providers

5.5. ÄNDERUNGEN DER CDI 1.2 APPLIKATIONBean-ArchiveKlärung der KonversationsauflösungObserver-Auflösung

5.6. MIGRIEREN EXPLIZITER MODULABHÄNGIGKEITENÜberprüfen der Abhängigkeiten auf VerfügbarkeitAbhängigkeiten, die Annotations-Prüfung erfordern

5.7. ÄNDERUNGEN HINSICHTLICH HIBERNATE UND JPA5.7.1. Hibernate ORM 3.05.7.2. Hibernate ORM 4.0 – 4.35.7.3. Hibernate ORM 55.7.4. Migrieren zu Hibernate ORM 5

Entfernte und veraltete KlassenSonstige Änderungen an Klassen und PaketenTypenhandhabungTransaktionsverwaltungSonstige Hibernate ORM 5 Änderungen

5.8. ÄNDERUNGEN HINSICHTLICH HIBERNATE SEARCHÄnderungen des Hibernate Search Mappings

Indexierung von ID-Feldern in eingebetteten ObjektenÄnderungen der Formatierung von Zahlen- und Datumsindexierung

Sonstige Änderungen hinsichtlich Hibernate SearchUnbenannte und neu paketierte Klassen in Hibernate SearchUnbenannte und neu paketierte Klassen in LuceneVeraltete APIs in Hibernate Search

Veraltete Schnittstellen in Hibernate SearchVeraltete Klassen in Hibernate SearchVeraltete Aufzählungen in Hibernate SearchVeraltete Annotationen in Hibernate SearchVeraltete Methoden in Hibernate SearchVeraltete Konstruktoren in Hibernate Search

Änderungen mit Auswirkungen auf erweiterte Integratoren5.9. MIGRIEREN VON ENTITY-BEANS ZU JPA5.10. ÄNDERUNGEN DER JPA-PERSISTENZEIGENSCHAFT5.11. MIGRIEREN VON EJB-CLIENT-CODE

5.11.1. Aktualisieren des standardmäßigen Remote-Verbindungsports5.11.2. Aktualisieren des Standard-Connectors

5656565757575757575757575858585859596060606060616161616262626263636464646465666667676767686868696971727272

Inhaltsverzeichnis

3

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.11.3. Migrieren von Remote-Naming-Client-Code5.12. MIGRIEREN VON DEPLOYMENT-PLAN-KONFIGURATIONEN5.13. MIGRIEREN VON ANGEPASSTEN APPLIKATIONS-VALVES

Migrieren der in Deployments konfigurierten ValvesMigrieren von angepassten Authentifikations-Valves

5.14. SICHERHEITSRELEVANTE APPLIKATIONSÄNDERUNGEN5.14.1. Migrieren von Authentifikations-Valves5.14.2. Änderungen an PicketLink5.14.3. Sonstige sicherheitsrelevante Applikationsänderungen

5.15. ÄNDERUNGEN AN DER JBOSS-PROTOKOLLIERUNG5.16. JAVASERVER FACES (JSF) CODE-ÄNDERUNGEN

Beendete Unterstützung für JSF 1.2Kompatibilitätsprobleme zwischen JSF 2.1 und JSF 2.2

5.17. ÄNDERUNGEN AM MODUL-KLASSENLADEN5.18. ÄNDERUNGEN DES APPLIKATIONS-CLUSTERINGS

5.18.1. Überblick über neue Clustering-Features5.18.2. Änderungen des Web-Session-Clusterings5.18.3. Änderungen am Stateful Session EJB Clustering5.18.4. Änderungen des Clustering-Services5.18.5. Migrieren des Clustering-HA-Singletons

KAPITEL 6. SONSTIGE ÄNDERUNGEN6.1. ÄNDERUNGEN BEI DER LIEFERUNG VON JBOSS EAP NATIVES UND APACHE HTTP SERVER6.2. ÄNDERUNGEN AN DEPLOYMENTS AUF AMAZON EC26.3. ÄNDERUNGEN AN JBOSS EAP SKRIPTEN6.4. ENTFERNUNG DER OSGI-UNTERSTÜTZUNG

KAPITEL 7. MIGRIEREN VON ÄLTEREN JBOSS EAP RELEASES7.1. MIGRIEREN VON JBOSS EAP 5 ZU JBOSS EAP 77.2. ZUSAMMENFASSUNG DER ÄNDERUNGEN AN JEDER RELEASE7.3. LESEN DER MIGRATIONSHANDBÜCHER7.4. LISTE DER JBOSS EAP 5 KOMPONENTEN-UPGRADES

ANHANG A. REFERENZMATERIALA.1. WARNUNGEN DER MIGRATION-OPERATION FÜR DAS JACORB-SUBSYSTEMA.2. WARNUNGEN DER MIGRATION-OPERATION FÜR DAS MESSAGING-SUBSYSTEM

Replace the Deprecated broadcast-group or discovery-group Attributes (Ersetzen Sie die veralteten Attribute»broadcast-group« oder »discovery-group«)

A.3. WEB SUBSYSTEM MIGRATION OPERATION WARNINGSWeb Subsystem Migration Operation Attribute Warnings

Web SSL Connector AttributesWeb Static Resource AttributesWeb SSO Resource AttributesWeb Access Log AttributesWeb Connector Attributes

A.4. ÜBERSICHT ÜBER DAS MIGRIEREN VON JBOSS WEB SYSTEMEIGENSCHAFTENA.5. KOMPATIBILITÄT UND INTEROPERABILITÄT ZWISCHEN RELEASES

EJB Remoting über IIOPEJB Remoting mittels JNDIEJB Remoting mittels @WebServiceStandalone Messaging-ClientMessaging-MDBsJMS-Bridges

7373737474747474747575757676777777798081

8282838383

8585858686

959596

100101104105105106106106107116116117117117117118


4

Inhaltsverzeichnis

5

KAPITEL 1. EINFÜHRUNG

1.1. ÜBER DIE RED HAT JBOSS ENTERPRISE APPLICATIONPLATFORM 7

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

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

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

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

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

1.2. ÜBER DAS MIGRATIONSHANDBUCH

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

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

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

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

1.3. ÜBER MIGRATIONEN UND UPGRADES

Große Upgrades

A major upgrade or migration is required when an application is moved from one major release toanother, for example, from JBoss EAP 6 to JBoss EAP 7. This is the type of migration addressed in thisguide. If an application follows the Java EE specifications, does not access deprecated APIs, and doesnot contain proprietary code, it might be possible to run the application in JBoss EAP 7 without anyapplication code changes. However, server configuration has changed in JBoss EAP 7 and any serverconfiguration settings require migration.


6

Kleinere Updates

JBoss EAP periodically provides point releases, which are minor updates that include bug fixes, securityfixes, and new features. The JBoss EAP Patching and Upgrading Guide describes how to upgrade fromone point release to another, for example from JBoss EAP 7.0 to JBoss EAP 7.1.

Kumulative Patches

JBoss EAP also periodically provides cumulative patches that contain bug and security fixes. Cumulativepatches increment the release by the last digit, for example from 7.0.0 to 7.0.1. Patch installation iscovered in detail in the JBoss EAP Patching and Upgrading Guide.

1.4. ZUR VERWENDUNG DER EAP_HOME IN DIESEM DOKUMENT

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

Wenn Sie die JBoss EAP mittels ZIP-Installationsmethode installiert haben, ist dasInstallationsverzeichnis das Verzeichnis jboss-eap-7.0, aus dem Sie das ZIP-Archivextrahiert haben.

Wenn Sie die JBoss EAP mittels RPM-Installationsmethode installiert haben, ist dasInstallationsverzeichnis /opt/rh/eap7/root/usr/share/wildfly/.

Wenn Sie die JBoss EAP mittels Installer installiert haben, so ist ${user.home}/EAP-7.0.0der Standardpfad für EAP_HOME:

Für Red Hat Enterprise Linux, Solaris und HP-UX: /home/USER_NAME/EAP-7.0.0/

Für Microsoft Windows: C:\Users\USER_NAME\EAP-7.0.0\

Wenn Sie den JBoss Developer Studio Installer benutzt haben, um den JBoss EAP Server zuinstallieren und zu konfigurieren, so ist EAP_HOME der Standardpfad für ${user.home}/jbdevstudio/runtimes/jboss-eap:

Für Red Hat Enterprise Linux: /home/USER_NAME/jbdevstudio/runtimes/jboss-eap/

Für Microsoft Windows: C:\Users\USER_NAME\jbdevstudio\runtimes\jboss-eapoder C:\Documents and Settings\USER_NAME\jbdevstudio\runtimes\jboss-eap\

ANMERKUNG

EAP_HOME ist keine Umgebungsvariable. JBOSS_HOME ist die Umgebungsvariable, die inSkripts verwendet wird.

KAPITEL 1. EINFÜHRUNG

7

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/patching-and-upgrading-guide/

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/patching-and-upgrading-guide/

KAPITEL 2. VORBEREITUNG DER MIGRATION

2.1. VORBEREITUNG IM ÜBERBLICK

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 fromJBoss 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 EAP7 applications. It is recommended that you do some research and planning before you attempt to migrateyour application.

Machen Sie sich mit den Features von Java EE 7 vertraut.

Lesen Sie Was ist neu in JBoss EAP 7?.

Überprüfen Sie die Liste veralteter und nicht unterstützter Features.

Review the material in the JBoss EAP 7 Getting Started Guide.

Sehen Sie sich die Tools an, die Ihnen bei der Migration behilflich sein können.

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

2.2. JAVA EE 7 FEATURES

Java EE 7 enthält viele Verbesserungen, die das Entwickeln und Betreiben funktionsreicherApplikationen in Private und Public Clouds erleichtern. Es beinhaltet neue Features und die neuestenStandards wie HTML5, WebSocket, JSON, Batch und Concurrency Utilities. Aktualisierungen umfassenJPA 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 undBean Validation 1.1.

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

2.3. WAS IST NEU IN JBOSS EAP 7?

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

Java EE 7

JBoss EAP 7 ist eine zertifizierte Implementierung von Java EE 7, die sowohl das Web- als auch dasFull-Profil abbildet. Es unterstützt zudem die neuesten Versionen von CDI 1.2 und Web Sockets 1.1.

Undertow

Undertow ist der neue schlanke, flexible und leistungsstarke Webserver in JBoss EAP 7, der JBossWeb ersetzt. Er wurde in Java geschrieben und für maximalen Durchsatz und Skalierbarkeitkonzipiert. Er unterstützt die neusten Webtechnologien wie z.B. den neuen HTTP/2-Standard.

Apache ActiveMQ Artemis


8

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/getting-started-guide/

http://www.oracle.com/technetwork/java/javaee/overview/index.html

Apache ActiveMQ Artemis ist der neue, in JBoss EAP 7 integrierte Messaging-Provider. Aufbauendauf einer Codespende von HornetQ, bietet dieses Apache-Unterprojekt herausragende Performancebasierend auf einer bewährten, nicht blockierenden Architektur.

IronJacamar 1.2

Die neueste Version von IronJacamar bietet eine stabile und funktionsreiche Unterstützung für JCAund DataSources.

JBossWS 5

The fifth generation of JBossWS is a major leap forward, bringing new features and performanceimprovements to JBoss EAP 7 web services.

RESTEasy 3

JBoss EAP 7 enthält die neueste Generation von RESTEasy. Es geht über die standardmäßigenJava EE REST APIs (JAX-RS 2.0) hinaus, indem es eine Reihe von hilfreichen Erweiterungen wiez.B. JSON Web Encryption, Jackson, YAML, JSON-P und Jettison bereitstellt.

OpenJDK ORB

JBoss EAP 7 ersetzte die JacORB IIOP Implementierung durch einen Downstream-Zweig derOpenJDK ORB, was zu einer besseren Interoperabilität mit dem JVM ORB und der Java EE RI führt.

Funktionsreiches Clustering

Die Clustering-Unterstützung wurde in JBoss EAP 7 grundlegend überarbeitet und enthält mehrereöffentliche APIs für den Zugriff durch Applikationen.

Port-Reduktion

Aufgrund eines HTTP-Upgrades konnte JBoss EAP 7 fast alle seiner Protokolle mittels Multiplexingin nur zwei HTTP-Ports zusammenfassen: einen Management-Port (9990) und einen Applikations-Port (8080).

Erweiterte Protokollierung

Die Management-API unterstützt nun das Anzeigen und Einsehen der verfügbaren Protokolldateienauf einem Server sowie das Definieren angepasster Formatierungen. Die Einrichtung derProtokollierung im Deployment wurde ebenfalls weit verbessert.

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

2.4. LISTE VERALTETER UND NICHT UNTERSTÜTZTER FEATURES

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

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

EJB Entity Beans

EJB Entity Beans werden nicht mehr unterstützt. Falls Ihre Applikation EJB Entity Beans verwendet,sollten Sie den Code auf JPA umstellen, die eine sehr viel performantere und flexiblere API bietet.

JAX-RPC

Da JAX-WS eine sehr viel exaktere und umfassendere Lösung bietet, sollte Code, der für JAX-RPCgeschrieben wurde, auf die Verwendung von JAX-WS umgestellt werden.

JSR-88

Die Java EE Application Deployment API Spezifikation (JSR-88) definierte einen Vertrag, der esTools verschiedener Anbieter ermöglichen sollte, Applikationen auf jeder beliebigen Java EE


9

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/700-release-notes/#release_notes_new_features

Plattform zu konfigurieren und bereitzustellen. Diese Spezifikation fand jedoch keine breiteAnwendung. Sie müssen eine andere von JBoss EAP unterstützte Option zurAnwendungsbereitstellung verwenden wie z.B. die Management-Konsole, das Management-CLI,Deployment Scanner oder Maven.

Generischer JMS-Ressourcenadapter

Die Fähigkeit zur Konfiguration eines generischen JMS-Ressourcenadapters zur Verbindung miteinem JMS-Provider wird in JBoss EAP 7 nicht mehr unterstützt.

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

2.5. INFORMATIONEN IM JBOSS EAP GETTING STARTED GUIDE

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

Download und Installation von JBoss EAP 7

Download und Installation von Red Hat JBoss Developer Studio

Konfiguration von Maven für Ihre Entwicklungsumgebung, Verwalten von Projektabhängigkeitenund Konfigurieren Ihrer Projekte zur Verwendung der JBoss EAP Bill of Material (BOM) Artefakte

Download und Betrieb des im Produkt enthaltenen Quickstart-Beispiels

2.6. MIGRATIONSANALYSE UND PLANUNG

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

Identifizieren der Verantwortlichen für die Migration

Identifizieren Sie die Interessengruppen, Projektmanager, Entwickler, Administratoren und anderePersonen oder Personenkreise, die für die Migration verantwortlich sind.

Überprüfen der Applikationsserverplattform-Konfiguration und -Hardware

Untersuchen Sie die Konfiguration der vorhandenen Applikationsserverplattform, um zu beurteilen,wie sich die veränderten Features in JBoss EAP 7 auswirken. Diese Prüfung sollte die folgendenAspekte berücksichtigen.

Betriebssysteme und Versionen

Von den Applikationen verwendete Datenbanken

Webserver

Sicherheitsarchitektur

Anzahl und Art der Prozessoren

Menge an Arbeitsspeicher

Menge an Festplattenspeicher

Migration von Datenbank- oder Messaging-Daten


10

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/700-release-notes/#release_notes_unsupported_and_deprecated_functionality

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/getting-started-guide/

Other components that might be impacted by the migration

Überprüfen der derzeitigen Produktionsumgebung

Sie sollten planen, die Produktionsumgebung so genau wie möglich nachzubilden, um denMigrationsprozess zu testen.

Take into account any clustering configurations. See Upgrading a Cluster in the JBoss EAPPatching and Upgrading Guide for more information about how to migrate clusters.

Falls Sie derzeit eine umfangreiche verwaltete Domain betreiben, sollten Sie eineschrittweise Migration in Betracht ziehen.

Klären Sie, ob Sie Datenbank- oder Messaging-Daten migrieren müssen.

Untersuchen und Verstehen der vorhandenen Applikation

Untersuchen Sie die vorhandene JBoss EAP 6 Applikation gründlich. Machen Sie sich bis ins Detailvertraut mit deren Architektur, Funktionen und Komponenten, einschließlich:

JVM-Version

Integration mit anderen Red Hat Applikationsserver-Middleware-Komponenten

Integration mit proprietärer Software von Drittanbietern

Nutzung von nicht weitergeführten Funktionen, die anderweitig ersetzt werden müssen

Applikationskonfiguration einschließlich Deployment-Deskriptoren, JNDI, Persistenz, JDBC-Konfiguration und Pooling, JMS-Topics und -Queues sowie Protokollierung

Identifizieren Sie jeglichen inkompatiblen Code oder Konfigurationen, an denen während derMigration zu JBoss EAP 7 Änderungen vorgenommen werden müssen.

Erstellen eines detaillierten Testplans

Der Plan sollte Anforderungen für Regressionstests und Annahmekriterien enthalten.

Er sollte zudem einen Performancetest enthalten.

Richten Sie eine Testumgebung ein, die möglichst genau die Produktionsumgebungnachbildet, um die Migration zu testen, bevor diese in der Produktionsumgebungdurchgeführt wird.

Entwerfen Sie unbedingt auch einen Plan für Backup und Backout, also für eine Rückkehrzum Status Quo im Falle einer gescheiterten Migration.

Überprüfen der verfügbaren Ressourcen für den Migrationsvorgang

Bewerten Sie die Fähigkeiten des Entwicklungsteams und planen Sie gegebenenfallszusätzliche Fortbildungen oder externe Berater ein.

Beachten Sie, dass für das Testen während des Migrationsvorgangs zusätzliche Hardwareund andere Ressourcen nötig sind, bis die gesamte Maßnahme abgeschlossen ist.

Entscheiden Sie, ob Schulungen nötig sind und fügen Sie diese gegebenenfalls im Zeitplanein.


11

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/patching-and-upgrading-guide/#patching_and_upgrading_a_cluster

Ausführen des Plans

Vereinen Sie die erforderlichen Ressourcen und implementieren Sie den Migrationsplan.

WICHTIG

Ehe Sie jegliche Änderungen an Ihrer Applikation vornehmen, sollten Sie unbedingt einBackup erstellen.

2.7. SICHERN WICHTIGER DATEN UND PRÜFEN DES SERVERSTATUS

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

The migration might remove temporary folders. Any deployments stored in the data/content/directory must be backed up prior to the migration and restored after it completes. Otherwise, theserver will fail to start due to the missing content.

Schließen Sie vor Beginn der Migration alle noch offenen Transaktionen ab und löschen Sie dasTransaktionsverzeichnis data/tx-object-store/.

Die persistenten Timerdaten in data/timer-service-data müssen auf deren Kompatibilitäthin überprüft werden. Untersuchen Sie die deployment-* Dateien in diesem Verzeichnis, umherauszufinden, welche Timer noch in Gebrauch sind.

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

2.8. MIGRIEREN EINER RPM-INSTALLATION

WICHTIG

Es wird nicht unterstützt, mehr als eine RPM-installierte Instanz von JBoss EAP auf einemeinzigen Red Hat Enterprise Linux Server auszuführen. Aufgrund dessen empfehlen wir,dass Sie Ihre JBoss EAP Installation auf einen neuen Rechner migrieren, wenn Sie zuJBoss EAP 7 migrieren.

Stellen Sie bei der Migration einer JBoss EAP RPM-Installation von JBoss EAP 6 zuJBoss EAP 7 sicher, dass JBoss EAP 7 auf einem Rechner installiert ist, der keinevorhandene JBoss EAP RPM-Installation hat.

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 youmight need to alter some steps (such as how to start JBoss EAP) to suit an RPM installation compared toa ZIP or installer installation.

2.9. MIGRIEREN VON JBOSS EAP ALS DIENST

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


12

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/installation-guide/#rpm_installation

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/installation-guide/#configuring_jboss_eap_to_run_as_a_service

KAPITEL 3. TOOLS FÜR DIE MIGRATION

3.1. VERWENDEN VON WINDUP ZUR ANALYSE VON APPLIKATIONENZUR MIGRATION

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

Detaillierte Erklärung der nötigen Migrationsänderungen

Ob die ausgewiesene Änderung optional oder zwingend erforderlich ist

Ob die ausgewiesene Änderung komplex oder einfach ist

Links zum Code, der die Migrationsänderung erfordert

Tipps und Links zu Informationen über die Durchführung der nötigen Änderungen

Eine Schätzung des Aufwands für jedes gefundene Migrationsproblem und der Gesamtaufwandzur Migration der Applikation

Sie können Windup zur Analyse des Codes und der Architektur Ihrer JBoss EAP 6 Applikationenverwenden, bevor Sie diese zu JBoss EAP 7 migrieren. Das Windup-Regelset zur Migration von JBossEAP 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 Applikationenfinden Sie im Windup User Guide.

3.2. VERWENDEN DES JBOSS SERVER MIGRATION TOOLS ZURMIGRATION VON SERVERKONFIGURATIONEN

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

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

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

ANMERKUNG

Die Vorab-Releaseversion des JBoss Server Migration Tools wird noch nicht unterstützt.

KAPITEL 3. TOOLS FÜR DIE MIGRATION

13

https://access.redhat.com/documentation/en/red-hat-jboss-migration-toolkit/

https://github.com/wildfly/wildfly-server-migration/releases

https://docs.jboss.org/author/display/CMTOOL/JBoss+Server+Migration+Tool+User+Guide

KAPITEL 4. ÄNDERUNGEN DER SERVERKONFIGURATION

4.1. OPTIONEN ZUR MIGRATION DER SERVERKONFIGURATION

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

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

migrate-Operation der Management-CLISie 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 unterder neuen Release laufen können. Beachten Sie jedoch, dass das Ergebnis keine vollständige JBossEAP 7 Konfiguration darstellt. Zum Beispiel:

Die Operation aktualisiert nicht die vorhandenen Einstellungen des remote-Protokolls und -Ports auf das neue http-remoting-Protokoll und die neuen Porteinstellungen für JBoss EAP7.

Die Konfiguration enthält nicht die neuen JBoss EAP Subsysteme oder Funktionen wiebeispielsweise geclusterte Singleton-Deployments oder das ordnungsgemäße Beenden.

Die Konfiguration umfasst nicht die neuen Java EE 7 Funktionen wie zum Beispiel Batch-Verarbeitung.

Die migrate-Operation migriert nicht die Konfiguration des ejb3-Subsystems. WeitereInformationen über mögliche EJB-Migrationsprobleme finden Sie unter Änderungen der EJB-Serverkonfiguration.

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

4.2. MIGRATE-OPERATION DER MANAGEMENT-CLI

Sie können die Management-CLI dazu verwenden, um Ihre JBoss EAP 6 Serverkonfigurationsdateienfü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 Releaseauf die neue Konfiguration zu aktualisieren. Sie können auch die Operation describe-migration fürdie Subsysteme jacorb, messaging und web ausführen, um die vorgeschlagenenKonfigurationsänderungen zu überprüfen, bevor Sie die Migration durchführen. Es gibt keinen Ersatz fürdie Subsysteme cmp, jaxr und threads, weshalb diese aus der Serverkonfiguration entfernt werdenmüssen.


14

WICHTIG

Siehe Optionen zur Migration der Serverkonfiguration für Einschränkungen der migrate-Operation. Das JBoss Server Migration Tool, was sich derzeit in der Entwicklung befindet,wird in Zukunft die bevorzugte Methode zur Aktualisierung Ihrer Konfiguration sein, umdie neuen Features und Einstellungen in JBoss EAP 7 zu implementieren und gleichzeitigIhre vorhandene Konfiguration beizubehalten.

Tabelle 4.1. Migration von Subsystemen und Management-CLI-Operation

JBoss EAP 6 Subsystem JBoss EAP 7 Subsystem Management-CLI-Operation

cmp kein Ersatz remove

jacorb iiop-openjdk migrate

jaxr kein Ersatz remove

messaging messaging-activemq migrate

threads kein Ersatz remove

web undertow migrate

Starten des Servers und der Management-CLIFolgen Sie den nachstehenden Schritten, um Ihre JBoss EAP 6 Serverkonfiguration für die Ausführungauf JBoss EAP 7 zu aktualisieren.

1. Bevor Sie beginnen, werfen Sie einen Blick auf Sichern wichtiger Daten und Prüfen desServerstatus. Dort finden Sie wichtige Informationen über die Vorbereitung des Servers und dieSicherung der richtigen Daten.

2. Starten Sie den JBoss EAP 7 Server mit der JBoss EAP 6 Konfiguration.

a. Sichern Sie die JBoss EAP 7 Serverkonfigurationsdateien.

b. Kopieren Sie die Konfigurationsdatei von der vorherigen Release in das JBoss EAP 7Verzeichnis.

$ cp EAP6_HOME/standalone/configuration/standalone-full.xml EAP7_HOME/standalone/configuration

c. Navigieren Sie zum JBoss EAP 7 Installationsverzeichnis und starten Sie den Server mitdem Parameter --admin-only.

$ bin/standalone.sh -c standalone-full.xml --admin-only


15

ANMERKUNG

Sie werden die folgenden org.jboss.as.controller.management-operation Fehlermeldungen im Serverprotokoll sehen, wenn Sie denServer starten. Diese Fehler sind normal und zeigen an, dass dieKonfigurationen der alten Subsysteme entfernt oder auf JBoss EAP 7 migriertwerden müssen.

WFLYCTL0402: Untersysteme [cmp], die von der veralteten Erweiterung'org.jboss.as.cmp' bereitgestellt werden, werden von Servern dieserVersion nicht unterstützt. Sowohl das Untersystem als auch dieErweiterung müssen entfernt oder migriert werden, ehe der Serverfunktionieren kann.

WFLYCTL0402: Untersysteme [jacorb], die von der veraltetenErweiterung 'org.jboss.as.jacorb' bereitgestellt werden, werden vonServern dieser Version nicht unterstützt. Sowohl das Untersystem alsauch die Erweiterung müssen entfernt oder migriert werden, ehe derServer funktionieren kann.

WFLYCTL0402: Untersysteme [jaxr], die von der veralteten Erweiterung'org.jboss.as.jaxr' bereitgestellt werden, werden von Servern dieserVersion nicht unterstützt. Sowohl das Untersystem als auch dieErweiterung müssen entfernt oder migriert werden, ehe der Serverfunktionieren kann.

WFLYCTL0402: Untersysteme [messaging], die von der veraltetenErweiterung 'org.jboss.as.messaging' bereitgestellt werden, werden vonServern dieser Version nicht unterstützt. Sowohl das Untersystem alsauch die Erweiterung müssen entfernt oder migriert werden, ehe derServer funktionieren kann.

WFLYCTL0402: Untersysteme [threads], die von der veraltetenErweiterung 'org.jboss.as.threads' bereitgestellt werden, werden vonServern dieser Version nicht unterstützt. Sowohl das Untersystem alsauch die Erweiterung müssen entfernt oder migriert werden, ehe derServer funktionieren kann.

WFLYCTL0402: Untersysteme [web], die von der veralteten Erweiterung'org.jboss.as.web' bereitgestellt werden, werden von Servern dieserVersion nicht unterstützt. Sowohl das Untersystem als auch dieErweiterung müssen entfernt oder migriert werden, ehe der Serverfunktionieren kann.

3. Öffnen Sie ein neues Terminal, navigieren Sie zum JBoss EAP 7 Installationsverzeichnis undstarten Sie das Management-CLI mit den Parametern --controller=remote://localhost:9999.

$ bin/jboss-cli.sh --connect --controller=remote://localhost:9999

Migrieren der JacORB-, Messaging- und Web-Subsysteme

1. Um die Konfigurationsänderungen, die an den Subsystemen vorgenommen werden, vor derMigration zu überprüfen, führen Sie die Operation describe-migration aus.Die describe-migration-Operation verwendet die folgende Syntax.


16

/subsystem=SUBSYSTEM_NAME:describe-migration

Das folgende Beispiel beschreibt die Konfigurationsänderungen, die an der JBoss EAP 6.4 standalone-full.xml Konfigurationsdatei vorgenommen werden, wenn diese zu JBoss EAP7 migriert wird. Einige Einträge wurden zugunsten der Lesbarkeit und Platzersparnis aus derAusgabe entfernt.

Beispiel: describe-migration Operation

[standalone@localhost:9999 /] /subsystem=messaging:describe-migration{ "outcome" => "success", "result" => { "migration-warnings" => [], "migration-operations" => [ { "operation" => "add", "address" => [("extension" => "org.wildfly.extension.messaging-activemq")], "module" => "org.wildfly.extension.messaging-activemq" }, { "operation" => "add", "address" => [("subsystem" => "messaging-activemq")] },  { "operation" => "remove", "address" => [("subsystem" => "messaging")] }, { "operation" => "remove", "address" => [("extension" => "org.jboss.as.messaging")] } ] }}

2. Führen Sie die migrate-Operation aus, um die Subsystemkonfiguration zu dem Subsystem zumigrieren, das dieses in JBoss EAP 7 ersetzt. Die Operation verwendet die folgende Syntax.

/subsystem=SUBSYSTEM_NAME:migrate

ANMERKUNG

Die Operationen describe-migration und migrate des messaging-Subsystems ermöglichen Ihnen die Übergabe eines Parameters, um den Zugriffvon älteren Clients zu konfigurieren. Weitere Informationen über dieBefehlssyntax finden Sie unter Migration und Aufwärtskompatibilität desMessaging-Subsystems.


17

3. Überprüfen Sie die Ausgabe und das Ergebnis des Befehls. Vergewissern Sie sich, dass dieOperation erfolgreich abgeschlossen wurde und es keine »migration-warning«-Einträge gibt.Das bedeutet, dass die Migrationskonfiguration für das Subsystem vollständig ist.

Beispiel: Erfolgreiche migrate-Operation ohne Warnungen

[standalone@localhost:9999 /] /subsystem=messaging:migrate{ "outcome" => "success", "result" => {"migration-warnings" => []}}

Falls Sie »migration-warnings«-Einträge im Protokoll entdecken, bedeutet dies, dass dieMigration der Serverkonfiguration erfolgreich abgeschlossen wurde, jedoch nicht alle Elementeund Attribute migriert werden konnten. Sie müssen den Empfehlungen der »migration-warnings«folgen und zusätzliche Management-CLI-Befehle ausführen, um diese Konfigurationenanzupassen. Nachfolgend sehen Sie ein Beispiel für eine migrate-Operation, die »migration-warnings« ausgibt.

Beispiel: migrate-Operation mit Warnungen

[standalone@localhost:9999 /] /subsystem=messaging:migrate{ "outcome" => "success", "result" => {"migration-warnings" => [ "WFLYMSG0080: Could not migrate attribute group-address from resource [ (\"subsystem\" => \"messaging-activemq\"), (\"server\" => \"default\"), (\"broadcast-group\" => \"groupB\")]. Use instead the socket-binding attribute to configure this broadcast-group.", "WFLYMSG0080: Could not migrate attribute group-port from resource [ (\"subsystem\" => \"messaging-activemq\"), (\"server\" => \"default\"), (\"broadcast-group\" => \"groupB\")]. Use instead the socket-binding attribute to configure this broadcast-group.", "WFLYMSG0080: Could not migrate attribute local-bind-address from resource [ (\"subsystem\" => \"messaging-activemq\"), (\"server\" => \"default\"), (\"broadcast-group\" => \"groupA\")]. Use instead the socket-binding attribute to configure this broadcast-group.", "WFLYMSG0080: Could not migrate attribute local-bind-port from resource [ (\"subsystem\" => \"messaging-activemq\"), (\"server\" => \"default\"), (\"broadcast-group\" => \"groupA\")]. Use instead the socket-binding attribute to configure this broadcast-group.", "WFLYMSG0080: Could not migrate attribute group-address from resource [


18

(\"subsystem\" => \"messaging-activemq\"), (\"server\" => \"default\"), (\"broadcast-group\" => \"groupA\")]. Use instead the socket-binding attribute to configure this broadcast-group.", "WFLYMSG0080: Could not migrate attribute group-port from resource [ (\"subsystem\" => \"messaging-activemq\"), (\"server\" => \"default\"), (\"broadcast-group\" => \"groupA\")]. Use instead the socket-binding attribute to configure this broadcast-group." ]}}

ANMERKUNG

Die Liste der migrate- und describe-migration-Warnungen für jedesSubsystem finden Sie im Referenzmaterial am Ende dieses Handbuchs.

Warnungen der migration-Operation für das Jacorb-Subsystem

Warnungen der migration-Operation für das Messaging-Subsystem

Warnungen der migration-Operation für das Web-Subsystem

4. Überprüfen Sie die Serverkonfigurationsdatei, um zu verifizieren, dass die Erweiterung, dasSubsystem und der Namespace aktualisiert wurden und das vorhandene Subsystem zu JBossEAP 7 migriert wurde.

ANMERKUNG

Sie müssen diesen Vorgang für jedes der Subsysteme jacorb, messaging und web wiederholen, indem Sie die folgenden Befehle ausführen.

/subsystem=jacorb:migrate/subsystem=messaging:migrate/subsystem=web:migrate

5. Entfernen Sie die Subsysteme cmp, jaxr und threads und Erweiterungen aus derServerkonfiguration.Während Sie noch am Management-CLI-Prompt sind, entfernen Sie die obsoleten Subsysteme cmp, jaxr und threads, indem Sie die folgenden Befehle ausführen.

/subsystem=cmp:remove/extension=org.jboss.as.cmp:remove/subsystem=jaxr:remove/extension=org.jboss.as.jaxr:remove/subsystem=threads:remove/extension=org.jboss.as.threads:remove


19

WICHTIG

Sie müssen die Subsysteme messaging, jacorb und web migrieren und dieErweiterungen und Subsysteme cmp, jaxr und threads entfernen, bevor Sie denServer für den normalen Betrieb neu starten können. Falls Sie den Server neu startenmüssen, bevor Sie diesen Vorgang abgeschlossen haben, dann geben Sie denParameter --admin-only auf der Server-Startbefehlszeile an. Dies erlaubt es Ihnen,mit den Konfigurationsänderungen fortzufahren.

4.3. GEÄNDERTE PRÄFIXE FÜR PROTOKOLLEINTRÄGE

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 ProjectCodes Used in JBoss EAP in the JBoss EAP Development Guide.

4.4. ÄNDERUNGEN DER WEBSERVERKONFIGURATION

4.4.1. Ersetzen des Web-Subsystems durch Undertow

Undertow ersetzt JBoss Web als Webserver in JBoss EAP 7. Das bedeutet, dass die Konfiguration desalten web-Subsystems zur neuen JBoss EAP 7 undertow-Subsystemkonfiguration migriert werdenmuss.

Der Namespace urn:jboss:domain:web:2.2 der Subsystemkonfiguration in derServerkonfigurationsdatei wurde ersetzt durch den Namespace urn:jboss:domain:undertow:3.1.

Das Erweiterungsmodul org.jboss.as.web in EAP_HOME/modules/system/layers/base/ wurde ersetzt durch das Erweiterungsmodul org.wildfly.extension.undertow.

Sie können die migrate-Operation der Management-CLI zur Migration des web-Subsystems zu undertow in der Serverkonfigurationsdatei verwenden. Beachten Sie jedoch, dass diese Operationnicht dazu in der Lage ist, sämtliche Konfigurationen des JBoss Web-Subsystems zu migrieren. Falls Sie»migration-warning«-Einträge sehen, müssen Sie zusätzliche Management-CLI-Befehle ausführen, umdiese Konfigurationen zu Undertow zu migrieren. Weitere Informationen über die migrate-Operationder Management-CLI finden Sie unter migrate-Operation der Management-CLI.

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

Nachfolgend sehen Sie ein Beispiel der standardmäßigen Konfiguration für das undertow-Subsystem

<subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default-host" native="false"> <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/> <virtual-server name="default-host" enable-welcome-root="true"> <alias name="localhost"/> <alias name="example.com"/> </virtual-server></subsystem>


20

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/development-guide/#project_codes_used_in_eap

in JBoss EAP 6.

4.4.2. Migrieren von JBoss Web Rewrite-Bedingungen

Die migrate-Operation der Management-CLI ist nicht dazu in der Lage, automatisch »rewrite«-Bedingungen zu migrieren. Diese werden stattdessen als »migration-warnings« gemeldet und müssenmanuell migriert werden. Sie können eine äquivalente Konfiguration in JBoss EAP 7 erstellen, indem SiePrädikat-Attribute und Handler verwenden; für weitere Informationen diesbezüglich siehe UndertowPredicates Attributes and Handlers.

Nachfolgend sehen Sie ein Beispiel einer Konfiguration für das web-Subsystem in JBoss EAP 6, dieeine rewrite-Konfiguration beinhaltet.

<subsystem xmlns="urn:jboss:domain:undertow:3.1"> <buffer-cache name="default"/> <server name="default-server"> <http-listener name="default" socket-binding="http" redirect-socket="https"/> <host name="default-host" alias="localhost"> <location name="/" handler="welcome-content"/> <filter-ref name="server-header"/> <filter-ref name="x-powered-by-header"/> </host> </server> <servlet-container name="default"> <jsp-config/> <websockets/> </servlet-container> <handlers> <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/> </handlers> <filters> <response-header name="server-header" header-name="Server" header-value="JBoss-EAP/7"/> <response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow/1"/> </filters></subsystem>

<subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default" native="false"> <virtual-server name="default" enable-welcome-root="true"> <alias name="localhost"/> <rewrite name="test" pattern="(.*)/toberewritten/(.*)" substitution="$1/rewritten/$2" flags="NC"/> <rewrite name="test2" pattern="(.*)" substitution="-" flags="F"> <condition name="get" test="%{REQUEST_METHOD}" pattern="GET"/> <condition name="andCond" test="%{REQUEST_URI}" pattern=".*index.html" flags="NC"/> </rewrite> </virtual-server></subsystem>


21

http://undertow.io/undertow-docs/undertow-docs-1.2.0/index.html#predicates-attributes-and-handlers

Folgen Sie den Anweisungen unter migrate-Operation der Management-CLI, um Ihren Server und dieManagement-CLI zu starten, und migrieren Sie anschließend die Konfigurationsdatei für das web-Subsystem mithilfe des folgenden Befehls.

/subsystem=web:migrate

Die folgenden »migration-warnings« werden gemeldet, wenn Sie die migrate-Operation auf der obigenKonfiguration ausführen.

/subsystem=web:migrate{ "outcome" => "success", "result" => {"migration-warnings" => [ "WFLYWEB0002: Could not migrate resource { \"pattern\" => \"(.*)\", \"substitution\" => \"-\", \"flags\" => \"F\", \"operation\" => \"add\", \"address\" => [ (\"subsystem\" => \"web\"), (\"virtual-server\" => \"default-host\"), (\"rewrite\" => \"test2\") ]}", "WFLYWEB0002: Could not migrate resource { \"test\" => \"%{REQUEST_METHOD}\", \"pattern\" => \"GET\", \"flags\" => undefined, \"operation\" => \"add\", \"address\" => [ (\"subsystem\" => \"web\"), (\"virtual-server\" => \"default-host\"), (\"rewrite\" => \"test2\"), (\"condition\" => \"get\") ]}", "WFLYWEB0002: Could not migrate resource { \"test\" => \"%{REQUEST_URI}\", \"pattern\" => \".*index.html\", \"flags\" => \"NC\", \"operation\" => \"add\", \"address\" => [ (\"subsystem\" => \"web\"), (\"virtual-server\" => \"default-host\"), (\"rewrite\" => \"test2\"), (\"condition\" => \"andCond\") ]}" ]}}

Wenn Sie die Serverkonfigurationsdatei überprüfen, sehen Sie die folgende Konfiguration für das undertow-Subsystem.


22

ANMERKUNG

Die rewrite-Konfiguration wurde weggelassen.

Verwenden Sie die Management-CLI, um den Filter anzulegen, der die rewrite-Konfiguration im undertow-Subsystem ersetzen soll. Für jeden Befehl sollten Sie die Meldung »{"outcome" ⇒"success"}« erhalten.

# Create the filters/subsystem=undertow/configuration=filter/expression-filter="test1":add(expression="path('(.*)/toberewritten/(.*)') -> rewrite('$1/rewritten/$2')")/subsystem=undertow/configuration=filter/expression-filter="test2":add(expression="method('GET') and path('.*index.html') -> response-code(403)")

# Add the filters to the default server/subsystem=undertow/server=default-server/host=default-host/filter-ref="test1":add/subsystem=undertow/server=default-server/host=default-host/filter-ref="test2":add

Überprüfen Sie die aktualisierte Serverkonfigurationsdatei. Das JBoss Web-Subsystem ist nunvollständig migriert und im undertow-Subsystem konfiguriert.

<subsystem xmlns="urn:jboss:domain:undertow:3.1"> <buffer-cache name="default"/> <server name="default-server"> <http-listener name="http" socket-binding="http"/> <host name="default-host" alias="localhost, example.com"> <location name="/" handler="welcome-content"/> </host> </server> <servlet-container name="default"> <jsp-config/> </servlet-container> <handlers> <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/> </handlers> </subsystem>

<subsystem xmlns="urn:jboss:domain:undertow:3.1"> <buffer-cache name="default"/> <server name="default-server"> <http-listener name="http" socket-binding="http"/> <host name="default-host" alias="localhost, example.com"> <location name="/" handler="welcome-content"/> <filter-ref name="test1"/> <filter-ref name="test2"/> </host> </server> <servlet-container name="default"> <jsp-config/> </servlet-container>


23

For more information about how to configure filters and handlers using the management CLI, seeConfiguring the Web Server in the JBoss EAP 7 Configuration Guide.

4.4.3. Migrieren von JBoss Web Systemeigenschaften

In der vorherigen Release von JBoss EAP konnte mithilfe von Systemeigenschaften dasstandardmäßige Verhalten von JBoss Web verändert werden. Informationen darüber, wie Sie dasselbeVerhalten in Undertow konfigurieren können, finden Sie unter Übersicht über das Migrieren von JBossWeb Systemeigenschaften

4.4.4. Migrate JBoss Web jboss-web.xml Overlay

In JBoss EAP 6, JBoss Web supported the ability to specify additional static files for a web applicationusing the overlay element in the jboss-web.xml file. This feature did not actually overlay existingfiles, but instead added static files to a deployment outside of the WAR archive.

In the following jboss-web.xml file example, /tmp/mycontents/test.html was returned by theJBoss EAP 6 server when you accessed the URL http://localhost:8080/example/test.html.

Undertow, which replaces JBoss Web in JBoss EAP 7, does not support the jboss-web.xml file overlay feature.

4.4.5. Migrieren von globalen Valves

Frühere Versionen von JBoss EAP unterstützten Valves. Valves sind angepasste Klassen, die in dieanfrageverarbeitende Pipeline für eine Applikation vor Servlet-Filtern eingefügt werden, um Änderungenan der Anfrage durchzuführen oder zusätzliche Verarbeitungen durchzuführen.

Globale Valves werden in die anfrageverarbeitende Pipeline für alle bereitgestelltenApplikationen eingefügt und werden in der Serverkonfigurationsdatei konfiguriert.

Authenticator Valves authentifizieren die Berechtigungsnachweise der Anfrage.

Angepasste Applikations-Valves werden erstellt, indem die Klasse org.apache.catalina.valves.ValveBase erweitert und im Element <valve> derDeskriptorklasse jboss-web.xml konfiguriert wird. Diese Valves müssen manuell migriert

<handlers> <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/> </handlers> <filters> <expression-filter name="test1" expression="path('(.*)/toberewritten/(.*)') -> rewrite('$1/rewritten/$2')"/> <expression-filter name="test2" expression="method('GET') and path('.*index.html') -> response-code(403)"/> </filters></subsystem>

<jboss-web> <context-root>/example</context-root> <overlay>/tmp/mycontents/</overlay></jboss-web>


24

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/configuration-guide/#configuring_the_web_server_undertow

http://localhost:8080/example/test.html

werden.

Dieser Abschnitt beschreibt die Migration von globalen Valves. Die Migration von angepassten undAuthenticator Valves wird im Abschnitt Migrieren von angepassten Applikations-Valves diesesHandbuchs erläutert.

Undertow, das JBoss Web in JBoss EAP 7 ersetzt, unterstützt keine globalen Valves. Sie sollten jedocheine ähnliche Funktion erreichen können mithilfe von Undertow-Handlern. Undertow enthält eine Reihevon integrierten Handlern, die allgemeine Funktionen bereitstellen. Es bietet auch die Möglichkeit zurErstellung von angepassten Handlern, die als Ersatz für die Funktionen angepasster Valves dienenkönnen.

Falls Ihre Applikation Valves verwendet, müssen Sie diese durch den jeweiligen Undertow Handler-Codeersetzen, um dieselbe Funktionalität zu erreichen, wenn Sie zu JBoss EAP 7 migrieren.

For more information about how to configure handlers, see Configuring Handlers in the JBoss EAP 7Configuration Guide.

For more information about how to configure filters, see Configuring Filters in the JBoss EAP 7Configuration Guide.

Migrieren von JBoss Web ValvesDie folgende Tabelle führt die Valves auf, die in der vorherigen Release von JBoss EAP von JBoss Webbereitgestellt wurden, sowie die jeweiligen integrierten Handler in Undertow. Die JBoss Web Valvesbefinden sich im Paket org.apache.catalina.valves.

Tabelle 4.2. Zuordnung von Valves zu Handlern

Valve Handler

AccessLogValve io.undertow.server.handlers.accesslog.AccessLogHandler

CrawlerSessionManagerValve io.undertow.servlet.handlers.CrawlerSessionManagerHandler

ExtendedAccessLogValve io.undertow.server.handlers.accesslog.AccessLogHandler

JDBCAccessLogValve Siehe Manuelles Migrationsverfahren für JDBCAccessLogValve untenfür Anweisungen.

RemoteAddrValve io.undertow.server.handlers.IPAddressAccessControlHandler

RemoteHostValve io.undertow.server.handlers.AccessControlListHandler

RemoteIpValve io.undertow.server.handlers.ProxyPeerAddressHandler

RequestDumperValve io.undertow.server.handlers.RequestDumpingHandler

RewriteValve Siehe Migrieren von JBoss Web Rewrite-Bedingungen für Anweisungenzur manuellen Migration dieser Valves

StuckThreadDetectionValve io.undertow.server.handlers.StuckThreadDetectionHandler


25

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/configuration-guide/#undertow-configure-handlers

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/configuration-guide/#undertow-configure-filters

Sie können die migrate-Operation der Management-CLI verwenden, um automatisch globale Valveszu migrieren, welche die folgenden Kriterien erfüllen:

Sie beschränken sich auf die in der obigen Tabelle aufgeführten Valves, die keine manuelleVerarbeitung erfordern.

Sie müssen im web-Subsystem der Serverkonfigurationsdatei definiert sein.

Weitere Informationen über die migrate-Operation der Management-CLI finden Sie unter migrate-Operation der Management-CLI .

Manuelles Migrationsverfahren für JDBCAccessLogValveDie Valve org.apache.catalina.valves.JDBCAccessLogValve ist eine Ausnahme und kannnicht automatisch zu io.undertow.server.handlers.JDBCLogHandler migriert werden. FolgenSie den nachstehenden Anweisungen, um die folgende Beispiel-Valve zu migrieren.

1. Erstellen Sie ein Treibermodul für die Datenbank, welche die Protokolleinträge speichern soll.

2. Konfigurieren Sie die Datenquelle für die Datenbank und fügen Sie den Treiber zur Liste derverfügbaren Treiber im datasources-Subsystem hinzu.

3. Konfigurieren Sie einen expression-filter im undertow-Subsystem mit dem folgendenAusdruck: jdbc-access-log(datasource=DATASOURCE_JNDI_NAME).

<valve name="jdbc" module="org.jboss.as.web" class-name="org.apache.catalina.valves.JDBCAccessLogValve"> <param param-name="driverName" param-value="com.mysql.jdbc.Driver" /> <param param-name="connectionName" param-value="root" /> <param param-name="connectionPassword" param-value="password" /> <param param-name="connectionURL" param-value="jdbc:mysql://localhost:3306/wildfly?zeroDateTimeBehavior=convertToNull" /> <param param-name="format" param-value="combined" /></valve>

<datasources> <datasource jndi-name="java:jboss/datasources/accessLogDS" pool-name="accessLogDS" enabled="true" use-java-context="true"> <connection-url>jdbc:mysql://localhost:3306/wildfly?zeroDateTimeBehavior=convertToNull</connection-url> <driver>mysql</driver> <security> <user-name>root</user-name> <password>Password1!</password> </security> </datasource> ... <drivers> <driver name="mysql" module="com.mysql"> <driver-class>com.mysql.jdbc.Driver</driver-class> </driver> ... </drivers></datasources>


26

4.5. ÄNDERUNGEN DER JGROUPS-SERVERKONFIGURATION

4.5.1. Private Netzwerkschnittstelle als Standard in JGroups

In der Standardkonfiguration von JBoss EAP 6 verwendete JGroups die public-Schnittstelle, die imAbschnitt <interfaces> der Serverkonfigurationsdatei definiert war.

Da empfohlen wird, eine dedizierte Netzwerkschnittstelle zu nutzen, verwendet JGroups standardmäßignunmehr die neue private-Schnittstelle, die in JBoss EAP 7 im Abschnitt <interfaces> derServerkonfigurationsdatei definiert ist.

4.5.2. Änderungen der JGroups-Channels

JGroups bietet Unterstützung für Gruppenkommunikation von HA-Services in Form von JGroups-Channels. JBoss EAP 7 führt <channel>-Elemente zum jgroups-Subsystem in derServerkonfigurationsdatei ein. Mithilfe der Management-CLI können Sie die Konfiguration von JGroups-Channels hinzufügen, entfernen oder ändern.

For more information about how to configure JGroups, see Cluster Communication with JGroups in theJBoss EAP Configuration Guide.

4.6. ÄNDERUNGEN DER INFINISPAN-SERVERKONFIGURATION

4.6.1. Änderungen der standardmäßigen Infinispan-Cache-Konfiguration

In JBoss EAP 6, the default clustered caches for web session replication and EJB replication werereplicated ASYNC caches. This has changed in JBoss EAP 7. The default clustered caches are nowdistributed ASYNC caches. The replicated caches are no longer even configured by default. SeeConfigure the Cache Mode in the JBoss EAP Configuration Guide for information about how to add areplicated cache and make it the default.

Dies betrifft Sie nur, wenn Sie die neue Standardkonfiguration von JBoss EAP 7 verwenden. Falls Siedie Konfiguration von JBoss EAP 6 migrieren, bleibt die Konfiguration des infinispan-Subsystemserhalten.

4.6.2. Änderungen der Infinispan-Cache-Strategie

Das Verhalten der ASYNC-Cache-Strategie hat sich in JBoss EAP 7 geändert.

In JBoss EAP 6 erfolgten Lesevorgänge im ASYNC-Cache ohne Sperre. Obwohl dies nie ein Blockierenzur Folge hatte, war dieses Verhalten anfällig für das Lesen veralteter Daten, beispielsweise beimFailover, denn nachfolgende Anfragen für denselben Benutzer durften starten, bevor die vorherigeAnfrage abgeschlossen war. Diese Toleranz ist im verteilten Modus nicht akzeptabel, da Änderungen inder Cluster-Topologie Auswirkungen auf die Session-Affinität haben kann und leicht zu veralteten Datenführen kann.

<filters> <expression-filter name="jdbc-access" expression="jdbc-access-log(datasource='java:jboss/datasources/accessLogDS')" /> ...</filters>


27

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/configuration-guide/#cluster_communication_jgroups

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/configuration-guide/#configure_the_cache_mode

In JBoss EAP 7 erfordern Lesevorgänge im ASYNC-Cache Sperren. Da nun neue Anfragen vom selbenBenutzer gesperrt werden, bis die vorherige Replikation abgeschlossen ist, ist das Lesen veralteterDaten somit ausgeschlossen.

4.7. ÄNDERUNGEN DER EJB-SERVERKONFIGURATION

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

WICHTIG

Falls Sie das JBoss Server Migration Tool verwenden, um Ihre Serverkonfiguration zuaktualisieren, sollte das ejb3-Subsystem korrekt konfiguriert sein und es sollten keineProbleme beim Bereitstellen Ihrer EJB-Applikationen auftreten.

DuplicateServiceExceptionDie folgende DuplicateServiceException wird durch Änderungen beim Cache-Verhalten in JBossEAP 7 verursacht.

DuplicateServiceException im Serverprotokoll

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.

1. Folgen Sie den Anweisungen unter Starten des Servers und der Management-CLI.

2. Führen Sie die folgenden Befehle aus, um das Cache-Verhalten im ejb3-Subsystem neu zukonfigurieren.

/subsystem=ejb3/file-passivation-store=file:remove/subsystem=ejb3/cluster-passivation-store=infinispan:remove/subsystem=ejb3/passivation-store=infinispan:add(cache-container=ejb, max-size=10000)

/subsystem=ejb3/cache=passivating:remove/subsystem=ejb3/cache=clustered:remove/subsystem=ejb3/cache=distributable:add(passivation-store=infinispan, aliases=[passivating, clustered])

4.8. ÄNDERUNGEN DER MESSAGING-SERVERKONFIGURATION

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


28

4.8.1. Änderungen der Messaging-Subsystem-Serverkonfiguration

Die Modulerweiterung org.jboss.as.messaging in EAP_HOME/modules/system/layers/base/wurde ersetzt durch das Erweiterungsmodul org.wildfly.extension.messaging-activemq.

Der Namespace urn:jboss:domain:web:2.2 der Subsystemkonfiguration wurde ersetzt durch denNamespace urn:jboss:domain:messaging-activemq:1.0.

Management-ModellIn den meisten Fällen wurde versucht, die Element- und Attributnamen möglichst unverändert zu jenender vorherigen Releases zu halten. Die folgende Tabelle zeigt einige der Änderungen.

Tabelle 4.3. Zuordnung der Messaging-Attribute

HornetQ-Name ActiveMQ-Name

hornetq-server server

hornetq-serverType serverType

connectors connector

discovery-group-name discovery-group

Die Management-Operationen, die auf dem neuen messaging-activemq-Subsystem aufgerufenwerden, haben sich geändert von /subsystem=messaging/hornetq-server= zu /subsystem=messaging-activemq/server=.

Sie können eine vorhandene JBoss EAP 6 messaging-Subsystemkonfiguration zum messaging-activemq-Subsystem auf einem JBoss EAP 7 Server migrieren, indem Sie dessen migrate-Operationausführen.

/subsystem=messaging:migrate

Before you execute the migrate operation, you can invoke the describe-migration operation toreview the list of management operations that will be performed to migrate from the existing JBoss EAP 6messaging subsystem configuration to the messaging-activemq subsystem on the JBoss EAP 7server.

/subsystem=messaging:describe-migration

Die Operationen migrate und describe-migration zeigen auch eine Liste mit migration-warnings für Ressourcen oder Attribute an, die nicht automatisch migriert werden können.

Migration und Aufwärtskompatibilität des Messaging-SubsystemsDie Operationen describe-migration und migrate für das messaging-Subsystem bieten einenzusätzlichen Konfigurationsparameter. Falls Sie das Messaging so konfigurieren möchten, dass alteJBoss EAP 6 Clients sich mit dem JBoss EAP 7 Server verbinden dürfen, können Sie die boolescheVariable add-legacy-entries wie folgt den Operationen describe-migration oder migratehinzufügen.


29

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

Falls die boolesche Variable add-legacy-entries auf true gesetzt ist, erstellt das messaging-activemq-Subsystem die Ressource legacy-connection-factory und fügt legacy-entries zuden Ressourcen jms-queue und jms-topic hinzu.

Falls die boolesche Variable add-legacy-entries auf false gesetzt ist, werden keine altenRessourcen im messaging-activemq-Subsystem erstellt, weshalb alte JMS-Clients nicht mit denJBoss EAP 7 Servern kommunizieren werden können. Dies ist der Standardwert.

For more information about forward and backward compatibility see the Backward and ForwardCompatibility in Configuring Messaging for JBoss EAP.

Weitere Informationen über die Operationen migrate und describe-migration der Management-CLI finden Sie unter migrate-Operation der Management-CLI .

Geändertes Verhalten des forward-when-no-consumers AttributsDas Verhalten des Attributs forward-when-no-consumers hat sich in JBoss EAP 7 geändert.

Wenn forward-when-no-consumers in JBoss EAP 6 auf false gesetzt war und keine Verbraucherim Cluster vorhanden waren, dann wurden Nachrichten auf alle Knoten in einem Cluster weiterverteilt.

Dieses Verhalten hat sich in JBoss EAP 7 geändert. Wenn forward-when-no-consumers auf falsegesetzt ist und keine Verbraucher im Cluster vorhanden sind, dann werden Nachrichten nichtweiterverteilt. Stattdessen verbleiben die Nachrichten auf dem Knoten, an den sie gesendet wurden.

Änderungen der Messaging-Subsystem-XML-KonfigurationDie XML-Konfiguration hat sich mit dem neuen messaging-activemq-Subsystem grundlegendgeändert und bietet nun ein XML-Schema, das eher im Einklang mit anderen JBoss EAP Subsystemensteht.

It is strongly advised that you do not attempt to modify the JBoss EAP messaging subsystem XMLconfiguration to conform to the new messaging-activemq subsystem. Instead, invoke the legacysubsystem migrate operation. This operation will write the XML configuration of the new messaging-activemq subsystem as a part of its execution.

4.8.2. Migrieren von Messaging-Daten

Aufgrund des Wechsels von HornetQ zu ActiveMQ Artemis als JMS-Support-Provider haben sichsowohl das Format als auch der Speicherort für die Messaging-Daten in JBoss EAP 7 geändert.

Sie können eine der beiden folgenden Herangehensweisen wählen, um die Daten zu migrieren:

Sie können die HornetQ Messaging Daten aus der vorherigen Release exportieren und mittelsder import-journal-Operation der Management-CLI importieren. Siehe Migrieren vonMessaging-Daten mittels Export und Import für weitere Informationen.

Sie können die Daten der vorherigen Release migrieren, indem Sie eine JMS-Bridgekonfigurieren. Dieser Prozess wird in Migrieren von Messaging-Daten mittels JMS-Bridgebeschrieben.

Unter Zuordnung der Messaging-Verzeichnisnamen finden Sie Details über die Änderungen an denVerzeichnisnamen für Messaging-Daten zwischen den Releases.


30

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/configuring-messaging/#messaging_forward_and_backward_compatiblity

4.8.2.1. Migrieren von Messaging-Daten mittels Export und Import

Bei dieser Herangehensweise exportieren Sie die Daten der vorherigen Release mittels HornetQ exporter-Dienstprogramm. Anschließend importieren Sie die als XML formatierte Ausgabedateimittels import-journal-Operation.

WARNUNG

Derzeit gibt es ein bekanntes Problem bei dieser Herangehensweise. Den aktuellenStatus dieses Problems können Sie unter JBEAP-4407 - Consumer crashes withIndexOutOfBoundsException when reading large messages from imported journaleinsehen.

Exportieren der Messaging-Daten der vorherigen Release

WICHTIG

Der JBoss EAP 6 Server muss angehalten werden, bevor Sie die Messaging-Datenexportieren.

Das HornetQ exporter-Dienstprogramm generiert und exportiert die Messaging-Daten von JBoss EAP6 in eine XML-formatierte Datei. Für diesen Befehl müssen Sie die Pfade zu den erforderlichen HornetQJARs angeben, die in JBoss EAP 6 enthalten sind, diese Pfade dann an die Ordner messagingbindings/, messagingjournal/, messagingpaging/ und messaginglargemessages/ der vorherigen Release als Parameter übergeben, und schließlich eineAusgabedatei angeben, in welche die exportierten XML-Daten geschrieben werden sollen.

Nachfolgend sehen Sie die Syntax für das HornetQ exporter-Dienstprogramm.

Erstellen Sie ein angepasstes Modul, um sicherzustellen, dass die richtigen Versionen der HornetQJARs – einschließlich jeglicher JARs, die im Rahmen von Patches oder Upgrades installiert wurden –geladen und an das exporter-Dienstprogramm übergeben werden. Verwenden Sie einen TexteditorIhrer Wahl, um eine neue module.xml-Datei im Verzeichnis EAP6_HOME/modules/org/hornetq/exporter/main/ zu erstellen, und kopieren Sie denfolgenden Inhalt:

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>


31

https://issues.jboss.org/browse/JBEAP-4407

ANMERKUNG

Das angepasste Modul wird im Verzeichnis modules/ erstellt, nicht im Verzeichnis modules/system/layers/base/.

Folgen Sie den nachstehenden Schritten, um die Daten zu exportieren.

1. Stoppen Sie den JBoss EAP 6 Server.

2. Erstellen Sie das angepasste Modul wie oben beschrieben.

3. Führen Sie den folgenden Befehl aus, um die Daten zu exportieren.

$ java -jar jboss-modules.jar -mp modules/ org.hornetq.exporter standalone/data/messagingbindings/ standalone/data/messagingjournal/ standalone/data/messagingpaging standalone/data/messaginglargemessages/ > OUTPUT_DIRECTORY/OldMessagingData.xml

4. Vergewissern Sie sich, dass nach Abschluss des Befehls keine Fehler- oder Warnmeldungenim Protokoll verzeichnet wurden.

5. Verwenden Sie ein Hilfsprogramm für Ihr Betriebssystem, um das XML in der generiertenAusgabedatei zu validieren.

Importieren der XML-formatierten Messaging-DatenImportieren Sie anschließend die als XML formatierte Ausgabedatei wie folgt mittels der import-journal-Operation.

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

4.8.2.2. Migrieren von Messaging-Daten mittels JMS-Bridge

Bei dieser Herangehensweise konfigurieren und implementieren Sie eine JMS-Bridge zum JBoss EAP 7Server, die Nachrichten von der JBoss EAP 6 HornetQ Warteschlange in die JBoss EAP 7 ActiveMQArtemis Warteschlange verschiebt.

Eine JMS-Bridge liest Nachrichten von einer Quell-JMS-Warteschlange oder -Topic und schickt sie aneine Ziel-JMS-Warteschlange oder -Topic, die üblicherweise auf einem anderen Server sind. Dies kanndazu verwendet werden, um Meldungen zwischen beliebigen JMS-Server zu überbrücken, sofern dieseJMS 1.1 kompatibel sind. Quell- und Ziel-JMS-Ressourcen können über JNDI gesucht werden und dieClientklassen für das JNDI-Lookup müssen in einem Modul zusammengefasst sein. Der Modulnamewird dann in der JMS-Bridgekonfiguration deklariert.

Dieser Abschnitt beschreibt, wie Sie die Server konfigurieren und eine JMS-Bridge implementieren, umdie Messaging-Daten von JBoss EAP 6 nach JBoss EAP 7 zu übertragen.

Konfigurieren des JBoss EAP 6 Servers

<module name="org.hornetq"/> </dependencies></module>


32

1. Stoppen Sie den JBoss EAP 6 Server.

2. Sichern Sie das Journal und die Konfigurationsdateien von HornetQ.

Standardmäßig befindet sich das HornetQ-Journal im Verzeichnis EAP6_HOME/standalone/data/.

Unter Mapping Messaging Folder Names finden Sie die standardmäßigen Speicherorte derMessaging-Verzeichnisse für jede Release.

3. Vergewissern Sie sich, dass die InQueue JMS-Warteschlange, die die JMS-Nachrichtenenthält, auf dem JBoss EAP 6 Server definiert ist.

4. Vergewissern Sie sich, dass die messaging-Subsystemkonfiguration einen Eintrag für RemoteConnectionFactory enthält ähnlich dem folgenden:

Falls sie diesen Eintrag nicht enthält, erstellen Sie ihn mit dem folgenden Management-CLI-Befehl:

/subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:add(factory-type=XA_GENERIC, connector=[netty], entries=[java:jboss/exported/jms/RemoteConnectionFactory],ha=true,block-on-acknowledge=true,retry-interval=1000,retry-interval-multiplier=1.0,reconnect-attempts=-1)

Konfigurieren des JBoss EAP 7 Servers

1. Die JMS-Bridgekonfiguration benötigt das org.hornetq-Modul, um mit dem HornetQ-Serverder vorherigen Release zu verbinden. Dieses Modul und dessen direkte Abhängigkeitenexistieren nicht in JBoss EAP 7, weshalb Sie die folgenden Module aus der vorherigen Releasekopieren müssen.

Kopieren Sie das org.hornetq-Modul in das JBoss EAP 7 Verzeichnis EAP_HOME/modules/org/.

Falls Sie keine Patches auf diesem Modul angewendet haben, kopieren Sie diesesVerzeichnis vom JBoss EAP 6.4 Server: EAP6_HOME/modules/system/layers/base/org/hornetq/

Falls Sie Patches auf diesem Modul angewendet haben, kopieren Sie diesesVerzeichnis vom JBoss EAP 6.4 Server: EAP6_HOME/modules/system/layers/base/.overlays/layer-base-jboss-eap-6.4.x.CP/org/hornetq/

Entfernen Sie das <resource-root> für den HornetQ lib-Pfad aus der JBoss EAP 7 EAP_HOME/modules/org/hornetq/main/module.xml-Datei.

<connection-factory name="RemoteConnectionFactory"> <entries> <entry name="java:jboss/exported/jms/RemoteConnectionFactory"/> </entries> ...</connection-factory>


33

Falls Sie keine Patches auf das JBoss EAP 6.4 org.hornetq-Modul angewendethaben, entfernen Sie die folgende Zeile aus der Datei:

Falls Sie Patches auf das JBoss EAP 6.4 org.hornetq-Modul angewendet haben,entfernen Sie die folgenden Zeilen aus der Datei:

WARNUNG

Wenn Sie den HornetQ lib-Pfad resource-root nichtentfernen, wird die Bridge fehlschlagen mit der folgendenFehlermeldung in der Protokolldatei.

2016-07-15 09:32:25,660 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([ ("subsystem" => "messaging-activemq"), ("jms-bridge" => "myBridge")]) - failure description: "WFLYMSGAMQ0086: Unable to load module org.hornetq"

Kopieren Sie das org.jboss.netty-Modul in das JBoss EAP 7 Verzeichnis EAP_HOME/modules/org/jboss/.

Falls Sie keine Patches auf diesem Modul angewendet haben, kopieren Sie diesesVerzeichnis vom JBoss EAP 6.4 Server: EAP6_HOME/modules/system/layers/base/org/jboss/netty/

Falls Sie Patches auf diesem Modul angewendet haben, kopieren Sie diesesVerzeichnis vom JBoss EAP 6.4 Server: EAP6_HOME/modules/system/layers/base/.overlays/layer-base-jboss-eap-6.4.x.CP/org/jboss/netty

2. Erstellen Sie die JMS-Warteschlange, welche die Nachrichten vom JBoss EAP 6 Serverenthalten soll. Nachfolgend sehen Sie ein Beispiel für ein Management-CLI-Befehl, der dieJMS-Warteschlange MigratedMessagesQueue zum Empfang der Nachrichten erstellt.

jms-queue add --queue-address=MigratedMessagesQueue --entries=[jms/queue/MigratedMessagesQueue java:jboss/exported/jms/queue/MigratedMessagesQueue]

Dies erstellt die folgende jms-queue-Konfiguration für den Standardserver im messaging-activemq-Subsystem des JBoss EAP 7 Servers.

<resource-root path="lib"/>

<resource-root path="lib"/><resource-root path="../../../../../org/hornetq/main/lib"/>


34

3. Vergewissern Sie sich, dass das messaging-activemq-Subsystem default-Server eineKonfiguration für InVmConnectionFactory connection-factory ähnlich der folgendenenthält:

Falls sie diesen Eintrag nicht enthält, erstellen Sie ihn mit dem folgenden Management-CLI-Befehl:

/subsystem=messaging-activemq/server=default/connection-factory=InVmConnectionFactory:add(factory-type=XA_GENERIC, connectors=[in-vm], entries=[java:/ConnectionFactory])

4. Erstellen und implementieren Sie eine JMS-Bridge, die Nachrichten von der JMS-Warteschlange InQueue liest, die auf dem JBoss EAP 6 Server konfiguriert ist, und diese an dieWarteschlange MigratedMessagesQueue überträgt, die auf dem JBoss EAP 7 Serverkonfiguriert ist.

/subsystem=messaging-activemq/jms-bridge=myBridge:add(add-messageID-in-header=true,max-batch-time=100,max-batch-size=10,max-retries=-1,failure-retry-interval=1000,quality-of-service=AT_MOST_ONCE,module=org.hornetq,source-destination=jms/queue/InQueue,source-connection-factory=jms/RemoteConnectionFactory,source-context=[("java.naming.factory.initial"=>"org.jboss.naming.remote.client.InitialContextFactory"),("java.naming.provider.url"=>"remote://127.0.0.1:4447")],target-destination=jms/queue/MigratedMessagesQueue,target-connection-factory=java:/ConnectionFactory)

Dies erstellt die folgende jms-bridge-Konfiguration im messaging-activemq-Subsystemdes JBoss EAP 7 Servers.

<jms-queue name="MigratedMessagesQueue" entries="jms/queue/MigratedMessagesQueue java:jboss/exported/jms/queue/MigratedMessagesQueue"/>

<connection-factory name="InVmConnectionFactory" factory-type="XA_GENERIC" entries="java:/ConnectionFactory" connectors="in-vm"/>

<jms-bridge name="myBridge" add-messageID-in-header="true" max-batch-time="100" max-batch-size="10" max-retries="-1" failure-retry-interval="1000" quality-of-service="AT_MOST_ONCE" module="org.hornetq"> <source destination="jms/queue/InQueue" connection-factory="jms/RemoteConnectionFactory"> <source-context> <property name="java.naming.factory.initial" value="org.jboss.naming.remote.client.InitialContextFactory"/> <property name="java.naming.provider.url" value="remote://127.0.0.1:4447"/> </source-context> </source>


35

5. Falls für JBoss EAP 6 die Sicherheit konfiguriert ist, müssen Sie die JMS-Bridgekonfigurationmit einem <source>-Element konfigurieren, das einen source-context enthält, der diekorrekten Werte für Benutzernamen und Password festlegt, die für den JNDI-Lookup bei derVerbindungsherstellung verwendet werden.

Migrieren der Daten

1. Überprüfen Sie, ob Ihre Angaben für die folgenden Konfigurationen richtig sind.

Alle Warteschlangen- und Topic-Namen

Die java.naming.provider.url für den JNDI-Lookup

2. Vergewissern Sie sich, dass Sie das JMS-Ziel auf dem JBoss EAP 7 Server implementierthaben.

3. Starten Sie sowohl den JBoss EAP 6 als auch den JBoss EAP 7 Server.

4.8.2.3. Zuordnung der Messaging-Verzeichnisnamen

Die folgende Tabelle führt die Messaging-Verzeichnisnamen auf, die in der vorherigen Releaseverwendet wurden, sowie die zugehörigen Namen, die in der aktuellen Release von JBoss EAPverwendet werden. Die Verzeichnisse sind relativ zum Verzeichnis jboss.server.data.dir, dasstandardmäßig EAP_HOME/standalone/data/ lautet, sofern nicht anders festgelegt.

JBoss EAP 6 Verzeichnisname JBoss EAP 7 Verzeichnisname

messagingbindings/ activemq/bindings/

messagingjournal/ activemq/journal/

messaginglargemessages/ activemq/largemessages/

messagingpaging/ activemq/paging/

ANMERKUNG

The messaginglargemessages/ and messagingpaging/ directories might not bepresent if there are no large messages or if paging is disabled.

4.8.3. Migrieren von JMS-Zielen

In vorherigen Releases von JBoss EAP wurden JMS-Zielwarteschlangen im <jms-destinations>-Element unter dem <hornetq-server>-Element im messaging-Subsystem konfiguriert.

<target destination="jms/queue/MigratedMessagesQueue" connection-factory="java:/ConnectionFactory"/></jms-bridge>

<hornetq-server> ... <jms-destinations>


36

In JBoss EAP 7 wird die JMS-Zielwarteschlange im standardmäßigen <server>-Element des messaging-activemq-Subsystems konfiguriert.

4.8.4. Migrieren von Messaging-Interzeptoren

Messaging-Interzeptoren haben sich in JBoss EAP 7 grundlegend geändert, da HornetQ durchActiveMQ Artemis als JMS Messaging Provider ersetzt wurde.

Um beim HornetQ messaging-Subsystem, das in der vorherigen Release von JBoss EAP enthaltenwar, HornetQ-Interzeptoren zu installieren, mussten Sie diese einem JAR hinzufügen und dann dieHornetQ module.xml-Datei bearbeiten.

The messaging-activemq subsystem included in JBoss EAP 7 does not require modification of a module.xml file. User interceptor classes, which now implement the Apache ActiveMQ ArtemisInterceptor interface, can now be loaded from any server module. You specify the module from which theinterceptor should be loaded in the messaging-activemq subsystem of the server configuration file.

Beispiel-Interzeptor-Konfiguration

4.8.5. Ersetzen der Netty-Servlet-Konfiguration

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


37

https://activemq.apache.org/artemis/docs/javadocs/javadoc-1.2.0/org/apache/activemq/artemis/api/core/Interceptor.html

In JBoss EAP 6 konnten Sie eine Servlet-Engine für die Arbeit mit dem Netty-Servlet-Transportkonfigurieren. Da ActiveMQ Artemis nun HornetQ als integrierten Messaging-Provider in JBoss EAP 7ersetzt, steht diese Konfiguration nicht mehr zur Verfügung. Sie müssen die Servlet-Konfiguration durchdie neuen integrierten http-Connectors und http-Acceptors ersetzen.

4.9. JMX MANAGEMENT CHANGES

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

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

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

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

// 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(); }}

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


38

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

1. Connect to the JConsole using the following command.

EAP_HOME/bin/jconsole.sh

2. Connect to JBoss EAP local process. Note that it should start with "jboss-modules.jar".

3. In the MBeans tab, choose jboss.as → messaging-activemq → default → Operations todisplay the list of method names and attributes.

4.10. ÄNDERUNGEN DER ORB-SERVERKONFIGURATION

Die JacORB-Implementierung wurde in JBoss EAP 7 ersetzt durch eine Downstream-Version vonOpenJDK 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 derServerkonfigurationsdatei 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 inJBoss EAP 6.

// 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(); }}

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


39

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

Die neue iiop-openjdk-Subsystemkonfiguration akzeptiert nur eine Untergruppe der bisherigenElemente 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:

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

Tabelle 4.4. Zu entfernende Parameter

Element Nicht unterstützte Parameter

</orb></subsystem>

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

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


40

<orb>client-timeout

max-managed-buf-size

max-server-connections

outbuf-cache-timeout

outbuf-size

connection retries

retry-interval

name

server-timeout

<poa>queue-min

queue-max

pool-size

max-threads

Element Nicht unterstützte Parameter

Die folgenden on/off-Parameter werden nicht mehr unterstützt und werden nicht migriert, wenn Sie diemigrate-Operation der Management-CLI ausführen. Falls diese auf on gesetzt sind, erhalten Sie eineMigrationswarnung. 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 erfolgreichmigriert werden. Der einzige Unterschied besteht darin, dass deren Werte von on/off auf true/false geändert werden.

Tabelle 4.5. Zu deaktivierende oder zu entfernende Parameter

Element Auf »off« zu setzende Parameter

<orb>cache-poa-names

cache-typecodes

print-version

use-bom

use-imr


41

<interop> (alle außer sun)

comet

iona

chunk-custom-rmi-valuetypes

indirection-encoding-disable

lax-boolean-encoding

strict-check-on-tc-creation

<poa/>monitoring

queue-wait

Element Auf »off« zu setzende Parameter

4.11. MIGRIEREN DER THREADS-SUBSYSTEMKONFIGURATION

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 jedesSubsystem für die Verwaltung seines eigenen Thread-Pools verantwortlich.

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

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

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

For information about about changes to thread pool configuration in the remoting subsystem, seeMigrate the Remoting Subsystem Configuration in this guide, and Configuring the Endpoint in the JBossEAP Configuration Guide.

4.12. MIGRIEREN DER REMOTING-SUBSYSTEMKONFIGURATION

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.


42

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/configuration-guide/#configure_infinispan_thread_pools

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/configuration-guide/#configure_jgroups_thread_pools

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/configuration-guide/#configuring_the_io_subsystem

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/configuration-guide/#remoting_configure_endpoint

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 EAPConfiguration Guide.

4.13. ÄNDERUNGEN DER WEBSOCKET-SERVERKONFIGURATION

Um WebSockets in JBoss EAP 6 zu verwenden, mussten Sie das nicht blockierende Java NIO2Connector-Protokoll für den http-Connector im web-Subsystem der JBoss EAPServerkonfigurationsdatei 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ützungkonfigurieren oder die Applikation zu deren Verwendung einstellen. WebSockets sind eineVoraussetzung der Java EE 7 Spezifikation und die erforderlichen Protokolle werden standardmäßigkonfiguriert. Komplexere WebSocket-Konfigurationen erfolgen im servlet-container des undertow-Subsystems in der JBoss EAP Serverkonfigurationsdatei. Mithilfe des folgenden Befehlskö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.

4.14. ÄNDERUNGEN DES SINGLE SIGN-ON SERVERS

The infinispan subsystem still provides distributed caching support for HA services in the form ofInfinispan caches in JBoss EAP 7; however the caching and distribution of authentication information ishandled 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-Profilausfü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


43

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/configuration-guide/#remoting_configure_endpoint

den Host. JBoss EAP handhabt die Übertragung der jeweiligen Cache-Daten auf alle Hosts. In JBossEAP 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.

4.15. ÄNDERUNGEN DER DATASOURCE-KONFIGURATION

4.15.1. JBDC-Datasource-Treibername

Bei der Konfiguration einer Datasource in der vorherigen Release von JBoss EAP hing der Wert für denTreibernamen von der Anzahl der Klassen in der Datei META-INF/services/java.sql.Driver ab,die im JDBC-Treiber-JAR enthalten war.

Treiber mit einer einzelnen KlasseFalls die Datei META-INF/services/java.sql.Driver nur eine einzige Klasse spezifizierte, dannwar der Wert für den Treibernamen einfach der Name des JDBC-Treiber-JARs. Dies hat sich in JBossEAP 7 nicht geändert.

Treiber mit mehreren KlassenFalls in JBoss EAP 6 mehr als eine Klasse in der Datei META-INF/services/java.sql.Driveraufgeführt war, dann gaben Sie an, bei welcher Klasse es sich um die Treiberklasse handelte, indem Siederen Namen sowie die Haupt- und Nebenversion im folgenden Format an den JAR-Namen anfügten:

JAR_NAME + DRIVER_CLASS_NAME + "_" + MAJOR_VERSION + "_" + MINOR_VERSION

In JBoss EAP 7 wurde dies geändert. Sie geben den Treibernamen nun im folgenden Format an:

JAR_NAME + "_" + DRIVER_CLASS_NAME + "_" + MAJOR_VERSION + "_" + MINOR_VERSION

ANMERKUNG

Ein Unterstrich wurde zwischen JAR_NAME und DRIVER_CLASS_NAME hinzugefügt.

Der MySQL 5.1.31 JDBC-Treiber ist ein Beispiel für einen Treiber, der zwei Klassen enthält. Der Nameder Treiberklasse lautet com.mysql.jdbc.Driver. Die folgenden Beispiele veranschaulichen dieUnterschiede in der Art und Weise, wie Sie den Treibernamen in der vorherigen Release von JBossEAP im Vergleich zur aktuellen Release angeben.

Beispiel für JBoss EAP 6 Treibername

mysql-connector-java-5.1.31-bin.jarcom.mysql.jdbc.Driver_5_1

Beispiel für JBoss EAP 7 Treibername

mysql-connector-java-5.1.31-bin.jar_com.mysql.jdbc.Driver_5_1

4.16. SICHERHEITSRELEVANTE SERVER-KONFIGURATIONSÄNDERUNGEN


44

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

4.17. ÄNDERUNGEN AM TRANSAKTIONSSUBSYSTEM

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

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

Parameter in JBoss EAP 6 Ersatz in JBoss EAP 7

path object-store-path

relative-to object-store-relative-to

Veraltete Parameter des TransaktionssubsystemsThe following attributes that were available in the transactions subsystem in JBoss EAP 6 aredeprecated in JBoss EAP 7. The deprecated attributes might be removed in a future release of theproduct. The following table lists the equivalent replacement attributes.

Parameter in JBoss EAP 6 Ersatz in JBoss EAP 7

use-hornetq-store use-journal-store

hornetq-store-enable-async-io-to journal-store-enable-async-io

enable-statistics statistics-enabled

4.18. ÄNDERUNGEN DER MOD_CLUSTER KONFIGURATION

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 einekommagetrennte Liste der httpd-Proxy-Adressen handelte, die im Format hostname:port angegebenwurden.

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 formod_cluster. For information about how to disable advertising for mod_cluster, see Disable Advertisingfor mod_cluster in the JBoss EAP Configuration Guide.

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


45

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/how-to-configure-server-security/#java-security-manager-migration-considerations

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/configuration-guide/#disable_advertising_mod_cluster

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/configuration-guide/#mod_cluster-reference

KAPITEL 5. ÄNDERUNGEN BEI APPLIKATIONSMIGRATION

5.1. ÄNDERUNGEN DER WEBSERVICES-APPLIKATION

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

5.1.1. Änderungen der JAX-RPC-Unterstützung

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

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

Das Vorhandensein einer JAX-RPC Mapping-Datei – eine XML-Datei mit dem Root-Element <java-wsdl-mapping>.

Das Vorhandensein einer webservices.xml XML-Deskriptordatei, die ein <webservice-description>-Element enthält, das ein <jaxrpc-mapping-file>-Unterelement enthält.Nachfolgend sehen Sie ein Beispiel für eine webservices.xml-Deskriptordatei, die einenJAX-RPC Webservice definiert.

Das Vorhandensein einer ejb-jar.xml-Datei, die ein <service-ref> enthält, das eine JAX-RPC Mapping-Datei referenziert.

5.1.2. Änderungen der Apache CXF Spring Webservices

In früheren Releases von JBoss EAP konnten Sie die Integration von JBossWS und Apache CXFanpassen, indem Sie eine jbossws-cxf.xml-Konfigurationsdatei im Endpunkt-Deployment-Archiv

<webservices xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://www.ibm.com/webservices/xsd/j2ee_web_services_1_1.xsd" version="1.1"> <webservice-description> <webservice-description-name>HelloService</webservice-description-name> <wsdl-file>WEB-INF/wsdl/HelloService.wsdl</wsdl-file> <jaxrpc-mapping-file>WEB-INF/mapping.xml</jaxrpc-mapping-file> <port-component> <port-component-name>Hello</port-component-name> <wsdl-port>HelloPort</wsdl-port> <service-endpoint-interface>org.jboss.chap12.hello.Hello</service-endpoint-interface> <service-impl-bean> <servlet-link>HelloWorldServlet</servlet-link> </service-impl-bean> </port-component> </webservice-description></webservices>


46

http://cxf.apache.org/docs/30-migration-guide.html

http://ws.apache.org/wss4j/

http://santuario.apache.org/

https://jax-ws.java.net/nonav/jaxws-api/2.2/index.html

implementierten. Ein Anwendungsfall hierfür war die Konfiguration von Interzeptor-Ketten fürWebservice-Client- und -Server-Endpunkte auf dem Apache CXF-Bus. Diese Integration erfordert, dassSpring 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 dieangepasste Konfiguration in dieser Datei zu ersetzen. Zwar ist es weiterhin möglich, direkt auf dieApache CXF-API zuzugreifen, seien Sie sich jedoch bewusst, dass die Applikation nicht portierbar seinwird.

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

Apache CXF-InterzeptorenDer JBossWS-Deskriptor bietet neue Konfigurationsoptionen, die es Ihnen ermöglichen, dieInterzeptoren zu deklarieren, ohne den Client-Endpunkt-Code zu ändern. Stattdessen deklarieren SieInterzeptoren innerhalb der vordefinierten Client- und Endpunkt-Konfigurationen, indem Sie eine Listevon 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 Interzeptorenmithilfe dieser Eigenschaften deklariert.

Apache CXF-FeaturesDer JBossWS-Deskriptor ermöglicht es Ihnen, Features innerhalb von vordefinierten Client- undEndpunktkonfigurationen 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 Featuremithilfe 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>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>


47

Apache CXF HTTP-TransportIn 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 ApacheCXF-API wie folgt.

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

Eigenschaft Typ Beschreibung

cxf.client.allowChunking BoolescheVariable

Legt fest, ob die Anfragen unter Verwendung von Chunkinggesendet werden sollen.

cxf.client.chunkingThreshold Integer Legt den Grenzwert fest, an dem von Nicht-Chunking- aufChunking-Modus gewechselt werden soll.

cxf.client.connectionTimeout Long Legt die Anzahl der Millisekunden für die Zeitüberschreitungder Verbindung fest.

cxf.client.receiveTimeout Long Legt die Anzahl der Millisekunden für die Zeitüberschreitungbeim Empfang fest.

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


48

cxf.client.connection Zeichenkette

Legt fest, ob der Verbindungstyp Keep-Alive oder closegenutzt werden soll.

cxf.tls-client.disableCNCheck BoolescheVariable

Legt fest, ob die CN-Hostnamen-Prüfung deaktiviert werdensoll.

Eigenschaft Typ Beschreibung

5.1.3. Änderungen der WS-Security

Falls Ihre Applikation einen angepassten Callback Handler enthält, der auf die Klasse org.apache.ws.security.WSPasswordCallback zugreift, dann beachten Sie, dass dieseKlasse in das Paket org.apache.wss4j.common.ext verlegt wurde.

Die meisten der SAML-Bean-Objekte vom Paket org.apache.ws.security.saml.extwurden in das Paket org.apache.wss4j.common.saml package verlegt.

Verwenden Sie den RSA v1.5 Schlüsseltransport und alle zugehörigen Algorithmen sindstandardmäßig untersagt.

Der Security Token Service (STS) validierte bisher lediglich onBehalfOf-Tokens. Er validiertnun auch ActAs-Tokens. Infolgedessen müssen gültige Werte für Benutzername und Passwortim UsernameToken angegeben werden, das für das ActAs-Token bereitgestellt wird.

SAML Bearer Tokens müssen nun über eine interne Signatur verfügen. Die Klasse org.apache.wss4j.dom.validate.SamlAssertionValidator besitzt nun eine setRequireBearerSignature()-Methode, um die Signaturprüfung zu aktivieren bzw. zudeaktivieren.

5.1.4. Änderungen der JBoss-Modulstruktur

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 bietetmehr Klassen als in der vorherigen Release.

5.1.5. Änderungen und Voraussetzungen von BouncyCastle

Falls Sie AES-Verschlüsselung mit Galois/Counter-Modus (GCM) für symmetrische Verschlüsselung inXML/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, mithilfeseines Klassenladers den BouncyCastle-Sicherheitsprovider zu erhalten und zu verwenden. Es ist dahernicht mehr nötig, BouncyCastle statisch in der aktuellen JVM zu installieren. Für Applikationen, dieauß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ürClients.


49

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

5.1.6. Apache CXF-Bus Auswahlstrategie

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

Booten Sie den JBoss EAP Server mit dem Wert THREAD_BUS für die Systemeigenschaft org.jboss.ws.cxf.jaxws-client.bus.strategy.

Legen Sie die Auswahlstrategie ausdrücklich im Clientcode fest.

5.1.7. JAX-WS 2.2 Anforderungen für WebServiceRef

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

5.1.8. Änderungen der IgnoreHttpsHost CN-Überprüfung

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

5.1.9. Serverseitige Konfiguration und Klassenladen

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

5.1.10. Auslaufen des »Java Endorsed Standards Override Mechanism«

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

Falls Ihre Applikation die JBossWS-Implementierung von Apache CXF verwendet, gewährleistet JBossEAP 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 aufApache CXF zugreift, müssen Sie nun die Apache CXF Abhängigkeiten nach den JBossWS-Abhängigkeiten hinzufügen im Rahmen Ihres Applikations-Deployments.

5.1.11. Spezifikation von Deskriptor in EAR-Archiv


50

https://docs.oracle.com/javase/7/docs/api/javax/xml/ws/WebServiceFeature.html

https://docs.oracle.com/javase/8/docs/technotes/guides/standards/

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-Archivenoder im Verzeichnis WEB-INF/ für POJO-Webservice-Deployments und EJB-Webservice-Endpunktegebündelt in WAR-Archiven konfigurieren.

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

5.2. ÄNDERUNGEN DES REMOTE-URL-CONNECTORS UND -PORTS

In JBoss EAP 7 wurde der Standard-Connector geändert von remote auf http-remoting und derstandardmäßige Remote-Verbindungsport wurde geändert von 4447 auf 8080. Die JNDI-Provider-URLfü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 modifythe remote connector, remote port, or JNDI provider URLs because the migration operation preservesthe JBoss EAP 6 remoting connector and 4447 port configuration settings in the subsystemconfiguration. For more information about the migrate operation, see Management CLI MigrationOperation.

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

5.3. ÄNDERUNGEN DER MESSAGING-APPLIKATION

5.3.1. Ersetzen oder Aktualisieren von JMS-Deployment-Deskriptoren

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

Falls Sie in der früheren Release -jms.xml JMS-Deployment-Deskriptoren in Ihrer Applikation

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


51

verwendet haben, können Sie Ihre Applikation entweder zur Verwendung des standardmäßigen JavaEE 7 Deployment-Deskriptors konvertieren (siehe Abschnitt EE.5.18 der Java EE 7 specification) oderSie können die Deployment-Deskriptoren auf das messaging-activemq-Subsystem in JBoss EAP 7aktualisieren.

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

Ändern Sie den Namespace von »urn:jboss:messaging-deployment:1.0« auf»urn:jboss:messaging-activemq-deployment:1.0«.

Ändern Sie den Elementnamen <hornetq-server> auf <server>.

Die aktualisierte Datei sollte etwa wie das folgende Beispiel aussehen.

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

5.3.2. Aktualisieren der externen JMS-Clients

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 altenEinstellungen bewahrt und Sie müssen Ihre PROVIDER_URL nicht aktualisieren. Wenn Sie dagegen dieneue 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. WeitereInformationen 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.

5.3.3. Ersetzen der HornetQ-API

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

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


52

http://download.oracle.com/otn-pub/jcp/java_ee-7-fr-spec/JavaEE_Platform_Spec.pdf

https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.4/html/API_Documentation/files/javadoc/index.html?org/hornetq/api/core/package-summary.html

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

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

5.4. ÄNDERUNGEN DER JAX-RS UND RESTEASY-APPLIKATION

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

Die in JBoss EAP enthaltene Version von Jackson hat sich geändert. Die vorherige Version von JBossEAP 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.

5.4.1. Veraltete Klassen in RESTEasy

Interzeptor- und MessageBody-KlassenJSR 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-Webservicesführte ein offizielles Interzeptor- und Filter-Framework ein, weshalb das in RESTEasy 2 enthalteneInterzeptor-Framework nun als veraltet gilt und durch die JAX-RS 2.0 konforme Interzeptor-Facility inRESTEasy 3.x. ersetzt wurde. Die relevanten Schnittstellen werden im Paket javax.ws.rs.ext desModuls jaxrs-api definiert.

Die folgenden Interzeptor-Schnittstellen gelten in RESTEasy 3.x als veraltet.

org.jboss.resteasy.spi.interception.PreProcessInterceptor

org.jboss.resteasy.spi.interception.PostProcessInterceptor

org.jboss.resteasy.spi.interception.ClientExecutionInterceptor

org.jboss.resteasy.spi.interception.ClientExecutionContext

org.jboss.resteasy.spi.interception.AcceptedByMethod

Die Schnittstelle org.jboss.resteasy.spi.interception.PreProcessInterceptorwurde in RESTEasy 3.x ersetzt durch die Schnittstelle javax.ws.rs.container.ContainerRequestFilter.

Die folgenden Schnittstellen und Klassen gelten ebenfalls als veraltet in RESTEasy 3.x.

org.jboss.resteasy.spi.interception.MessageBodyReaderInterceptor

org.jboss.resteasy.spi.interception.MessageBodyWriterInterceptor

org.jboss.resteasy.spi.interception.MessageBodyWriterContext

org.jboss.resteasy.spi.interception.MessageBodyReaderContext

org.jboss.resteasy.core.interception.InterceptorRegistry


53

https://activemq.apache.org/artemis/docs/javadocs/javadoc-1.2.0/index.html

https://jcp.org/en/jsr/detail?id=339

https://jax-rs-spec.java.net/nonav/2.0-rev-a/apidocs/index.html



https://docs.jboss.org/resteasy/docs/3.0.13.Final/javadocs/org/jboss/resteasy/spi/interception/PreProcessInterceptor.html

https://docs.jboss.org/resteasy/docs/3.0.13.Final/javadocs/org/jboss/resteasy/spi/interception/PostProcessInterceptor.html

https://docs.jboss.org/resteasy/docs/3.0.13.Final/javadocs/org/jboss/resteasy/spi/interception/ClientExecutionInterceptor.html

https://docs.jboss.org/resteasy/docs/3.0.13.Final/javadocs/org/jboss/resteasy/spi/interception/ClientExecutionContext.html

https://docs.jboss.org/resteasy/docs/3.0.13.Final/javadocs/org/jboss/resteasy/spi/interception/AcceptedByMethod.html

https://docs.jboss.org/resteasy/docs/3.0.13.Final/javadocs/org/jboss/resteasy/spi/interception/PreProcessInterceptor.html

https://jax-rs-spec.java.net/nonav/2.0-rev-a/apidocs/javax/ws/rs/container/ContainerRequestFilter.html

https://docs.jboss.org/resteasy/docs/3.0.13.Final/javadocs/org/jboss/resteasy/spi/interception/MessageBodyReaderInterceptor.html

https://docs.jboss.org/resteasy/docs/3.0.13.Final/javadocs/org/jboss/resteasy/spi/interception/MessageBodyWriterInterceptor.html

https://docs.jboss.org/resteasy/docs/3.0.13.Final/javadocs/org/jboss/resteasy/spi/interception/MessageBodyWriterContext.html

https://docs.jboss.org/resteasy/docs/3.0.13.Final/javadocs/org/jboss/resteasy/spi/interception/MessageBodyReaderContext.html

https://docs.jboss.org/resteasy/docs/3.0.13.Final/javadocs/org/jboss/resteasy/core/interception/InterceptorRegistry.html

org.jboss.resteasy.core.interception.InterceptorRegistryListener

org.jboss.resteasy.core.interception.ClientExecutionContextImpl

Die Schnittstelle org.jboss.resteasy.spi.interception.MessageBodyWriterInterceptor wurdeersetzt durch die Schnittstelle javax.ws.rs.ext.WriterInterceptor.

In addition, some changes to the javax.ws.rs.ext.MessageBodyWriter interface mightnot be backward compatible with respect to JAX-RS 1.x. If your application used JAX-RS 1.x,review your application code to make sure you define @Produces or @Consumes for yourendpoints. Failure to do so might result in an error similar to the following.

org.jboss.resteasy.core.NoMessageBodyWriterFoundFailure: Could not find MessageBodyWriter for response object of type: <OBJECT> of media type:

Nachfolgend sehen Sie ein Beispiel für einen REST-Endpunkt, der diesen Fehler verursacht.

Um diesen Fehler zu beheben, fügen Sie den Import für javax.ws.rs.Produces und dieAnnotation @Produces wie folgt hinzu.

@Path("dates")public class DateService {

@GET @Path("daysuntil/{targetdate}") public long showDaysUntil(@PathParam("targetdate") String targetDate) { DateLogger.LOGGER.logDaysUntilRequest(targetDate); final long days;

try { final LocalDate date = LocalDate.parse(targetDate, DateTimeFormatter.ISO_DATE); days = ChronoUnit.DAYS.between(LocalDate.now(), date); } catch (DateTimeParseException ex) { // ** DISCLAIMER **. This example is contrived. throw new WebApplicationException(Response.status(400).entity(ex.getLocalizedMessage()).type(MediaType.TEXT_PLAIN) .build()); } return days; }}

...import javax.ws.rs.Produces;...

@Path("dates")public class DateService {

@GET


54

https://docs.jboss.org/resteasy/docs/3.0.13.Final/javadocs/org/jboss/resteasy/core/interception/InterceptorRegistryListener.html

https://docs.jboss.org/resteasy/docs/3.0.13.Final/javadocs/org/jboss/resteasy/core/interception/ClientExecutionContextImpl.html


https://jax-rs-spec.java.net/nonav/2.0-rev-a/apidocs/javax/ws/rs/ext/WriterInterceptor.html


ANMERKUNG

Alle Interzeptoren aus der vorherigen Release von RESTEasy können parallel zum neuenJAX-RS 2.0 Filter und den Interzeptor-Schnittstellen laufen.

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

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

Client-APIDas 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 -Methodennun veraltet.

Die folgenden Klassen sind veraltet.

org.jboss.resteasy.client.ClientRequest

org.jboss.resteasy.client.ClientRequestFactory

org.jboss.resteasy.client.ClientResponse

org.jboss.resteasy.client.ProxyBuilder

org.jboss.resteasy.client.ProxyConfig

org.jboss.resteasy.client.ProxyFactory

Die Ausnahme org.jboss.resteasy.client.ClientResponseFailure und dieSchnittstellen org.jboss.resteasy.client.ClientExecutor und org.jboss.resteasy.client.EntityTypeFactory sind ebenfalls veraltet.

@Path("daysuntil/{targetdate}") @Produces(MediaType.TEXT_PLAIN) public long showDaysUntil(@PathParam("targetdate") String targetDate) { DateLogger.LOGGER.logDaysUntilRequest(targetDate); final long days;

try { final LocalDate date = LocalDate.parse(targetDate, DateTimeFormatter.ISO_DATE); days = ChronoUnit.DAYS.between(LocalDate.now(), date); } catch (DateTimeParseException ex) { // ** DISCLAIMER **. This example is contrived. throw new WebApplicationException(Response.status(400).entity(ex.getLocalizedMessage()).type(MediaType.TEXT_PLAIN) .build()); } return days; }}


55

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/developing-web-services-applications/#resteasy_interceptors

https://docs.jboss.org/resteasy/docs/3.0.13.Final/javadocs/index.html

https://docs.jboss.org/resteasy/docs/3.0.13.Final/javadocs/org/jboss/resteasy/client/ClientRequest.html

https://docs.jboss.org/resteasy/docs/3.0.13.Final/javadocs/org/jboss/resteasy/client/ClientRequestFactory.html

https://docs.jboss.org/resteasy/docs/3.0.13.Final/javadocs/org/jboss/resteasy/client/ClientResponse.html

https://docs.jboss.org/resteasy/docs/3.0.13.Final/javadocs/org/jboss/resteasy/client/ProxyBuilder.html

https://docs.jboss.org/resteasy/docs/3.0.13.Final/javadocs/org/jboss/resteasy/client/ProxyConfig.html

https://docs.jboss.org/resteasy/docs/3.0.13.Final/javadocs/org/jboss/resteasy/client/ProxyFactory.html

https://docs.jboss.org/resteasy/docs/3.0.13.Final/javadocs/org/jboss/resteasy/client/ClientResponseFailure.html

https://docs.jboss.org/resteasy/docs/3.0.13.Final/javadocs/org/jboss/resteasy/client/ClientExecutor.html

https://docs.jboss.org/resteasy/docs/3.0.13.Final/javadocs/org/jboss/resteasy/client/EntityTypeFactory.html

Sie müssen die Klassen org.jboss.resteasy.client.ClientRequest und org.jboss.resteasy.client.ClientResponse ersetzen durch org.jboss.resteasy.client.jaxrs.ResteasyClient bzw. javax.ws.rs.core.Response.Nachfolgend sehen Sie ein Beispiel für das Senden eines Link-Headers mit dem RESTEasy-Client in RESTEasy 2.3.x.

Nachfolgend sehen Sie ein Beispiel für das Durchführen derselben Aufgabe mit demRESTEasy-Client in RESTEasy 3.

Siehe resteasy-jaxrs-client-Quickstart für ein Beispiel für einen externen JAX-RSRESTEasy-Client, der mit einem JAX-RS Webservice interagiert.

Die Klassen und Schnittstellen im Paket org.jboss.resteasy.client.cache sindebenfalls veraltet. Sie wurden ersetzt durch entsprechende Klassen und Schnittstellen im Paket org.jboss.resteasy.client.jaxrs.cache.

ANMERKUNG

Weitere Informationen über die API-Klassen org.jboss.resteasy.client.jaxrsfinden Sie unter RESTEasy JAX-RS JavaDoc.

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

5.4.2. Entfernte oder geschützte RESTEasy-Klassen

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

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

ClientRequest request = new ClientRequest(generateURL("/linkheader/str"));request.addLink("previous chapter", "previous", "http://example.com/TheBook/chapter2", null);ClientResponse response = request.post();LinkHeader header = response.getLinkHeader();

ResteasyClient client = new ResteasyClientBuilder().build();Response response = client.target(generateURL("/linkheader/str")).request() .header("Link", "<http://example.com/TheBook/chapter2>; rel=\"previous\";title=\"previous chapter\"").post(Entity.text(new String()));javax.ws.rs.core.Link link = response.getLink("previous");


56

https://docs.jboss.org/resteasy/docs/3.0.13.Final/javadocs/org/jboss/resteasy/client/ClientRequest.html

https://docs.jboss.org/resteasy/docs/3.0.13.Final/javadocs/org/jboss/resteasy/client/ClientResponse.html

https://docs.jboss.org/resteasy/docs/3.0.13.Final/javadocs/org/jboss/resteasy/client/jaxrs/ResteasyClient.html

https://jax-rs-spec.java.net/nonav/2.0-rev-a/apidocs/javax/ws/rs/core/Response.html

https://docs.jboss.org/resteasy/docs/3.0.13.Final/javadocs/org/jboss/resteasy/client/cache/package-frame.html

https://docs.jboss.org/resteasy/docs/3.0.13.Final/javadocs/org/jboss/resteasy/client/jaxrs/cache/package-frame.html

https://docs.jboss.org/resteasy/docs/3.0.13.Final/javadocs/

https://docs.jboss.org/resteasy/docs/3.0.13.Final/javadocs/org/jboss/resteasy/spi/StringConverter.html

https://docs.oracle.com/javaee/7/api/javax/ws/rs/ext/ParamConverterProvider.html

https://docs.jboss.org/resteasy/docs/3.0.13.Final/javadocs/org/jboss/resteasy/spi/ResteasyProviderFactory.html

Weitere von RESTEasy 3 entfernte KlassenDie Annotation @org.jboss.resteasy.annotations.cache.ServerCached, die angibt, dass dieAntwort auf die JAX-RS-Methode auf dem Server gecacht werden soll, wurde aus RESTEasy 3 entferntund muss aus dem Applikationscode entfernt werden.

5.4.3. Weitere RESTEasy-Änderungen

SignedInput und SignedOuput

SignedInput und SignedOutput für resteasy-crypto müssen den Content-Type auf multipart/signed gesetzt haben, entweder im Request- oder im Response-Objekt oderdurch Verwendung der Annotation @Consumes oder @Produces.

SignedOutput und SignedInput können dazu verwendet werden, um das application/pkcs7-signature MIME-Type-Format in Binärformat zurückzugeben, indemdieser Typ in der Annotation @Produces oder @Consumes festgelegt wird.

Falls @Produces oder @Consumes vom MIME-Typ text/plain ist, wird SignedOutputbase64-kodiert und als Zeichenkette gesendet.

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

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

Asynchrone HTTP-UnterstützungBecause the JAX-RS 2.0 specification adds asynchronous HTTP support using the @Suspendedannotation and the AsynResponse interface, the RESTEasy proprietary API for asynchronous HTTPhas been deprecated and might be removed as soon as RESTEasy 3.1. The asynchronous Tomcat andasynchronous JBoss Web modules have also been removed from the server installation. If you are notusing the Servlet 3.0 container or higher, asynchronous HTTP server-side processing will be simulatedand run synchronously in same request thread.

Serverseitiger CacheDie Einrichtung des serverseitigen Caches hat sich verändert. Siehe RESTEasy-Dokumentation fürweitere Informationen.

5.4.4. Änderungen der RESTEasy SPI

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

Veraltete Ausnahme Ersatz-Ausnahme im jaxrs-api-Modul

org.jboss.resteasy.spi.ForbiddenException javax.ws.rs.ForbiddenException

org.jboss.resteasy.spi.MethodNotAllowedException javax.ws.rs.NotAllowedException

org.jboss.resteasy.spi.NotAcceptableException javax.ws.rs.NotAcceptableException


57

https://docs.jboss.org/resteasy/docs/3.0.0.Final/userguide/html/

org.jboss.resteasy.spi.NotFoundException javax.ws.rs.NotFoundException

org.jboss.resteasy.spi.UnauthorizedException javax.ws.rs.NotAuthorizedException

org.jboss.resteasy.spi.UnsupportedMediaTypeException

javax.ws.rs.NotSupportedException

Veraltete Ausnahme Ersatz-Ausnahme im jaxrs-api-Modul

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

5.4.5. Änderungen des Jackson-Providers

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

Das Upgrade auf resteasy-jackson2-provider erfordert einige Paketänderungen. Beispielsweisehat 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 JBossEAP, see Switching the Default Jackson Provider in Developing Web Services Applications for JBossEAP.

5.4.6. Änderungen der Spring RESTEasy-Integration

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

5.4.7. Änderungen des RESTEasy Jettison JSON-Providers

Der RESTEasy Jettison JSON-Provider gilt in JBoss EAP 7 als veraltet und wird standardmäßig nichtmehr zu Deployments hinzugefügt. Wir raten Ihnen, auf den empfohlenen RESTEasy Jackson-Providerzu wechseln. Falls Sie es vorziehen, weiterhin den Jettison-Provider zu verwenden, müssen Sie eineexplizite Abhängigkeit dafür in der Datei jboss-deployment-descriptor.xml definieren, wie imfolgenden 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"


58

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/developing-web-services-applications/#switching_the_default_jackson_provider

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

5.5. ÄNDERUNGEN DER CDI 1.2 APPLIKATION

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

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

Contexts and Dependency Injection for the Java EE platform

CDI 1.2 Javadoc

Weld 2.3.3.Final - CDI Reference Implementation

Bean-ArchiveBean-Klassen mit aktivierten Beans müssen in Bean-Archiven deployt sein, um zu gewährleisten, dasssie 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 imVerzeichnis META-INF/ eines Applikations-Clients, EJB oder Bibliothek-JAR enthielt, oder wenn es einebeans.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 mehrereBean-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 mitAnnotationen zur Bean-Definition gefunden. Weitere Informationen finden Sie unter Type and BeanDiscovery 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, daseine beans.xml-Datei ohne Version enthält, hat standardmäßig den Bean-Discovery-Modus all. EinBean-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:

Es enthält eine beans.xml-Datei mit dem bean-discovery-mode none.

Es enthält eine CDI-Erweiterung ohne beans.xml-Datei.

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

Das Archiv enthält eine beans.xml-Datei mit der Versionsnummer 1.1 oder höher und den bean-discovery-mode all.

Das Archiv enthält eine beans.xml-Datei ohne Versionsnummer.

Das Archiv enthält eine leere beans.xml-Datei.

services="import"/> </dependencies> </deployment></jboss-deployment-structure>


59

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/development-guide/#add_an_explicit_module_dependency_to_a_deployment

http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html

http://docs.jboss.org/cdi/api/1.2/

http://docs.jboss.org/weld/reference/latest/en-US/html_single/

http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#type_bean_discovery

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

Das Archiv enthält eine oder mehrere Bean-Klassen mit einer Annotation zur Bean-Definition,oder eine oder mehrere Session-Beans, selbst wenn es keine beans.xml-Datei enthält.

Das Archiv enthält eine beans.xml-Datei mit dem bean-discovery-mode annotated.

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

@ApplicationScoped, @SessionScoped, @ConversationScoped und @RequestScoped

Alle anderen normalen Scope-Typen

@Interceptor und @Decorator

Alle Stereotyp-Annotationen, also Annotationen mit @Stereotype annotiert

@Dependent Scope-Annotation

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

Klärung der KonversationsauflösungDer 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 istwährend jeglicher Servlet-Anfragen aktiv und sollte andere Servlets oder Servlet-Filter nicht daranhindern, den Anfrage-Body oder die Zeichenkodierung einzustellen.

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

5.6. MIGRIEREN EXPLIZITER MODULABHÄNGIGKEITEN

Die Einführung des modularen Klassenladesystems und JBoss Modules in der vorherigen Release vonJBoss 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 derApplikation.

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

Überprüfen der Abhängigkeiten auf VerfügbarkeitDie Module, die in JBoss EAP enthalten sind, haben sich geändert. Wenn Sie Ihre Applikation zu JBossEAP 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 Produktreleaseentfernt wurden.

Abhängigkeiten, die Annotations-Prüfung erfordernFalls Ihre Abhängigkeiten Annotationen enthielten, die während der Annotationsprüfung verarbeitetwerden mussten (z.B. beim Deklarieren von EJB-Interzeptoren), dann mussten Sie in der vorherigenVersion von JBoss EAP einen Jandex-Index in einer neuen JAR-Datei generieren und einbeziehen und


60

http://docs.jboss.org/cdi/spec/1.2/cdi-spec-with-assertions.html#bean_defining_annotations

http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bean_archive

https://issues.jboss.org/browse/CDI-411

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 Siediese 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 derApplikation hinzufügen, wie unten veranschaulicht.

Beispiel für Annotations-Flag in der MANIFEST.MF-Datei

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

Beispiel für Annotations-Flag in der jboss-deployment-structure.xml-Datei

5.7. ÄNDERUNGEN HINSICHTLICH HIBERNATE UND JPA

5.7.1. Hibernate ORM 3.0

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

5.7.2. Hibernate ORM 4.0 – 4.3

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

Applikationen, die mit Hibernate ORM 4.x geschrieben wurden, können weiterhin Hibernate ORM 4.xverwenden. Sie müssen ein angepasstes JBoss-Modul für die Hibernate ORM 4.x JARs definieren unddie Hibernate ORM 5 Klassen aus Ihrer Applikation ausschließen. Allerdings empfehlen wir Ihnendringend, 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.

5.7.3. 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ährenddes Deployments auf und geht davon aus, dass die Applikation JPA verwendet. es fügt dem KlassenpfadIhrer Applikation implizit die Hibernate ORM 5 Bibliotheken sowie ein paar andere Abhängigkeiten hinzuund verwendet standardmäßig diese Bibliotheken.

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


61

5.7.4. Migrieren zu Hibernate ORM 5

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

Entfernte und veraltete KlassenDie folgenden veralteten Klassen wurden aus Hibernate ORM 5 entfernt.

org.hibernate.cfg.AnnotationConfiguration

org.hibernate.id.TableGenerator

org.hibernate.id.TableHiLoGenerator

org.hibernate.id.SequenceGenerator

Sonstige Änderungen an Klassen und Paketen

Die Schnittstelle org.hibernate.integrator.spi.Integrator hat sich entsprechend derBootstrap-Überarbeitung verändert.

Ein neues Paket org.hibernate.engine.jdbc.env wurde erstellt. Es enthält dieSchnittstelle org.hibernate.engine.jdbc.env.spi.JdbcEnvironment, die aus derSchnittstelle org.hibernate.engine.jdbc.spi.JdbcServices extrahiert wurde.

Eine neue Schnittstelle org.hibernate.boot.model.relational.ExportableProducer wurde eingeführt, wasAuswirkungen auf org.hibernate.id.PersistentIdentifierGenerator-Implementierungen hat.

Die Signatur von org.hibernate.id.Configurable wurde geändert, um org.hibernate.service.ServiceRegistry zu akzeptieren, statt nur org.hibernate.dialect.Dialect.

Die Schnittstelle org.hibernate.metamodel.spi.TypeContributor wurde migriert zu org.hibernate.boot.model.TypeContributor.

Die Schnittstelle org.hibernate.metamodel.spi.TypeContributions wurde migriert zu org.hibernate.boot.model.TypeContributions.

Typenhandhabung

Integrierte org.hibernate.type.descriptor.sql.SqlTypeDescriptor-Implementierungen registrieren sich nicht mehr automatisch bei der org.hibernate.type.descriptor.sql.SqlTypeDescriptorRegistry. Applikationen,die angepasste SqlTypeDescriptor-Implementierungen verwenden, welche die integriertenImplementierungen erweitern und auf dieses Verhalten angewiesen sind, müssen aktualisiertwerden, um selbst SqlTypeDescriptorRegistry.addDescriptor() aufzurufen.

Für IDs, die als generierte UUIDs definiert sind, setzen einige Datenbanken voraus, dass Sie fürdie Generierung von BINARY(16) die @Column(length=16) ausdrücklich festlegen, damitder Abgleich einwandfrei funktioniert.

Für EnumType-Mappings, die in der Datei hbm.xml definiert sind und Sie javax.persistence.EnumType.STRING name-mapping möchten, muss diese


62

https://github.com/hibernate/hibernate-orm/blob/5.0/migration-guide.adoc

https://docs.jboss.org/hibernate/orm/3.5/api/org/hibernate/cfg/AnnotationConfiguration.html

https://docs.jboss.org/hibernate/orm/3.5/api/org/hibernate/id/TableGenerator.html

https://docs.jboss.org/hibernate/orm/3.5/api/org/hibernate/id/TableHiLoGenerator.html

https://docs.jboss.org/hibernate/orm/3.5/api/org/hibernate/id/SequenceGenerator.html

https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/integrator/spi/Integrator.html

https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/engine/jdbc/spi/package-frame.html

https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/engine/jdbc/env/spi/JdbcEnvironment.html

https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/engine/jdbc/spi/JdbcServices.html

https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/boot/model/relational/ExportableProducer.html

https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/id/PersistentIdentifierGenerator.html

https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/id/Configurable.html

https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/service/ServiceRegistry.html

https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/dialect/Dialect.html

https://docs.jboss.org/hibernate/orm/4.3/javadocs/org/hibernate/metamodel/spi/TypeContributor.html

https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/boot/model/TypeContributor.html

https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/boot/model/TypeContributions.html

https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/boot/model/TypeContributions.html

https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/type/descriptor/sql/SqlTypeDescriptor.html

https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/type/descriptor/sql/SqlTypeDescriptorRegistry.html

http://docs.oracle.com/javaee/7/api/javax/persistence/EnumType.html#STRING

Konfiguration ausdrücklich angegeben werden. Nutzen Sie dazu entweder die Einstellung useNamed(true) oder geben Sie einen VARCHAR-Wert von 12 an.

Transaktionsverwaltung

Die Transaktions-SPI wurde in Hibernate ORM 5 umfassend überarbeitet. In Hibernate ORM4.3 verwendeten Sie die org.hibernate.Transaction-API, um direkt auf verschiedeneBack-end-Transaktionsstrategien zuzugreifen. Hibernate ORM 5 führte eine Ebene derIndirektion ein. Im Back-end kommuniziert die org.hibernate.TransactionImplementierung nun mit einem org.hibernate.resource.transaction.TransactionCoordinator, der dentransaktionalen Kontext für eine angegebene Sitzung repräsentiert gemäß Back-end-Strategie.Dies hat zwar keine direkten Auswirkungen auf Entwickler, könnte aber die Bootstrap-Konfiguration beeinflussen. Bislang spezifizierten Applikationen die Eigenschaft hibernate.transaction.factory_class (die jetzt veraltet ist) und verwiesen auf einen org.hibernate.engine.transaction.spi.TransactionFactory-FQN (vollständigenNamen). Mit Hibernate ORM 5 spezifizieren Sie die Einstellung hibernate.transaction.coordinator_class und verweisen auf einen org.hibernate.resource.transaction.TransactionCoordinatorBuilder. Siehe org.hibernate.cfg.AvailableSettings.TRANSACTION_COORDINATOR_STRATEGY fürweitere Einzelheiten.

Die folgenden Kurznamen werden jetzt erkannt.

jdbc: Manage transactions using the JDBC java.sql.Connection. This is the default fornon-JPA transactions.

jta: Manage transactions using JTA.

WICHTIG

If a JPA application does not provide a setting for the hibernate.transaction.coordinator_class property, Hibernate willautomatically build the proper transaction coordinator based on thetransaction type for the persistence unit.

If a non-JPA application does not provide a setting for the hibernate.transaction.coordinator_class property, Hibernate willdefault to jdbc to manage the transactions. This default will cause problemsif the application actually uses JTA-based transactions. A non-JPA applicationthat uses JTA-based transactions should explicitly set the hibernate.transaction.coordinator_class property value to jta orprovide a custom org.hibernate.resource.transaction.TransactionCoordinatorBuilder that builds a org.hibernate.resource.transaction.TransactionCoordinatorthat properly coordinates with JTA-based transactions.

Sonstige Hibernate ORM 5 Änderungen

Die cfg.xml-Dateien werden wieder vollständig analysiert und integriert in Ereignissen, in derSicherheit und in anderen Funktionen.

Die mittels EntityManagerFactory von cfg.xml geladenen Eigenschaften haben dieNamen bislang nicht mit dem Präfix hibernate versehen. Dies wurde jetzt vereinheitlicht.


63

https://docs.oracle.com/javase/8/docs/api/java/sql/Types.html#VARCHAR

https://docs.jboss.org/hibernate/orm/4.3/javadocs/org/hibernate/Transaction.html

https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/Transaction.html

https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/resource/transaction/TransactionCoordinator.html

https://docs.jboss.org/hibernate/orm/4.3/javadocs/org/hibernate/engine/transaction/spi/TransactionFactory.html

https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/resource/transaction/TransactionCoordinatorBuilder.html

https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/cfg/AvailableSettings.html#TRANSACTION_COORDINATOR_STRATEGY

https://docs.oracle.com/javase/8/docs/api/java/sql/Connection.html

https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/resource/transaction/TransactionCoordinatorBuilder.html

https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/resource/transaction/TransactionCoordinator.html

Die Konfiguration ist nicht mehr serialisierbar.

Die Methode org.hibernate.dialect.Dialect.getQuerySequencesString() ruft nunWerte für Katalog, Schema und Inkrement ab.

Der Modifier AuditConfiguration wurde aus org.hibernate.envers.boot.internal.EnversService entfernt.

Die Methodenparameter AuditStrategy wurden geändert, um die hinfällige AuditConfiguration zu entfernen und den neuen EnversService zu verwenden.

Verschiedene Klassen und Schnittstellen im org.hibernate.hql.spi-Paket undUnterpaketen wurden verlegt in das neue Paket org.hibernate.hql.spi.id. Dazu gehörtdie Klasse MultiTableBulkIdStrategy sowie die Schnittstellen AbstractTableBasedBulkIdHandler, TableBasedDeleteHandlerImpl und TableBasedUpdateHandlerImpl samt deren Unterklassen.

Die Verträge für Eigenschaftszugriff wurden vollständig überarbeitet.

Gültige Werte für die Einstellung hibernate.cache.default_cache_concurrency_strategy sind nun definiert anhandder Methode org.hibernate.cache.spi.access.AccessType.getExternalName()anstelle der Aufzählungskonstanten org.hibernate.cache.spi.access.AccessType.Dies steht im Einklang mit anderen Hibernate-Einstellungen.

5.8. ÄNDERUNGEN HINSICHTLICH HIBERNATE SEARCH

Die in JBoss EAP 7 integrierte Version von Hibernate Search hat sich geändert. Die vorherige Releasevon 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 toalign with this version. The Hibernate Search 5.5 API wraps and hides the complexity of many of theLucene API changes made between version 3 and version 5, however, some classes are nowdeprecated, renamed, or repackaged. This section describes how these changes might impact yourapplication code.

Änderungen des Hibernate Search MappingsIndexierung von ID-Feldern in eingebetteten ObjektenWenn eine @IndexedEmbedded-Annotation verwendet wird, um Felder von einem zugehörigen Objekteinzubinden, dann ist die id des zugehörigen Objekts nicht mehr enthalten. Sie können dieEinbeziehung der id aktivieren, indem Sie den Parameter includeEmbeddedObjectId derAnnotation @IndexedEmbedded verwenden.

Änderungen der Formatierung von Zahlen- und DatumsindexierungZahlen 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 alsZeichenketten (Strings) indiziert. Stattdessen werden sie nun unter Verwendung von Lucenesnumerischer Kodierung indiziert. Die id-Felder stellen eine Ausnahme von dieser Regel dar. Selbstwenn es sich bei ihnen um einen numerischen Typ handelt, werden sie standardmäßig dennoch alsZeichenketten indiziert. Die Verwendung von @NumericField ist nun obsolet, es sei denn, Siemöchten eine angepasste Länge für die numerische Kodierung festlegen. Sie können das alte

@IndexedEmbedded(includeEmbeddedObjectId=true)


64

https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/dialect/Dialect.html

https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/envers/boot/internal/EnversService.html

https://docs.jboss.org/hibernate/orm/4.3/javadocs/org/hibernate/hql/spi/package-frame.html

https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/hql/spi/id/package-frame.html

https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/cache/spi/access/AccessType.html

https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/cache/spi/access/AccessType.html

https://docs.jboss.org/hibernate/search/5.5/api/index.html

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 Paketorg.hibernate.search.bridge.builtin finden Sie andere öffentlich verfügbare Bridges.

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

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

Sonstige Änderungen hinsichtlich Hibernate Search

Die Sortierungsoptionen wurden verbessert; die inkorrekte Angabe der Feldkodierung fürSortierungsoptionen führt nun zu einem Laufzeitfehler. Lucene bietet zudem eineleistungsstärkere Sortierung, wenn die in der Sortierung verwendeten Felder bereits bekanntsind. Hibernate Search 5.5 bietet die neuen Annotationen @SortableField bzw. @SortableFields. Unter Migration Guide from Hibernate Search 5.4 to 5.5 finden Sie weitereInformationen.

Die Lucene SortField-API erfordert die folgenden Änderungen am Applikationscode.In der vorherigen Release von JBoss EAP legten Sie den Typ des Sortierungsfeldes wie folgt inder Anfrage fest.

Nachfolgend sehen Sie ein Beispiel dafür, wie dies in JBoss EAP 7 angegeben wird.

Da SearchFactory nur von ORM-Integrationen verwendet werden sollte, wurde sie vomModul hibernate-search-engine in das Modul hibernate-search-orm verlegt. AndereIntegratoren sollten ausschließlich SearchIntegrator verwenden, was das veraltete SearchFactoryIntegrator ersetzt.

Der Aufzählungswert SpatialMode.GRID wurde umgenannt zu SpatialMode.HASH.

FullTextIndexEventListener ist nun eine finale Klasse. Falls Sie derzeit diese Klasseerweitern, müssen Sie eine alternative Lösung finden, um dieselbe Funktionalität zu erreichen.

Das Modul hibernate-search-analyzers wurde entfernt. Die empfohleneHerangehensweise ist nun die direkte Verwendung des jeweiligen Lucene-Artefakts, zumBeispiel org.apache.lucene:lucene-analyzers-common.

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

fulltextQuery.setSort(new Sort(new SortField("title", SortField.STRING)));

fulltextQuery.setSort(new Sort(new SortField("title", SortField.Type.STRING)));


65

http://docs.jboss.org/hibernate/search/5.5/api/org/hibernate/search/bridge/builtin/IntegerBridge.html

http://docs.jboss.org/hibernate/search/5.5/api/org/hibernate/search/bridge/builtin/package-summary.html

http://docs.jboss.org/hibernate/search/5.0/api/org/hibernate/search/annotations/EncodingType.html

http://hibernate.org/search/documentation/migrate/5.5/

https://lucene.apache.org/core/5_3_1/core/org/apache/lucene/search/SortField.html

The JMS controller API has changed. The JMS back-end dependency on Hibernate ORM wasremoved so that it could be used in other non-ORM environments. A consequence is thatimplementors of org.hibernate.search.backend.impl.jms.AbstractJMSHibernateSearchController must adjust to the new signature. This class is an internal class and it is recommended touse it as an example instead of extending it.

Die org.hibernate.search.spi.ServiceProvider-SPI wurde refaktoriert. Falls Sie denalten Dienstvertrag integriert haben, werfen Sie einen Blick auf das Hibernate Search 5.5Javadoc von ServiceManager, Service, Startable und Stoppable für Einzelheiten zumneuen Vertrag.

Falls Sie die von Lucene 3.x generierten Indexe behalten haben und diese nicht mit HibernateSearch 5.0 oder höher neu erstellt haben, erhalten Sie den Fehler IndexFormatTooOldException. Es wird empfohlen, die Indexe mit dem Massenindexer neuzu erstellen. Falls Ihnen das nicht möglich ist, sollten Sie Lucenes IndexUpgrader probieren.Sie müssen die Hibernate Search Mappings sorgfältig aktualisieren für den Fall, dass sich dasStandardverhalten geändert hat. Weitere Informationen siehe Apache Lucene Migration Guide.

Apache Lucene wurde in JBoss EAP 7 aktualisiert von 3.6 auf 5.3. Falls Ihr Code Lucene-Codedirekt importiert, finden Sie unter Apache Lucene Migration Guide die Einzelheiten dieserÄnderungen. Weitere Informationen finden Sie auch im Lucene Change Log.

Wenn Sie @Field(indexNullAs=) zum Kodieren eines Nullmarker-Werts im Indexverwenden, muss der Typ des Markers kompatibel mit allen anderen Werten sein, die indemselben Feld indexiert werden. Beispielsweise war es bislang möglich, einen Nullwert fürnumerische Felder mittels der Zeichenkette »null« zu kodieren. Dies ist nicht mehr zulässig.Stattdessen müssen Sie eine Zahl wählen, die für den null-Wert steht, wie z.B. -1.

An der Facettierungs-Engine wurden deutliche Verbesserungen vorgenommen. Die meistenÄnderungen haben keine Auswirkungen auf die API. Die einzige nennenswerte Ausnahme ist,dass Sie nun alle Felder, die Sie bei der Facettierung verwenden möchten, mit denAnnotationen @Facet oder @Facets annotieren müssen.

Unbenannte und neu paketierte Klassen in Hibernate SearchNachfolgend sehen Sie eine Liste mit Hibernate Search Klassen, die neu paketiert oder umbenanntwurden.

Bisherige Pakete und Klassen Neue Pakete und Klassen

org.hibernate.search.Environment org.hibernate.search.cfg.Environment

org.hibernate.search.FullTextFilter org.hibernate.search.filter.FullTextFilter

org.hibernate.search.ProjectionConstants org.hibernate.search.engine.ProjectionConstants

org.hibernate.search.SearchException org.hibernate.search.exception.SearchException

org.hibernate.search.Version org.hibernate.search.engine.Version

Unbenannte und neu paketierte Klassen in Lucene


66

https://docs.jboss.org/hibernate/search/5.5/api/index.html

http://lucene.apache.org/core/5_3_0/MIGRATE.html


http://lucene.apache.org/core/5_3_0/changes/Changes.html

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. SieheApache 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 oderangepasste 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 SearchEine 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

Schnittstelle Beschreibung

org.hibernate.search.store.IndexShardingStrategy Veraltet ab Hibernate Search 4.4. Wirdmöglicherweise ab Search 5 entfernt. Verwenden Siestattdessen ShardIdentifierProvider.

org.hibernate.search.store.Workspace Diese Schnittstelle wird verlegt und sollte als nichtöffentliche API betrachtet werden. WeitereInformationen siehe HSEARCH-1915.

Veraltete Klassen in Hibernate Search

Klasse Beschreibung

org.hibernate.search.filter.FilterKey Angepasste Filter-Keys gelten als veraltet undwerden planmäßig aus Hibernate Search 6 entfernt.Ab Hibernate Search 5.1 werden Keys zum Cachenvon Lucene-Filtern automatisch basierend aufangegebenen Filterparametern berechnet.

org.hibernate.search.filter.StandardFilterKey Angepasste Filter-Keys gelten als veraltet undwerden planmäßig aus Hibernate Search 6 entfernt.Ab Hibernate Search 5.1 werden Keys zum Cachenvon Lucene-Filtern automatisch basierend aufangegebenen Filterparametern berechnet.

Veraltete Aufzählungen in Hibernate Search

Aufzählung Beschreibung

org.hibernate.search.annotations.FieldCacheType Entfernen Sie die veraltete Annotation CacheFromIndex. Siehe Veraltete Annotationenin Hibernate Search.


67

http://lucene.apache.org/core/4_10_2/


https://docs.jboss.org/hibernate/search/5.5/api/deprecated-list.html

https://docs.jboss.org/hibernate/search/5.5/api/org/hibernate/search/store/ShardIdentifierProvider.html

https://hibernate.atlassian.net/browse/HSEARCH-1915

Veraltete Annotationen in Hibernate Search

Annotation Beschreibung

org.hibernate.search.annotations.CacheFromIndex Entfernen Sie die Annotation. Ein Ersatz ist nichtnötig.

org.hibernate.search.annotations.Key Angepasste Filter-Cache-Keys sind eine veralteteFunktion und werden planmäßig aus HibernateSearch 6 entfernt. Ab Hibernate Search 5.1 werdenFilter-Cache-Keys automatisch basierend auf denFilterparametern berechnet, sodass es nicht mehrnötig ist, ein Key-Objekt anzugeben.

Veraltete Methoden in Hibernate Search

Methode Beschreibung

org.hibernate.search.FullTextSharedSessionBuilder.autoClose()

Kein Ersatz

org.hibernate.search.FullTextSharedSessionBuilder.autoClose(boolean)

Kein Ersatz

org.hibernate.search.cfg.IndexedMapping.cacheFromIndex(FieldCacheType… )

Dies wird ersatzlos entfernt.

org.hibernate.search.cfg.EntityDescriptor.getCacheInMemory()


org.hibernate.search.cfg.ContainedInMapping.numericField()

Rufen Sie stattdessen field().numericField() auf.

org.hibernate.search.cfg.EntityDescriptor.setCacheInMemory(Map<String, Object>)


org.hibernate.search.MassIndexer.threadsForSubsequentFetching(int)

Diese Methode wird entfernt.

org.hibernate.search.query.dsl.FuzzyContext.withThreshold(float)

Verwenden Sie FuzzyContext.withEditDistanceUpTo(int).

Veraltete Konstruktoren in Hibernate Search

Konstruktor Beschreibung

org.hibernate.search.cfg.NumericFieldMapping(PropertyDescriptor, EntityDescriptor, SearchMapping)

Verwenden Sie stattdessen NumericFieldMapping.NumericFieldMapping(String, PropertyDescriptor, EntityDescriptor, SearchMapping).


68

Änderungen mit Auswirkungen auf erweiterte IntegratorenDieser Abschnitt beschreibt Änderungen, die nicht Teil der öffentlichen API sind. Sie sollten keinerleiAuswirkungen auf normale Entwickler haben, da auf diese Artefakte nur von Integratoren zugegriffenwird, die das Hibernate Search Framework erweitern.

Die Aufzählungskonstanten IndexWriterSetting.MAX_THREAD_STATES und IndexWriterSetting.TERM_INDEX_INTERVAL sind veraltet. Sie beeinflussen, welcheEigenschaften aus der Konfiguration gelesen werden; dass diese nun fehlen, bedeutet, dassKonfigurationseigenschaften wie hibernate.search.Animals.2.indexwriter.term_index_interval = default nunignoriert werden. Die einzige Nebenwirkung ist die, dass die Eigenschaft nicht angewendet wird.

Die Schnittstelle SearchFactoryIntegrator ist nun veraltet. Sie sollten unverzüglichsämtlichen Code zu SearchIntegrator migrieren.

Die Klasse SearchFactoryBuilder ist nun veraltet. Verwenden Sie stattdessen SearchIntegrationBuilder.

The HSQuery.getExtendedSearchIntegrator() method has been deprecated. It might bepossible to use SearchIntegrator, but it is preferable to remove it altogether.

Die Methode DocumentBuilderIndexedEntity.getFieldCacheOption() ist nunveraltet. Es gibt keinen Ersatz.

Die Methode BuildContext.getIndexingStrategy() ist nun veraltet. Verwenden Siestattdessen BuildContext.getIndexingMode().

Die Methode DirectoryHelper.getVerifiedIndexDir(String, Properties, boolean) ist veraltet. Verwenden Sie stattdessen DirectoryHelper.getVerifiedIndexPath(java.lang.String, java.util.Properties, boolean).

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

Bisherige Pakete und Klassen Neue Pakete und Klassen

org.hibernate.search.engine.impl.SearchMappingBuilder

org.hibernate.search.engine.spi.SearchMappingHelper

org.hibernate.search.indexes.impl.DirectoryBasedIndexManager

org.hibernate.search.indexes.spi.DirectoryBasedIndexManager

org.hibernate.search.spi.MassIndexerFactory org.hibernate.search.batchindexing.spi.MassIndexerFactory

org.hibernate.search.spi.SearchFactoryBuilder org.hibernate.search.spi.SearchIntegratorBuilder

org.hibernate.search.spi.SearchFactoryIntegrator org.hibernate.search.spi.SearchIntegrator

5.9. MIGRIEREN VON ENTITY-BEANS ZU JPA

Unterstützung für EJB-Entity-Beans ist optional in Java EE 7, und sie werden in JBoss EAP 7 nicht


69

http://docs.jboss.org/hibernate/search/5.5/api/org/hibernate/search/backend/configuration/impl/IndexWriterSetting.html#MAX_THREAD_STATES

http://docs.jboss.org/hibernate/search/5.5/api/org/hibernate/search/backend/configuration/impl/IndexWriterSetting.html#TERM_INDEX_INTERVAL

http://docs.jboss.org/hibernate/search/5.5/api/org/hibernate/search/spi/SearchFactoryIntegrator.html

http://docs.jboss.org/hibernate/search/5.5/api/org/hibernate/search/spi/SearchIntegrator.html

http://docs.jboss.org/hibernate/search/5.5/api/org/hibernate/search/spi/SearchFactoryBuilder.html

http://docs.jboss.org/hibernate/search/5.5/api/org/hibernate/search/spi/SearchIntegratorBuilder.html

http://docs.jboss.org/hibernate/search/5.5/api/org/hibernate/search/query/engine/spi/HSQuery.html#getExtendedSearchIntegrator--

http://docs.jboss.org/hibernate/search/5.5/api/org/hibernate/search/spi/SearchIntegrator.html

http://docs.jboss.org/hibernate/search/5.5/api/org/hibernate/search/engine/spi/DocumentBuilderIndexedEntity.html#getFieldCacheOption--

http://docs.jboss.org/hibernate/search/5.5/api/org/hibernate/search/spi/BuildContext.html#getIndexingStrategy--

http://docs.jboss.org/hibernate/search/5.5/api/org/hibernate/search/spi/BuildContext.html#getIndexingMode--

http://docs.jboss.org/hibernate/search/5.5/api/org/hibernate/search/store/spi/DirectoryHelper.html#getVerifiedIndexDir-java.lang.String-java.util.Properties-boolean-

http://docs.jboss.org/hibernate/search/5.5/api/org/hibernate/search/store/spi/DirectoryHelper.html#getVerifiedIndexPath-java.lang.String-java.util.Properties-boolean-

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 dieKlasse 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 wurdespezifiziert mithilfe eines <entity>-Elements, das ein <persistence-type>-Unterelement mit demWert 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 JavaPersistence 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; }


70

https://docs.oracle.com/javaee/7/api/index.html?javax/persistence/package-summary.html

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

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

5.10. ÄNDERUNGEN DER JPA-PERSISTENZEIGENSCHAFT

Eine neue Persistenzeigenschaft namens jboss.as.jpa.deferdetach wurde hinzugefügt, umKompatibilitä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 istdas 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 zuJBoss EAP 7 migrieren, müssen Sie den Eigenschaftswert jboss.as.jpa.deferdetach auf trueeinstellen in Ihrer persistence.xml, wie im folgenden Beispiel veranschaulicht.

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 Änderungennötig, wenn Sie Ihre Applikation migrieren.

public void setLastName(String lastName) { this.lastName = lastName; }

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

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


71


5.11. MIGRIEREN VON EJB-CLIENT-CODE

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 altenEinstellungen bewahrt, sodass die unten beschriebenen Änderungen nicht notwendig sind. Wenn Sieallerdings die neue JBoss EAP 7 Standardkonfiguration ausführen, müssen Sie die folgendenÄnderungen vornehmen.

5.11.1. Aktualisieren des standardmäßigen Remote-Verbindungsports

Ä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 vorherigenund in der aktuellen Release.

Beispiel: JBoss EAP 6 jboss-ejb-client.properties Datei

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

Beispiel: JBoss EAP 7 jboss-ejb-client.properties Datei

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

5.11.2. Aktualisieren des Standard-Connectors

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

Falls eine Client-Applikation die EJB-Client-Bibliothek von JBoss EAP 6 verwendet und miteinem JBoss EAP 7 Server verbinden will, dann muss der Server dazu konfiguriert sein, einen remote-Connector auf einem anderen Port als 8080 verfügbar zu machen. Der Client mussdann mit dem neu konfigurierten Connector verbinden.

Eine Client-Applikation, die die EJB-Client-Bibliothek von JBoss EAP 7 verwendet und miteinem JBoss EAP 6 Server verbinden will, muss darüber informiert sein, dass die Server-Instanznicht den http-remoting-Connector verwendet, sondern einen remote-Connector. Dieserreichen Sie, indem Sie eine neue clientseitige Verbindungseigenschaft definieren.


72

remote.connection.default.protocol=remote

5.11.3. Migrieren von Remote-Naming-Client-Code

Falls Sie die neue standardmäßige JBoss EAP 7 Konfiguration ausführen, müssen Sie Ihren Client-Codezur 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 JBossEAP 6 spezifiziert wurden.

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

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

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

5.12. MIGRIEREN VON DEPLOYMENT-PLAN-KONFIGURATIONEN

Die Java EE Spezifikation für Applikations-Deployment (JSR-88) wurde dazu entworfen, um einenVertrag zu definieren, der es Tools verschiedener Anbieter ermöglichen sollte, Applikationen auf jederbeliebigen Java EE Plattform zu konfigurieren und bereitzustellen. Der Vertrag erforderte von denAnbietern 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 ihreeigenen, funktionsreicheren Deployment-Lösungen bereitstellten. Aus diesem Grund wurde dieUnterstü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 theapplication. The JBoss EAP management CLI deploy command provides a standard way to deployarchives to standalone servers or to server groups in a managed domain. For more information aboutthe management CLI, see the Management CLI Guide.

5.13. MIGRIEREN VON ANGEPASSTEN APPLIKATIONS-VALVES

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


73

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/management-cli-guide/

WICHTIG

Angepasste Valves und solche Valves, die in der jboss-web.xml-Datei definiert sind,müssen neu geschrieben oder ersetzt werden durch den jeweiligen integrierten Undertow-Handler. Informationen über die Zuordnung von Valves zu Undertow-Handlern finden Sieunter Migrieren von JBoss Web Valves.

Authentifikations-Valves müssen manuell ersetzt werden durch die integrierten Undertow-Authentifizierungsmechanismen.

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

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

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

Migrieren von angepassten Authentifikations-ValvesWeitere Informationen über die Migration von Authentifikations-Valves finden Sie unterSicherheitsrelevante Applikationsänderungen

5.14. SICHERHEITSRELEVANTE APPLIKATIONSÄNDERUNGEN

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

5.14.1. Migrieren von Authentifikations-Valves

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

5.14.2. Änderungen an PicketLink

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

5.14.3. Sonstige sicherheitsrelevante Applikationsänderungen

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


74

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/development-guide/#creating_custom_handler

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/how-to-set-up-sso-with-saml-v2/#picketlink-changes-from-prev-version

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

5.15. ÄNDERUNGEN AN DER JBOSS-PROTOKOLLIERUNG

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 desneuen Pakets ändern müssen.

Die Annotationen wurden zudem in eine separate Maven groupId:artifactId:version (GAV) IDverlegt, 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.

ANMERKUNG

Nur die Logging-Annotationen wurden verlegt. Die org.jboss.logging.BasicLogger und org.jboss.logging.Logger befindensich weiterhin im org.jboss.logging-Paket.

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

Tabelle 5.1. Ersatz für veraltete Logging-Annotationen

Veraltete Klasse Ersatzklasse

org.jboss.logging.Cause org.jboss.logging.annotations.Cause

org.jboss.logging.Field org.jboss.logging.annotations.Field

org.jboss.logging.FormatWith org.jboss.logging.annotations.FormatWith

org.jboss.logging.LoggingClass org.jboss.logging.annotations.LoggingClass

org.jboss.logging.LogMessage org.jboss.logging.annotations.LogMessage

org.jboss.logging.Message org.jboss.logging.annotations.Message

org.jboss.logging.MessageBundle org.jboss.logging.annotations.MessageBundle

org.jboss.logging.MessageLogger org.jboss.logging.annotations.MessageLogger

org.jboss.logging.Param org.jboss.logging.annotations.Param

org.jboss.logging.Property org.jboss.logging.annotations.Property

5.16. JAVASERVER FACES (JSF) CODE-ÄNDERUNGEN

Beendete Unterstützung für JSF 1.2


75

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/how-to-set-up-sso-with-kerberos/#differences_from_configuring_previous_versions_jboss_eap

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.2verwendet, müssen Sie diese auf JSF 2.2 umschreiben.

Kompatibilitätsprobleme zwischen JSF 2.1 und JSF 2.2Die 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 eineInline-Ersetzung durch – Code, der für eine Release kompiliert wurde, kann nicht für eine anderenRelease funktionieren.

Applikationen, die ähnlichen Code wie im folgenden Beispiel enthalten und mit der JSF 2.1 APIkompiliert 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 dieApplikation mit der JSF 2.2 API neu kompilieren.

Siehe JAVASERVERFACES_SPEC_PUBLIC-1257 für weitere Informationen.

5.17. ÄNDERUNGEN AM MODUL-KLASSENLADEN

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

Angenommen es gibt zwei Module, MODULE_A und MODULE_B, die voneinander abhängen und zum Teildie gleichen Pakete enthalten. In JBoss EAP 6 hatten die Klassen oder Pakete, die von denAbhängigkeiten geladen wurden, Vorrang vor jenen, die im resource-root der module.xml-Dateiangegeben wurden. Das bedeutet, dass MODULE_A die Pakete für MODULE_B sah und MODULE_B diePakete 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ängigkeitspezifiziert werden. Das bedeutet, dass MODULE_A die Pakete für MODULE_A sieht und MODULE_B diePakete 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 containclasses 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 classis used. This can be accomplished by using either of the following approaches.

Sie können vermeiden, ein resource-root anzugeben, das doppelte Klassen in derModulabhängigkeit definiert.

Sie können die Subelemente include und exclude der Elemente imports und exportsverwenden, um das Klassenladen in der module.xml-Datei zu steuern. Nachfolgend sehenSie ein Export-Element, das Klassen in dem angegebenen Paket ausschließt.

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


76

https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1257

Falls Sie es vorziehen, Ihr derzeitiges Verhalten beizubehalten, müssen Sie die Pakete derAbhä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 mancheSchleifen, 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.

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

5.18. ÄNDERUNGEN DES APPLIKATIONS-CLUSTERINGS

5.18.1. Überblick über neue Clustering-Features

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

JBoss EAP 7 introduces a new public API for building singleton services that significantlysimplifies the process. For more information, see Implement an HA Singleton in Developing EJBApplications for JBoss EAP.

A singleton deployment can be configured to deploy and start on only a single node in the clusterat a time. For more information, see HA Singleton Deployments in the JBoss EAP DevelopmentGuide.

You can now define clustered singleton MDBs. For more information, see Clustered SingletonMDBs in Developing EJB Applications for JBoss EAP.

JBoss EAP 7 includes the Undertow mod_cluster implementation. This offers a pure Java loadbalancing solution that does not require an httpd web server. For more information, seeConfiguring JBoss EAP as a Front-end Load Balancer in the JBoss EAP Configuration Guide.

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

5.18.2. Änderungen des Web-Session-Clusterings

JBoss EAP 7 führt eine neue Implementierung für Web-Session-Clustering ein. Diese ersetzt dievorherige 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 Konfigurationder Applikation in der jboss-web.xml JBoss proprietären Webapplikation-XML-Deskriptordatei. Dienachfolgend aufgeführten sind die einzigen, in der Datei noch verbliebenen Clustering-Konfigurationselemente.

<exports> <exclude path="com/mycompany/duplicateclassespath/"/></exports>

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


77

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/development-guide/#class_loading_and_modules

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/developing-ejb-applications/#implement_an_ha_singleton

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/development-guide/#ha_singleton_deployments

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/developing-ejb-applications/#clustered_singleton_mdbs

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/configuration-guide/#configuring_jboss_eap_load_balancer

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

Konfigurationselement Beschreibung der Änderung

<max-active-sessions/> Bislang schlug die Session-Erstellung fehl, falls dadurch die Anzahl deraktiven Sessions den in <max-active-sessions/> definierten Wertüberstiegen worden wäre.

In der neuen Implementierung wird <max-active-sessions/> dazuverwendet, um Session-Passivierung zu ermöglichen. Falls durch dieErstellung einer neuen Session die Anzahl der aktiven Sessions den <max-active-sessions/> Wert übersteigen würde, so wird die älteste, demSession-Manager bekannte Session passiviert, um Platz für die neueSession zu schaffen.

<passivation-config/> Dieses Konfigurationselement und dessen Unterelemente werden in JBossEAP 7 nicht mehr verwendet.

<use-session-passivation/> Bislang wurde die Passivierung mithilfe dieses Attributs ermöglicht.

In der neuen Implementierung wird die Passivierung aktiviert, indem einnicht negativer Wert für <max-active-sessions/> definiert wird.

<passivation-min-idle-time/> Bislang mussten Sessions mindestens für eine bestimmte Zeitspanne aktivsein, bevor sie für eine Passivierung in Frage kamen. Dadurch war esmöglich, dass die Session-Erstellung fehlschlug, selbst wenn diePassivierung aktiviert war.

Die neue Implementierung unterstützt diese Logik nicht und vermeidetdadurch diese Denial of Service (DoS) Schwachstelle.

<passivation-max-idle-time/> Bislang wurde eine Session passiviert, sobald Sie für eine bestimmteZeitspanne inaktiv war.

Die neue Implementierung unterstützt nur eine reaktive Passivierung, keineaktive Passivierung. Sessions werden nur passiviert, wenn dies erforderlichist, um <max-active-sessions/> einzuhalten.

<replication-config/> In der neuen Implementierung gelten eine Reihe von Unterelementen nunals veraltet.

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


78

<replication-trigger/> Previously, this element was used to determine when session replicationwas triggered. The new implementation replaces this configuration optionwith a single, robust strategy. For more information, see Immutable SessionAttributes in the JBoss EAP Development Guide.

<use-jk/> Bislang wurde die instance-id des Knotens, der die jeweilige Anfragehandhabte, der jsessionid angefügt (um dann von Lastverteilern wiemod_jk, mod_proxy_balancer und mod_cluster verwendet zu werden),abhängig von dem für <use-jk/> angegebenen Wert.

In der neuen Implementierung wird die instance-id, sofern definiert,immer der jsessionid angefügt.

<max-unreplicated-interval/> Bislang diente diese Konfigurationsoption der Optimierung, um dieReplikation eines Session-Timestamps zu verhindern, wenn kein Session-Attribut verändert wurde. Theoretisch war dies sinnvoll, praktischverhinderte es jedoch keine RPCs, da der Session-Zugriff nach wie vorRPCs für die Cache-Transaktion erforderte, unabhängig davon, ob Session-Attribute verändert wurden oder nicht.

In der neuen Implementierung wird der Timestamp einer Session bei jederAnfrage repliziert. Dies verhindert veraltete Session-Metadaten nach einemFailover.

<snapshot-mode/> Bislang konnte man <snapshot-mode/> als INSTANT oder INTERVAL konfigurieren. Durch die asynchrone Replikation von Infinispanwird diese Konfigurationsoption jedoch hinfällig.

<snapshot-interval/> Dies war nur relevant für <snapshot-mode>INTERVAL</snapshot-mode>. Da <snapshot-mode/> jedoch hinfällig ist, wurde diese Optionebenfalls obsolet.

<session-notification-policy/> Bislang definierte der Wert dieses Attributs eine Richtlinie zum Auslösenvon Session-Ereignissen.

In der neuen Implementierung ist dieses Verhalten spezifikationsabhängigund nicht konfigurierbar.

Konfigurationselement Beschreibung der Änderung

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

5.18.3. Änderungen am Stateful Session EJB Clustering

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

Sie konnten die org.jboss.ejb3.annotation.Clustered-Annotation in der Session-Bean hinzufügen.


79

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/development-guide/#immutable_session_attributes

Sie konnten das <clustered>-Element zur jboss-ejb3.xml-Datei hinzufügen.

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

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

Sie können das standardmäßige Verhalten für eine einzelne Stateful Session Bean mithilfe von @Stateful(passivationCapable=false) deaktivieren; dies ist neu in der EJB 3.2Spezifikation.

Sie können dieses Verhalten global deaktivieren in der Konfiguration des ejb3-Subsystems inder Serverkonfiguration.

ANMERKUNG

Falls die @Clustered-Annotation nicht von der Applikation entfernt wird, so wird sieeinfach ignoriert und hat keine Auswirkungen auf die Applikation.

5.18.4. Änderungen des Clustering-Services

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

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

Die neue org.wildfly.clustering.group.Group-Schnittstelle bietet Zugang zumaktuellen Cluster-Status und ermöglicht das Lauschen auf Änderungen der Cluster-Mitgliedschaft.

Die neue org.wildfly.clustering.dispatcher.CommandDispatcher-Schnittstelleermöglicht das Ausführen von Code im Cluster, entweder auf allen Knoten oder auf einerUntergruppe ausgewählter Knoten.

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

@Stateful@Clusteredpublic class MyBean implements MySessionInt {

public void myMethod() { // }}

<c:clustering> <ejb-name>DDBasedClusteredSFSB</ejb-name> <c:clustered>true</c:clustered></c:clustering>


80

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

5.18.5. Migrieren des Clustering-HA-Singletons

In JBoss EAP 6 gab es keine öffentliche API für den clusterweiten HA-Singleton-Service. Wenn Sie dieprivaten org.jboss.as.clustering.singleton.* Klassen verwendet haben, müssen Sie für dieMigration 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 theDevelopment Guide for JBoss EAP.


81

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/development-guide/#public_API_for_clustering-services

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/development-guide/#clustered_ha_singleton_service

KAPITEL 6. SONSTIGE ÄNDERUNGEN

6.1. ÄNDERUNGEN BEI DER LIEFERUNG VON JBOSS EAP NATIVESUND APACHE HTTP SERVER

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

Die folgende Tabelle listet die Unterschiede in den Lieferungsmethoden zwischen denVersionen auf.

Paket JBoss EAP 6 JBoss EAP 7

AIO Natives fürMessaging

Wird in einem separaten "NativeUtilities" Download mit dem Produktgeliefert

In der JBoss EAP Distributioninbegriffen. Zusätzlicher Download istnicht erforderlich.

Apache HTTPServer

Wird in einem separaten "ApacheHTTP Server" Download mit demProdukt geliefert

Wird mit dem neuen Produkt JBossCore Services geliefert

mod_cluster,mod_jk, isapi undnsapiKonnektoren

Wird in einem separaten "WebserverConnector Natives" Download mitdem Produkt geliefert


JSVC Wird in einem separaten "NativeUtilities" Download mit dem Produktgeliefert


OpenSSL Wird in einem separaten "NativeUtilities" Download mit dem Produktgeliefert

Dies wurde in JBoss EAP7weggelassen

tcnatives Wird in einem separaten "NativeComponents" Download mit demProdukt geliefert

Dies wurde in JBoss EAP7weggelassen

Sie sollten sich zudem folgender Änderungen bewusst sein:

Die Unterstützung für mod_cluster and mod_jk Konnektoren, die mit Apache HTTP Servervon Red Hat Enterprise Linux RPM-Channels verwendet werden, wurde eingestellt. WennSie den Apache HTTP Server von Red Hat Enterprise Linux RPM-Channels aus ausführenund Lastverteilung für JBoss EAP 7 Server konfigurieren müssen, können Siefolgendermaßen vorgehen:

Verwenden Sie den Apache HTTP Server, der von JBoss Core Services bereitgestelltwird.


82

You can configure JBoss EAP 7 to act as a front-end load balancer. For moreinformation, see Configuring JBoss EAP as a Front-end Load Balancer in the JBossEAP Configuration Guide.

You can deploy Apache HTTP Server on a machine that is supported and certified andthen run the load balancer on that machine. For the list of supported configurations, seeOverview of HTTP Connectors in the JBoss EAP 7 Configuration Guide.

Die Unterstützung für mod_cluster and mod_jk Konnektoren, die mit dem Apache HTTPServer von HP-UX Web Server Suites verwendet wurden, wurde eingestellt. Wenn Sie denApache HTTP Server von HP-UX Web Server Suites aus verwenden und Lastverteilung fürJBoss EAP 7 Server konfigurieren müssen, können Sie folgendermaßen vorgehen:

You can configure JBoss EAP 7 to act as a front-end load balancer. For moreinformation, see Configuring JBoss EAP as a Front-end Load Balancer in the JBossEAP Configuration Guide.

You can deploy Apache HTTP Server on a machine that is supported and certified andthen run the load balancer on that machine. For the list of supported configurations, seeOverview of HTTP Connectors in the JBoss EAP Configuration Guide.

You can find more information about JBoss Core Services in the Apache HTTP ServerInstallation Guide.

6.2. ÄNDERUNGEN AN DEPLOYMENTS AUF AMAZON EC2

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

Die Art und Weise, wie geclusterte und nicht geclusterte JBoss EAP Instanzen und Domains inAmazon EC2 gestartet werden, hat sich grundlegend geändert.

JBoss EAP 6 verwendete das Feld User Data: zur JBoss EAP Konfiguration. Die AMI-Skipte,welche die Konfiguration im Feld User Data: analysierten und beim Instanzenstartautomatisch die Server starteten, wurden aus JBoss EAP 7 entfernt.

Der Red Hat JBoss Operations Network Agent wurde in der vorherigen Version von JBoss EAPautomatisch mit installiert. In JBoss EAP 7 müssen Sie diesen separat installieren.

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

6.3. ÄNDERUNGEN AN JBOSS EAP SKRIPTEN

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

6.4. ENTFERNUNG DER OSGI-UNTERSTÜTZUNG

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 Statuseiner Technologievorschau verloren und wird nicht mehr unterstützt.

KAPITEL 6. SONSTIGE ÄNDERUNGEN

83


https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/configuration-guide/#overview_http_connectors


https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/configuration-guide/#overview_http_connectors

https://access.redhat.com/documentation/en/red-hat-jboss-core-services-apache-http-server/2.4/single/apache-http-server-installation-guide/#about_red_hat_jboss_core_services

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/deploying-red-hat-jboss-enterprise-application-platform-on-amazon-ec2/

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/configuration-guide/#setting_add_user_password_restrictions

In JBoss EAP 6.1.0 wurden die configadmin- und osgi-Erweiterungsmodule undSubsystemkonfigurationen für einen Standalone-Server in die separate Konfigurationsdatei EAP_HOME/standalone/configuration/standalone-osgi.xml verlegt. Da Sie diese nichtunterstützte Konfigurationsdatei nicht migrieren sollten, dürfte die Entfernung der JBoss OSGiUnterstützung keine Auswirkungen auf die Migration einer Standalone-Serverkonfiguration haben. FallsSie andere Standalone-Konfigurationsdateien zum Konfigurieren von osgi oder configadminverä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 DateiEAP_HOME/domain/configuration/domain.xml. Diese Konfiguration wird in JBoss EAP 7 nichtmehr unterstützt und muss entfernt werden.


84

KAPITEL 7. MIGRIEREN VON ÄLTEREN JBOSS EAPRELEASES

7.1. MIGRIEREN VON JBOSS EAP 5 ZU JBOSS EAP 7

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

1. Werfen Sie einen Blick auf Zusammenfassung der Änderungen an jeder Release in diesemHandbuch für eine Zusammenfassung der Änderungen an jeder JBoss EAP Release.

2. Lesen Sie das JBoss EAP 6 Migrationshandbuch sowie dieses Handbuch, um sich mit denInhalten beider Handbücher vertraut zu machen.

3. Verwenden Sie die JBoss EAP 5 Component Upgrade Reference als Referenz fürMigrationsinformationen über bestimmte Komponenten und Features.

4. Das regelbasierte Windup-Migrationstool fügt weiterhin Regeln hinzu, um Ihnen bei der direktenMigration von JBoss EAP 5 zu JBoss EAP 7 zu helfen. Sie können dieses Tool verwenden, umIhre Applikation zu analysieren und um detaillierte Berichte über die Änderungen zu generieren,die für die Migration zu JBoss EAP 7 erforderlich sind. Weitere Informationen finden Sie unterVerwenden von Windup zur Analyse von Applikationen zur Migration.

5. Die Kundenportal Knowledgebase enthält derzeit Artikel und Lösungen, die bei der Migrationvon JBoss EAP 5 zu JBoss EAP 6 helfen. Im Laufe der Zeit sollen weitere Inhalte hinzugefügtwerden, welche die Migration von JBoss EAP 5 zu JBoss EAP 7 behandeln.

7.2. ZUSAMMENFASSUNG DER ÄNDERUNGEN AN JEDER RELEASE

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

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

Neue Architektur basierend auf dem Modular Service Container implementiert

Zertifizierte Implementierung der Java Enterprise Edition 6 Spezifikation

Domain-Management, neue Deployment-Konfiguration sowie neue Verzeichnisstruktur undSkripte eingeführt

Auf neue portierbare JNDI-Namespaces standardisiert

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

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

KAPITEL 7. MIGRIEREN VON ÄLTEREN JBOSS EAP RELEASES

85

https://access.redhat.com/documentation/de-DE/JBoss_Enterprise_Application_Platform/6.4/html-single/Migration_Guide/index.html

https://access.redhat.com/search/#/knowledgebase?q=migration JBoss EAP 5 JBoss EAP 6&p=1&sort=relevant&rows=12&srch=any&product=Red Hat JBoss Enterprise Application Platform&language=en&documentKind=Solution,Article


https://access.redhat.com/documentation/de-DE/JBoss_Enterprise_Application_Platform/6.4/html-single/Migration_Guide/index.html#Review_Whats_New_and_Different_in_JBoss_Enterprise_Application_Platform_61

Unterstützung für die Java Enterprise Edition 7 Spezifikation hinzugefügt

Webserver durch Undertow ersetzt

JacORB IIOP-Implementierung durch eine Downstream-Branch des OpenJDK ORB ersetzt

Enthält Apache ActiveMQ Artemis als neuen Messaging-Provider

Entfernt die Subsysteme cmp, jaxr und threads

Entfernt Unterstützung für EJB Entity Beans

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

7.3. LESEN DER MIGRATIONSHANDBÜCHER

Lesen Sie das gesamte Migrationshandbuch für jede Release, um über neue oder veraltete Features imBilde zu sein und um die Serverkonfigurationen und Änderungen an Applikationen zu erfahren, dienotwendig 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, habenviele der im JBoss EAP 6 Migrationshandbuch dokumentierten Änderungen noch Gültigkeit.Beispielsweise beziehen sich die in Von den meisten Applikationen benötigte Änderungendokumentierten Änderungen auf die Neuerungen der zugrunde liegenden Architektur in JBoss EAP 6,und treffen somit ebenfalls auf diese Release zu. Die Änderungen am neuen, modularenKlassenladersystem sind beträchtlich und wirken sich auf die Paketierung und die Abhängigkeiten vonfast allen JBoss EAP 5 Applikationen aus. Viele der unter Von Ihrer Applikationsarchitektur und -komponenten abhängige Änderungen aufgeführten Änderungen gelten ebenfalls weiterhin. Da JBossEAP 7 jedoch den Webserver, ORB und Messaging-Provider ersetzt hat, die cmp, threads und jaxrSubsysteme entfernt sowie Unterstützung für EJB Entity Beans gestoppt hat, müssen Sie diesesHandbuch für jegliche Änderungen hinsichtlich dieser Komponenten zu Rate ziehen. Achten Siebesonders auf die Änderungen der Serverkonfiguration und die Änderungen bei Applikationsmigration,die in diesem Handbuch beschrieben werden, bevor Sie beginnen.

7.4. LISTE DER JBOSS EAP 5 KOMPONENTEN-UPGRADES

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

JBoss EAP 5Feature oderKomponente

Zusammenfassung der Änderungen und Links zu Migrationsinformationen


86


https://access.redhat.com/documentation/de-DE/JBoss_Enterprise_Application_Platform/6.4/html-single/Migration_Guide/index.html#sect-Changes_Required_by_Most_Applications

https://access.redhat.com/documentation/de-DE/JBoss_Enterprise_Application_Platform/6.4/html-single/Migration_Guide/index.html#sect-Changes_Dependent_on_Your_Application_Architecture_and_Components

Packen der Applikationund Klassenladen

In JBoss EAP 6 wurde die bisherige hierarchische Klassenladestruktur ersetztdurch eine modulare Architektur basierend auf JBoss Modules. Das Packen vonApplikationen hat sich ebenfalls geändert aufgrund der neuen modularenKlassenladestruktur. Diese Architektur wird auch in JBoss EAP 7 verwendet.Weitere Informationen über die neue modulare Architektur finden Sie im folgendenKapitel im JBoss EAP 7 Development Guide.

Class Loading and Modules

Informationen über das Aktualisieren und Neupacken von Applikationen für diemodulare Architektur finden Sie im folgenden Abschnitt im JBoss EAP 6Migrationshandbuch.

Änderungen beim Klassenladen

Applikations-Konfigurationsdateien

Due to the changes in JBoss EAP 6 to use modular class loading, you might needto create or modify one or more application configuration files to adddependencies or to prevent automatic dependencies from loading. This has notchanged in JBoss EAP 7. For details, see the following section in the JBoss EAP6 Migration Guide.

Änderungen bei Konfigurationsdateien

Caching und Infinispan JBoss Cache wurde ersetzt durch Infinispan zum internen Gebrauch durch denServer in JBoss EAP 6. In den folgenden Abschnitten im JBoss EAP 6Migrationshandbuch finden Sie Informationen darüber, wie JBoss Cache imApplikationscode ersetzt werden muss.

Cache-Änderungen (auf Englisch)

Die Änderungen an der Infinispan-Caching-Strategie und -Konfiguration für JBossEAP 7 werden im folgenden Abschnitt dieses Handbuchs erläutert.

Änderungen der Infinispan-Serverkonfiguration

Datenquellen undRessourcenadapter

JBoss EAP 6 konsolidierte die Konfiguration von Datenquellen undRessourcenadaptern in hauptsächlich eine Datei, und dies ist nach wie vor derFall in JBoss EAP 7. Im folgenden Abschnitt des JBoss EAP 6Migrationshandbuch finden Sie weitere Informationen.

Konfigurationsänderungen bei Datenquellen und Ressourcenadaptern

Darüber hinaus wird die Fähigkeit zur Konfiguration eines generischen JMS-Ressourcenadapters zur Verbindung mit einem JMS-Provider in JBoss EAP 7nicht mehr unterstützt. Siehe folgenden Abschnitt in diesem Handbuch.

Liste veralteter und nicht unterstützter Features




87

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/development-guide/#class_loading_and_modules

https://access.redhat.com/documentation/de-DE/JBoss_Enterprise_Application_Platform/6.4/html-single/Migration_Guide/index.html#sect-Class_Loading_Changes

https://access.redhat.com/documentation/de-DE/JBoss_Enterprise_Application_Platform/6.4/html-single/Migration_Guide/index.html#sect-Configuration_File_Changes

https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.4/html-single/Migration_Guide/index.html#sect-Cache_Changes

https://access.redhat.com/documentation/de-DE/JBoss_Enterprise_Application_Platform/6.4/html-single/Migration_Guide/index.html#sect-Datasource_and_Resource_Adapter_Configuration_Changes

Verzeichnisstruktur,Skripte und Deployment-Konfiguration

In JBoss EAP 6 haben sich Verzeichnisstruktur, Skripte und Deployment-Konfiguration geändert. Diese Änderungen gelten auch weiterhin in JBoss EAP 7.Weitere Informationen finden Sie im folgenden Abschnitt des JBoss EAP 6Migrationshandbuchs.

Was ist neu und anders bei der JBoss EAP 6?

EJB Die Java EE 7 Spezifikation machte EJB 2.x und frühere Features optional,weshalb wir dringend empfehlen, Ihren Applikationscode zur Verwendung derEJB 3.x Spezifikation und JPA umzuschreiben. Informationen über veralteteFeatures und Änderungen, die zum Ausführen von EJB 2.x notwendig sind, findenSie im folgenden Abschnitt im JBoss EAP 6 Migrationshandbuch.

EJB 2.x und frühere Änderungen (auf Englisch)

In JBoss EAP 6 wird der Stateful EJB Cache und die Größe des Stateless SessionBean-Pools nun im ejb3-Subsystem der Serverkonfigurationsdatei konfiguriert.Der jboss-ejb3.xml-Deployment-Deskriptor ersetzt die jboss.xml-Deployment-Deskriptor-Datei. Weitere Informationen über diese Änderungenfinden Sie im folgenden Abschnitt des JBoss EAP 6 Migrationshandbuchs.

EJB 2.x Änderungen

Der standardmäßige Remote-Connector und Port wurde in JBoss EAP 7geändert. Weitere Informationen dazu und über Serverkonfigurationsänderungenfinden Sie in den folgenden Abschnitten dieses Handbuchs.

Änderungen der EJB-Serverkonfiguration

Migrieren von EJB-Client-Code

EJB Entity Beans werden in JBoss EAP 7 nicht unterstützt. Informationen überdas Migrieren von Entity Beans zu JPA finden Sie in dem folgenden Abschnittdieses Handbuchs.

Migrieren von Entity-Beans zu JPA




88

https://access.redhat.com/documentation/de-DE/JBoss_Enterprise_Application_Platform/6.4/html-single/Migration_Guide/index.html#Review_Whats_New_and_Different_in_JBoss_Enterprise_Application_Platform_61

https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.4/html-single/Migration_Guide/index.html#sect-EJB_2.x_and_Earlier_Changes

https://access.redhat.com/documentation/de-DE/JBoss_Enterprise_Application_Platform/6.4/html-single/Migration_Guide/index.html#sect-EJB_Changes

Hibernate und JPA In JBoss EAP 6 wurde Hibernate von Version 3 auf Version 4 aktualisiert. DieseVersion von JBoss EAP implementierte zudem die JPA 2.0 Spezifikation und anJPA-Persistenzeigenschaften wurden Änderungen vorgenommen. Informationendarüber, wie Sie Ihre Applikationen an diese Änderungen anpassen, finden Sie imfolgenden Abschnitt des JBoss EAP 6 Migrationshandbuchs.

Hibernate- und JPA-Änderungen

JBoss EAP 7 implementiert JPA 2.1 und enthält Hibernate 5. Es aktualisiertHibernate Search von Version 4.6.x auf Version 5.5.x. Andere Änderungen sindu.a. die Entfernung der Unterstützung für EJB Entity Beans und zusätzlicheAktualisierungen an JPA-Persistenzeigenschaften. Informationen darüber, wiesich diese Änderungen auf Ihre Applikationen auswirken, finden Sie in denfolgenden Abschnitten in diesem Handbuch.

Änderungen hinsichtlich Hibernate und JPA

Änderungen hinsichtlich Hibernate Search

Migrieren von Entity-Beans zu JPA

Änderungen der JPA-Persistenzeigenschaft

JAX-RS und RESTEasy JBoss EAP 6 integrierte RESTEasy 2, was automatisch RESTEasy konfiguriertund Änderungen an Ihrer Applikationskonfiguration erforderlich macht. In demfolgenden Abschnitt im JBoss EAP 6 Migrationshandbuch finden Sie weitereInformationen.

JAX-RS- und RESTEasy-Änderungen

JBoss EAP 7 enthält RESTEasy 3, und weitere Klassen gelten nun als veraltet.Die Jackson-Version hat sich von Version 1.9.9 auf Version 2.6.3 oder höhergeändert. Einzelheiten über diese Änderungen finden Sie im folgenden Abschnittdieses Handbuchs.

Änderungen der JAX-RS und RESTEasy-Applikation

JBoss AOP JBoss AOP (Aspect Oriented Programming) wurde aus JBoss EAP 6 entfernt.Informationen darüber, wie Applikationen refaktoriert werden müssen, die JBossAOP verwenden, finden Sie im folgenden Abschnitt des JBoss EAP 6Migrationshandbuchs.

JBoss AOP Änderungen




89

https://access.redhat.com/documentation/de-DE/JBoss_Enterprise_Application_Platform/6.4/html-single/Migration_Guide/index.html#sect-Hibernate_and_JPA_Changes

https://access.redhat.com/documentation/de-DE/JBoss_Enterprise_Application_Platform/6.4/html-single/Migration_Guide/index.html#sect-JAX-RS_and_RESTEasy_Changes

https://access.redhat.com/documentation/de-DE/JBoss_Enterprise_Application_Platform/6.4/html-single/Migration_Guide/index.html#sect-JBoss_AOP_Changes

JGroups und Clustering Die Art und Weise, wie Clustering aktiviert und Bind-Adressen angegeben werden,hat sich JBoss EAP 6 geändert. Im folgenden Abschnitt im JBoss EAP 6Migrationshandbuch finden Sie weitere Informationen.

Clustering-Änderungen

In JBoss EAP 7 verwendet JGroups nun standardmäßig eine privateNetzwerkschnittstelle anstelle einer öffentlichen Netzwerkschnittstelle, und es führt<channel>-Elemente im jgroups-Subsystem ein. JBoss EAP 7 enthält zudemdie Undertow mod_cluster-Implementierung, und es führt eine neue API zumErstellen von Singleton-Diensten sowie andere Clustering-Features ein. DieseÄnderungen werden in den folgenden Abschnitten dieses Handbuchs erläutert.

Änderungen der JGroups-Serverkonfiguration

Änderungen des Applikations-Clusterings

JNDI JBoss EAP 6 implementierte einen neuen, standardisierten, globalen JNDI-Namespace sowie eine Reihe zugehöriger Namespaces, die den verschiedenenBereichen einer Java EE Applikation zugewiesen sind. In dem folgendenAbschnitt des JBoss EAP 6 Migrationshandbuchs finden Sie Informationen überdie erforderlichen Applikationsänderungen, um die neuen JNDI-Namespace-Regeln zu verwenden.

JNDI-Änderungen

JSF JBoss EAP 6 enthielt JSF 2.0 und ermöglichte es Ihnen, Ihre Applikation zurVerwendung einer älteren Version zu konfigurieren. Dies ist in JBoss EAP 7 – wasJSF 2.2 enthält – nicht mehr möglich. Der folgende Abschnitt in diesem Handbuchliefert weitere Informationen.

JavaServer Faces (JSF) Code-Änderungen




90

https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.4/html-single/Migration_Guide/index.html#sect-Clustering_Changes

https://access.redhat.com/documentation/de-DE/JBoss_Enterprise_Application_Platform/6.4/html-single/Migration_Guide/index.html#sect-JNDI_Changes

Protokollierung JBoss EAP 6 introduced a new JBoss Logging framework that is still used in JBossEAP 7. Applications that use third-party logging frameworks might be impacted bythe modular class loading changes. Review the following section in the JBossEAP 6 Migration Guide for information about these changes.

Protokolländerungen

In JBoss EAP 7 gelten Annotationen im org.jboss.logging-Paket nun alsveraltet, was Auswirkungen auf den Quellcode und auf Maven GAVs(groupId:artifactId:version) hat. Die Präfixe für alle Protokollnachrichten wurdenebenfalls geändert. Weitere Informationen über diese Änderungen finden Sie inden folgenden Abschnitten in diesem Handbuch.

Änderungen an der JBoss-Protokollierung

Geänderte Präfixe für Protokolleinträge

Messaging und JMS In JBoss EAP 6 ersetzte HornetQ das JBoss Messaging als standardmäßige JMS-Implementierung. In JBoss EAP 7 ersetzt ActiveMQ Artemis nun HornetQ alsintegrierten Messaging-Provider.

Der beste Ausgangspunkt zur Migration Ihrer Messaging-Konfiguration ist dieJBoss EAP 7 Standard-Serverkonfiguration, auf die Sie anhand des folgendenLeitfadens Ihre aktuellen Messaging-Konfigurationsänderungen anwenden sollten.

Configuring Messaging for JBoss EAP 7

Falls Sie die erforderlichen Änderungen für den Wechsel von JBoss Messagingnach HornetQ besser verstehen möchten, werfen Sie einen Blick auf denfolgenden Abschnitt des JBoss EAP 6 Migrationshandbuchs.

HornetQ-Änderungen

Lesen Sie anschließend die folgenden Informationen über die Migration derHornetQ-Konfiguration und der zugehörigen Messaging-Daten in diesemHandbuch.

Änderungen der Messaging-Serverkonfiguration

Änderungen der Messaging-Applikation




91

https://access.redhat.com/documentation/de-DE/JBoss_Enterprise_Application_Platform/6.4/html-single/Migration_Guide/index.html#sect-Logging_Changes

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/configuring-messaging/

https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.4/html-single/Migration_Guide/index.html#sect-HornetQ_Changes

ORB In JBoss EAP 6 wurde die JacORB-Konfiguration aus der EAP_HOME/server/production/conf/jacorb.properties-Datei indie Server-Konfigurationsdatei verlegt. JBoss EAP 7 ersetzte dann die JacORBIIOP-Implementierung durch eine Downstream-Branch des OpenJDK ORB.

Der beste Ausgangspunkt zur Migration Ihrer ORB-Konfiguration ist die JBossEAP 7 Standard-Serverkonfiguration, auf die Sie anhand des JBoss EAP 7Configuration Guide Ihre aktuellen ORB-Konfigurationsänderungen anwendensollten.

ORB Configuration

Remote-Aufruf Eine neue EJB-Client-API wurde in JBoss EAP 6 eingeführt für Remote-Aufrufe;falls Sie es allerdings vorzogen, Ihren Applikationscode nicht zur Verwendung derneuen API umzuschreiben, konnten Sie Ihren vorhandenen Code ändern, um die ejb:BEAN_REFERENCE für Remote-Zugriff auf EJBs zu verwenden. Imfolgenden Abschnitt des JBoss EAP 6 Migrationshandbuchs erhalten Sie weitereInformationen.

Änderungen bei Remote-Aufrufen

In JBoss EAP 7 hat sich der Standard-Connector und der Standard-Remote-Verbindungsport geändert. Weitere Informationen finden Sie in den folgendenAbschnitten in diesem Handbuch.

Änderungen des Remote-URL-Connectors und -Ports

Aktualisieren der externen JMS-Clients

Migrieren von EJB-Client-Code

Seam 2.x Obwohl die offizielle Unterstützung für Seam 2.2 Applikationen in JBoss EAP 6aufgegeben wurde, war es nach wie vor möglich, Abhängigkeiten für JSF 1.2 undHibernate 3 zu konfigurieren, damit Seam 2.2 Applikationen auf dieser Releaseausgeführt werden konnten. JBoss EAP 7 enthält nun JSF 2.2 und Hibernate 5; esunterstützt weder Seam 2.2 noch Seam 2.3, da das Red Hat JBoss WebFramework Kit das Ende seines Produktlebenszyklus erreicht hat. Wir empfehlen,Ihre Seam-Komponenten umzuschreiben zur Verwendung von Weld CDI Beans.




92

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/configuration-guide/#orb_configuration

https://access.redhat.com/documentation/de-DE/JBoss_Enterprise_Application_Platform/6.4/html-single/Migration_Guide/index.html#sect-Remote_Invocation_Changes

Sicherheit Sicherheitsaktualisierungen in JBoss EAP 6 umfassten Änderungen an denNamen von Sicherheitsdomains und Änderungen bei der Konfiguration derSicherheit für einfache Authentifizierung. Die Konfiguration des LDAP-Sicherheitsbereichs wurde in die Server-Konfigurationsdatei verlegt. In denfolgenden Abschnitten des JBoss EAP 6 Migrationshandbuchs finden Sie weitereInformationen.

Sicherheitsänderungen

Änderungen des LDAP-Sicherheitsbereichs

Aktualisierungen, die Auswirkungen auf die Sicherheit in JBoss EAP 7 haben, sindunter anderem Server-Konfigurationsänderungen und Applikationsänderungen.Informationen finden Sie in den folgenden Abschnitten dieses Handbuchs.

Sicherheitsrelevante Server-Konfigurationsänderungen

Sicherheitsrelevante Applikationsänderungen

Spring-Applikationen Spring 4.2.x ist die früheste, stabile Spring-Version, die von JBoss EAP 7unterstützt wird. In den folgenden Abschnitten dieses Handbuchs finden SieInformationen über Apache CXF Spring Webservices und Spring RESTEasyIntegrationsänderungen.

Änderungen der Apache CXF Spring Webservices

Änderungen der Spring RESTEasy-Integration

Transaktionen JBoss EAP 6 konsolidierte die Transaktionskonfiguration und verlegte sie in dieServer-Konfigurationsdatei. Weitere Aktualisierungen betrafen Änderungen an denJTA-Knotenbezeichner-Einstellungen und die Art und Weise, wie JTS aktiviertwird. Details hierzu finden Sie im folgenden Abschnitt des JBoss EAP 6Migrationshandbuchs.

JTS and JTA Changes (auf English)

Einige der Konfigurationsparameter für den Transaktionsmanager, die im transactions-Subsystem in JBoss EAP 6 verfügbar waren, haben sich inJBoss EAP 7 geändert. Weitere Informationen finden Sie in den folgendenAbschnitten in diesem Handbuch.

Migrate Transactions Subsystem Changes




93

https://access.redhat.com/documentation/de-De/JBoss_Enterprise_Application_Platform/6.4/html-single/Migration_Guide/index.html#sect-Security_Changes

https://access.redhat.com/documentation/de-DE/JBoss_Enterprise_Application_Platform/6.4/html-single/Migration_Guide/index.html#sect-LDAP_Security_Realm_Changes

https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.4/html-single/Migration_Guide/index.html#sect-JTS_and_JTA_Changes

Valves Undertow ersetzte JBoss Web in JBoss EAP 7 und Valves werden nicht mehrunterstützt. Siehe die folgenden Abschnitte in diesem Handbuch.

Migrieren von globalen Valves

Migrieren von angepassten Applikations-Valves

Migrieren von Authentifikations-Valves

Web-Dienste JBoss EAP 6 enthielt JBossWS 4. Informationen über die erforderlichenÄnderungen für die aktualisierte Version finden Sie im folgenden Abschnitt imJBoss EAP 6 Migrationshandbuch.

Web-Dienste Änderungen

JBoss EAP 7 führte JBossWS 5 ein. In dem folgenden Abschnitt in diesemHandbuch sind die erforderlichen Aktualisierungen aufgeführt.

Änderungen der Webservices-Applikation




94

https://access.redhat.com/documentation/de-DE/JBoss_Enterprise_Application_Platform/6.4/html-single/Migration_Guide/index.html#sect-Web_Services_Changes

ANHANG A. REFERENZMATERIAL

A.1. WARNUNGEN DER MIGRATION-OPERATION FÜR DAS JACORB-SUBSYSTEM

The migrate operation is not able to process all resources and attributes. The following table lists someof the warnings you might see when you run either the migrate or describe-migration operationfor the jacorb subsystem.

ANMERKUNG

Falls Sie »Could not migrate« oder »Can not migrate« Einträge in der Ausgabe der migrate-Operation entdecken, bedeutet hin, dass die Migration der Serverkonfigurationerfolgreich abgeschlossen wurde, jedoch nicht alle Elemente und Attribute automatischmigriert werden konnten. Sie müssen den Empfehlungen der »migration-warnings«Empfehlungen folgen, um diese Konfigurationen anzupassen.

Warnmeldung Bedeutung/Lösung

The iiop migration can be performed when theserver is in admin-only mode (Die iiop-Migration kann ausgeführt werden, wenn der Serverim admin-only-Modus läuft)

Die migrate-Operation erfordert, dass der Serverim Modus admin-only gestartet wird. Sieerreichen dies, indem Sie den Parameter --admin-only zum Server-Startbefehl hinzufügen:

$ EAP_HOME/bin/standalone.sh --admin-only

Properties X cannot be emulated using OpenJDKORB and are not supported (Eigenschaften X könnennicht mithilfe von OpenJDK ORB emuliert werden undwerden nicht unterstützt)

Die Konfiguration der angegebenen Eigenschaft wirdnicht unterstützt und ist nicht in der neuen iiop-openjdk Subsystemkonfiguration enthalten. DasVerhalten, das von dieser Eigenschaft in dervorherigen Release von JBoss EAP gezeigt wurde,wird nicht migriert und der Administrator muss sichvergewissern, ob das neue iiop-openjdk-Subsystem in JBoss EAP 7 dazu in der Lage ist,ohne dieses Verhalten erwartungsgemäß zufunktionieren.

Nicht unterstützte Eigenschaften sind unter anderem:cache-poa-names, cache-typecodes, chunk-custom-rmi-valuetypes, client-timeout, comet, indirection-encoding-disable, iona, lax-boolean-encoding, max-managed-buf-size, max-server-connections, max-threads, outbuf-cache-timeout, outbuf-size, queue-max, queue-min, poa-monitoring, print-version, retries, retry-interval, queue-wait, server-timeout, strict-check-on-tc-creation, use-bom, use-imr.


95

The properties X use expressions. Configurationproperties that are used to resolve those expressionsshould be transformed manually to the new iiop-openjdk subsystem format (Die Eigenschaften Xverwenden Ausdrücke. Konfigurationseigenschaften,die zum Auslösen dieser Ausdrücke verwendetwerden, sollten manuell in das neue iiop-openjdk-Subsystemformat umgewandelt werden)

Eigenschaften, die Ausdrücke verwenden, müssenmanuell vom Administrator konfiguriert werden.

Beispielsweise definierte das jacorb-Subsystem inJBoss EAP 6 eine giop-minor-version-Eigenschaft. Das iiop-openjdk-Subsystem inJBoss EAP 7 definiert eine giop-version-Eigenschaft. Angenommen, dass Nebenversion-Attribut des jacorb-Subsystems ist auf ${iiop-giop-minor-version} eingestellt und dieSystemeigenschaft ist in der standalone.conf-Datei als -Diiop-giop-minor-version=1konfiguriert. Nach der migrate-Operation muss derAdministrator den Wert der Systemeigenschaft auf 1.1 setzen, um sicherzustellen, dass das neueSubsystem richtig konfiguriert ist.

Can not migrate: the new iiop-openjdksubsystem is already defined (Kann nicht migrieren:das neue iiop-openjdk-Subsystem ist bereitsdefiniert)

Diese Meldung ist selbsterklärend.


A.2. WARNUNGEN DER MIGRATION-OPERATION FÜR DASMESSAGING-SUBSYSTEM

The migrate operation is not able to process all resources and attributes. The following table lists someof the warnings you might see when you run either the migrate or describe-migration operationfor the messaging subsystem.

ANMERKUNG



The migrate operation can not be performed: theserver must be in admin-only mode (Die migrate-Operation kann nicht ausgeführt werden:der Server muss im admin-only-Modus laufen)




96

Can not migrate attribute local-bind-addressfrom resource X. Use instead the socket-binding attribute to configure this broadcast-group. (Attribut local-bind-address vonRessource X kann nicht migriert werden. VerwendenSie stattdessen das socket-binding-Attribut, umdiese broadcast-group zu konfigurieren.)

Diese Meldung ist selbsterklärend und nennt dieLösung.

Can not migrate attribute local-bind-port fromresource X. Use instead the socket-bindingattribute to configure this broadcast-group.(Attribut local-bind-port von Ressource Xkann nicht migriert werden. Verwenden Siestattdessen das socket-binding-Attribut, umdiese broadcast-group zu konfigurieren.)


Can not migrate attribute group-address fromresource X. Use instead the socket-bindingattribute to configure this broadcast-group.(Attribut group-address von Ressource X kannnicht migriert werden. Verwenden Sie stattdessendas socket-binding-Attribut, um diese broadcast-group zu konfigurieren.)


Can not migrate attribute group-port fromresource X. Use instead the socket-bindingattribute to configure this broadcast-group.(Attribut group-port von Ressource X kann nichtmigriert werden. Verwenden Sie stattdessen das socket-binding-Attribut, um diese broadcast-group zu konfigurieren.)

Die Ressource broadcast-group akzeptiertnicht mehr die Attribute local-bind-address, local-bind-port, group-address oder group-port. Sie akzeptiert ausschließlich ein socket-binding-Attribut. Die Warnung weistdarauf hin, dass die Ressource X ein nichtunterstütztes Attribut enthält. Sie müssen manuelldas socket-binding-Attribut auf der Ressourcedefinieren und sicherstellen, dass es auf einedefinierte socket-binding-Ressource verweist.

Klassen, die X bereitstellen, werden während derMigration verworfen. Um sie im neuen messaging-activemq-Subsystem zu verwenden, müssen Sieden Artemis-basierten Interceptor erweitern.

Die Unterstützung von Messaging-Interzeptoren hatsich in JBoss EAP 7 deutlich verändert. JeglicheInterzeptoren, die in der vorherigen Version desSubsystems konfiguriert wurden, werden währendder Migration verworfen. Siehe Migrieren vonMessaging-Interzeptoren für weitere Informationen.



97

Can not migrate the HA configuration of X. Its shared-store and backup attributes holdsexpressions and it is not possible to determineunambiguously how to create the corresponding ha-policy for the messaging-activemq’s server. (DieHA-Konfiguration von X kann nicht migriert werden.Deren Attribute shared-store und backupenthalten Ausdrücke, und es kann nicht eindeutigfestgestellt werden, wie die entsprechende ha-policy für den messaging-activemq-Server erstelltwerden soll.)

Dies bedeutet, dass die Attribute shared-storeoder backup von hornetq-server X einenAusdruck enthielten, wie z.B. ${xxx}, und dieMigrationsoperation war nicht dazu in der Lage,diesen Ausdruck eindeutig aufzulösen. Der Wert wirdverworfen und die ha-policy für messaging-activemq muss manuell aktualisiert werden.

Can not migrate attribute local-bind-addressfrom resource X. Use instead the socket-binding attribute to configure this discovery-group. (Attribut local-bind-address vonRessource X kann nicht migriert werden. VerwendenSie stattdessen das socket-binding-Attribut, umdiese discovery-group zu konfigurieren.)


Can not migrate attribute local-bind-port fromresource X. Use instead the socket-bindingattribute to configure this discovery-group.(Attribut local-bind-port von Ressource Xkann nicht migriert werden. Verwenden Siestattdessen das socket-binding-Attribut, umdiese discovery-group zu konfigurieren.)


Can not migrate attribute group-address fromresource X. Use instead the socket-bindingattribute to configure this discovery-group.(Attribut group-address von Ressource X kannnicht migriert werden. Verwenden Sie stattdessendas socket-binding-Attribut, um diese discovery-group zu konfigurieren.)


Can not migrate attribute group-port fromresource X. Use instead the socket-bindingattribute to configure this discovery-group.(Attribut group-port von Ressource X kann nichtmigriert werden. Verwenden Sie stattdessen das socket-binding-Attribut, um diese discovery-group zu konfigurieren.)

Die Ressource discovery-group akzeptiertnicht mehr die Attribute local-bind-address, local-bind-port, group-address oder group-port. Sie akzeptiert ausschließlich ein socket-binding-Attribut. Die Warnung weistdarauf hin, dass die Ressource X ein nichtunterstütztes Attribut enthält. Sie müssen manuelldas socket-binding-Attribut auf der Ressourcedefinieren und sicherstellen, dass es auf einedefinierte socket-binding-Ressource verweist.



98

Can not create a legacy-connection-factory based on connection-factory X. Ituses a HornetQ in-vm connector that is notcompatible with Artemis in-vm connector. (Eine legacy-connection-factory basierend auf connection-factory X kann nicht erstelltwerden. Sie verwendet einen HornetQ in-vmConnector, der nicht kompatibel ist mit dem Artemis in-vm Connector)

Die veralteten HornetQ Remote connection-factory-Ressourcen werden migriert zu legacy-connection-factory-Ressourcen, um JBossEAP 6 Clients die Verbindung mit JBoss EAP 7 zuermöglichen. Allerdings werden legacy-connection-factory-Ressourcen nur erstellt,wenn die connection-factory Remote-Connectors verwendet. Jegliche connection-factory, die in-vm verwendet, wird nicht migriert,da in-vm-Clients auf JBoss EAP 7 basieren, nichtauf JBoss EAP 6. Dieses Warnung weist darauf hin,dass die in-vm connection-factory nichtmigriert wurde.

Can not migrate attribute X from resource Y. Theattribute uses an expression that can be resolveddifferently depending on system properties. Aftermigration, this attribute must be added back with anactual value instead of the expression. (Attribut Xvon Ressource Y kann nicht migriert werden. DasAttribut verwendet einen Ausdruck, der abhängig vonden Systemeigenschaften unterschiedlich aufgelöstwerden kann. Nach der Migration muss diesesAttribut manuell mit dem tatsächlichen Wert anstelledes Ausdrucks wieder hinzugefügt werden.)

Diese Warnung erscheint, wenn die Migration dasAttribut X während des Migrationsvorgangs nicht ineinen konkreten Wert auflösen kann. Der Wert wirdverworfen und das Attribut muss manuell migriertwerden. Dies tritt in den folgenden Situationen auf:

cluster-connection forward-when-no-consumers:Diese boolesche Variable wurde ersetztdurch das message-load-balancing-type-Attribut, bei dem essich um eine Enumeration mit denmöglichen Werten OFF, STRICT oder ON_DEMAND handelt.

Für broadcast-group und discovery-group die Attribute jgroups-stack und jgroups-channelSie referenzieren andere Ressourcen undJBoss EAP 7 akzeptiert diese Ausdrückenicht mehr.

Can not migrate attribute X from resource Y. Thisattribute is not supported by the new messaging-activemq subsystem. (Attribut X von Ressource Ykann nicht migriert werden. Dieses Attribut wird vondem neuen messaging-activemq-Subsystemnicht unterstützt.)

Einige Attribute werden im neuen messaging-activemq-Subsystem nicht mehr unterstützt undwerden einfach verworfen:

failback-delay-Attribut von hornetq-server

use-nio-Attribut von http-connector

use-nio-Attribut von http-acceptor

use-nio-Attribut von remote-connector

use-nio-Attribut von remote-acceptor



99

Can not migrate attribute failback-delay fromresource X. Artemis detects failback deterministicallyand it no longer requires to specify a delay forfailback to occur. (Attribut failback-delay vonRessource X kann nicht migriert werden. Artemiserkennt Failback deterministisch und benötigt keinefestgelegte Wartezeit mehr zum Auslösen einesFailbacks.)



Replace the Deprecated broadcast-group or discovery-group Attributes (Ersetzen Sie dieveralteten Attribute »broadcast-group« oder »discovery-group«)Wenn Sie angewiesen werden, die veralteten Attribute broadcast-group oder discovery-groupdurch das socket-binding-Attribut zu ersetzen, können Sie das neue Attribut mithilfe derManagement-CLI hinzufügen.

Für dieses Beispiel nehmen wir an, dass Sie einen Standalone-Server migrieren, der die folgende discovery-group-Konfiguration im messaging-Subsystem enthält.

Wenn Sie die migrate-Operation für das messaging-Subsystem ausführen, sehen Sie die folgendeAusgabe und Warnungen:

Die migrate-Operation erstellt eine discovery-group namens »my-discovery-group« im neuen messaging-activemq-Subsystem, das nun wie folgt konfiguriert ist.

<discovery-groups> <discovery-group name="my-discovery-group"> <group-address>224.0.1.105</group-address> <group-port>56789</group-port> </discovery-group></discovery-groups>

[standalone@localhost:9999 /] /subsystem=messaging:migrate{ "outcome" => "success", "result" => {"migration-warnings" => [ "WFLYMSG0084: Can not migrate attribute group-address from resource [ (\"subsystem\" => \"messaging-activemq\"), (\"server\" => \"default\"), (\"discovery-group\" => \"my-discovery-group\")]. Use instead the socket-binding attribute to configure this discovery-group.", "WFLYMSG0084: Can not migrate attribute group-port from resource [ (\"subsystem\" => \"messaging-activemq\"), (\"server\" => \"default\"), (\"discovery-group\" => \"my-discovery-group\")]. Use instead the socket-binding attribute to configure this discovery-group." ]}}


100

Anschließend müssen Sie den folgenden Management-CLI-Befehl ausführen, um ein socket-binding-Element in der Server-Konfigurationsdatei namens »my-discovery-group-socket-binding« zuerstellen.

/socket-binding-group=standard-sockets/socket-binding=my-discovery-group-socket-binding:add(multicast-address=224.0.1.105, multicast-port=56789)

Fügen Sie als Nächstes das neu erstellte socket-binding zur discovery-group namens »my-discovery-group« im messaging-activemq-Subsystem in der Server-Konfigurationsdatei hinzu.Verwenden Sie dazu den folgenden Management-CLI-Befehl:

/subsystem=messaging-activemq/server=default/discovery-group=my-discovery-group:write-attribute(name=socket-binding,value=my-discovery-group-socket-binding)

Diese Befehle erstellen das folgende XML in der Server-Konfigurationsdatei.

A.3. WEB SUBSYSTEM MIGRATION OPERATION WARNINGS

The migrate operation is not able to process all resources and attributes. The following table lists someof the warnings you might see when you run either the migrate or describe-migration operationfor the web subsystem.

ANMERKUNG


<discovery-group name="my-discovery-group"/>

<subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0"> <server name="default"> ... <discovery-group name="my-discovery-group" socket-binding="my-discovery-group-socket-binding"/> ... </server></subsystem>...<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}"> ... <socket-binding name="my-discovery-group-socket-binding" multicast-address="224.0.1.105" multicast-port="56789"/> ...</socket-binding-group>


101


Migrate operation only allowed in admin only mode(Migrations-Operation nur im »admin-only«-Moduserlaubt)



Could not migrate resource X (Ressource X konntenicht migriert werden)

Das Verhalten, das diese Ressource in dervorherigen Release von JBoss EAP zeigte, wurdenicht migriert. Der Administrator muss überprüfen, obdas neue undertow-Subsystem in JBoss EAP 7dazu in der Lage ist, ohne dieses Verhalten zufunktionieren, oder ob dieses Verhalten manuellmigriert werden muss.

Could not migrate attribute X from resource Y.(Attribut X von Ressource Y konnte nicht migriertwerden.)

Das Verhalten, das dieses Ressourcenattribut in dervorherigen Release von JBoss EAP zeigte, wurdenicht migriert. Der Administrator muss überprüfen, obdas neue undertow-Subsystem in JBoss EAP 7dazu in der Lage ist, ohne dieses Verhalten zufunktionieren, oder ob dieses Verhalten manuellmigriert werden muss.

See Web Subsystem Migration Operation AttributeWarnings for the list of attributes that are notmigrated.

Could not migrate SSL connector as no SSL config isdefined (SSL-Connector konnte nicht migriertwerden, da keine SSL-Konfiguration definiert ist)


Could not migrate verify-client attribute X tothe Undertow equivalent (verify-client-AttributX konnte nicht zum Undertow-Äquivalent migriertwerden)


Could not migrate verify-client expression X(verify-client Ausdruck X konnte nicht migriertwerden)



102

Could not migrate valve X (Valve X konnte nichtmigriert werden)

Das Verhalten, das diese Valve in der vorherigenRelease von JBoss EAP zeigte, wurde nicht migriert.Der Administrator muss überprüfen, ob das neue undertow-Subsystem in JBoss EAP 7 dazu in derLage ist, ohne dieses Verhalten zu funktionieren,oder ob dieses Verhalten manuell migriert werdenmuss.

This warning can occur for the following valves:

org.apache.catalina.valves.RemoteAddrValveEs muss mindestens einen erlaubten oderverweigerten Wert haben.

org.apache.catalina.valves.RemoteHostValveEs muss mindestens einen erlaubten oderverweigerten Wert haben.

org.apache.catalina.authenticator.BasicAuthenticator

org.apache.catalina.authenticator.DigestAuthenticator

org.apache.catalina.authenticator.FormAuthenticator

org.apache.catalina.authenticator.SSLAuthenticator

org.apache.catalina.authenticator.SpnegoAuthenticator

Angepasste Valves



103

Could not migrate attribute X from valve Y. (AttributX von Valve Y konnte nicht migriert werden.)

The behavior exhibited by this valve attribute in theprevious release of JBoss EAP was not migrated.The administrator must verify if the new undertowsubsystem in JBoss EAP 7 is able to operatecorrectly without that behavior or whether thebehavior must be migrated manually. This warningcan occur for the following valve attributes:

org.apache.catalina.valves.AccessLogValve

resolveHosts

fileDateFormat

renameOnRotate

encoding

locale

requestAttributesEnabled

buffered

org.apache.catalina.valves.ExtendedAccessLogValve

resolveHosts

fileDateFormat

renameOnRotate

encoding

locale

requestAttributesEnabled

buffered

org.apache.catalina.valves.RemoteIpValve

httpServerPort

httpsServerPort

remoteIpHeaderFalls definiert, aber nicht auf »x-forwarded-for« eingestellt

protocolHeaderFalls definiert, aber nicht auf »x-forwarded-proto« eingestellt


Web Subsystem Migration Operation Attribute Warnings


104

The migrate operation is not able to process all JBoss Web attributes. See the following referencetables for information about how to migrate the unprocessed attributes manually.

Web SSL Connector AttributesThe following attributes were used in JBoss EAP 6 to configure the SSL connector. OpenSSL nativelibraries are not supported in JBoss EAP 7 so there are no equivalent settings.

Attribute Beschreibung Undertow Equivalent

ca-revocation-url The file or URL that contains therevocation list.

No equivalent in Undertow.

certificate-file When using OpenSSL encryption, thepath to the file containing the servercertificate.


ssl-protocol The SSL protocol string. No equivalent in Undertow.

verify-depth The maximum number of intermediatecertificate issuers checked beforedeciding that the clients do not have avalid certificate.


Web Static Resource AttributesThe following static-resources element attributes were used to describe how static resources werehandled by the DefaultServlet or by the WebdavServlet. There are no equivalents for theseattributes because WebDAV is not supported by Undertow. For more information, seehttps://issues.jboss.org/browse/JBEAP-1036.


disabled Enable the default Servlet mapping. No equivalent setting in Undertow.

file-encoding File encoding to be used when readingstatic files.

No equivalent setting in Undertow.

max-depth Maximum recursion for PROPFIND. This is a WebDAV setting andWebDAV is not supported byUndertow.

read-only Allow write HTTP methods (PUT,DELETE).

This is a WebDAV setting andWebDAV is not supported byUndertow.

secret Secret for WebDAV locking operations. This is a WebDAV setting andWebDAV is not supported byUndertow.

sendfile Enable sendfile if possible, for filesbigger than the specified byte size.

This is set to a sensible default value inUndertow and is not configurable.


105

https://issues.jboss.org/browse/JBEAP-1036

webdav Enable WebDAV functionality. WebDAV is not supported byUndertow.


Web SSO Resource AttributesSSO is handled differently than in the previous release and there are no equivalent attribute settings inJBoss EAP 7.

JBoss Web Attribute Beschreibung Undertow Equivalent

cache-container Name of the cache container to use forclustered SSO.

This setting is no longer needed inUndertow. This works by default acrossa distributed clustered environment.

cache-name Name of the cache to use for clusteredSSO.

This setting is no longer needed inUndertow. This works by default acrossa distributed clustered environment.

reauthenticate Whether each request should cause areauthentication.

There is no equivalent setting inUndertow, which behaves similarly tothe reauthenticate=true settingin JBoss EAP 6. While reauthenticate=false couldpossibly improve performance, it couldalso create security issues.

Web Access Log Attributes


resolve-hosts Whether to enable resolving hosts foraccess logging.

Use the setting on the connector toaccomplish the same behavior.

Web Connector Attributes


executor The name of the executor that shouldbe used to process the threads of thisconnector.

You now reference a worker that isdefined in the io subsystem.

See Migrate the Threads SubsystemConfiguration for more information.

proxy-binding The socket binding to define the hostand port that is used when sending aredirect.

There is no direct equivalent.

See https-listener Attributes in theJBoss EAP Configuration Guide foravailable configuration options.


106

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/configuration-guide/#https_listener_attributes

redirect-port The port for redirection to a secureconnector.

This attribute was deprecated in JBossEAP 6 and replaced with redirect-binding. Undertow provides the redirect-socket attribute on the http-listener element, which is areplacement for redirect-binding.

See https-listener Attributes in theJBoss EAP Configuration Guide formore information.


A.4. ÜBERSICHT ÜBER DAS MIGRIEREN VON JBOSS WEBSYSTEMEIGENSCHAFTEN

Diese Übersicht veranschaulicht die Systemeigenschaften, die bisher für die JBoss Web Konfigurationverwendet wurden, und deren entsprechende Konfiguration für Undertow in JBoss EAP 7.

Zuordnung von Servlet-Container- und Connector-Systemeigenschaften

Zuordnung von EL-Systemeigenschaften

Zuordnung von JSP-Systemeigenschaften

Zuordnung von Sicherheits-Systemeigenschaften

Tabelle A.1. Zuordnung von Servlet-Container- und Connector-Systemeigenschaften

JBoss EAP 6 Systemeigenschaft Beschreibung

Entsprechung in JBoss EAP 7

jvmRoute Provides a default value for the jvmRoute attribute. It does notoverride the automatically generated value when using the standalone-ha.xml configuration file.

It supports reload.

Management-CLI-Befehl:

/subsystem=undertow:write-attribute(name=instance-id,value=VALUE)

org.apache.tomcat.util.buf.StringCache.byte.enabled

Falls true, wird der String-Cache aktiviert für ByteChunk.Falls der Wert nicht angegeben ist, wird der Standardwert false verwendet.

Keine entsprechende Konfiguration


107

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/configuration-guide/#https_listener_attributes

org.apache.tomcat.util.buf.StringCache.char.enabled

Falls true, wird der String-Cache aktiviert für CharChunk.Falls der Wert nicht angegeben ist, wird der Standardwert false verwendet.


org.apache.tomcat.util.buf.StringCache.cacheSize

Die Größe des String-Caches. Falls der Wert nicht angegebenist, wird der Standardwert 5000 verwendet.


org.apache.tomcat.util.buf.StringCache.maxStringSize

Die maximale Länge des zu cachenden Strings. Falls der Wertnicht angegeben ist, wird der Standardwert 128 verwendet.


org.apache.tomcat.util.http.FastHttpDateFormat.CACHE_SIZE

Die Größe des Caches für analysierte und formatierteDatumswerte. Falls der Wert nicht angegeben ist, wird derStandardwert 1000 verwendet.


org.apache.catalina.core.StandardService.DELAY_CONNECTOR_STARTUP

Falls true, erfolgt der Connector-Start nicht automatisch. Diesist hilfreich im eingebetteten Modus.


org.apache.catalina.connector.Request.SESSION_ID_CHECK

Falls true, prüft der Servlet-Container, ob eine Session mit derangegebenen Session-ID in einem Kontext existiert, bevor eineSession mit dieser ID erstellt wird.


org.apache.coyote.Constants.USE_CUSTOM_STATUS_MSG_IN_HEADER

Falls true, werden angepasste HTTP-Statusnachrichteninnerhalb der HTTP-Header verwendet. Benutzer müssensichergehen, dass solche Nachrichten ISO-8859-1 kodiertsind, insbesondere falls Benutzereingaben in der Nachrichtenthalten sind, um eine mögliche XSS-Schwachstelle zuvermeiden. Falls der Wert nicht angegeben ist, wird derStandardwert false verwendet.

Muss befehlsorientiert aktiviert werden, indem eine angepasste io.undertow.servlet.ServletExtensionimplementiert wird. Verwenden Sie dann die Erweiterung, um setSendCustomReasonPhraseOnError(true) auf derio.undertow.servlet.api.DeploymentInfoStrukturinstanz aufzurufen.


108

https://access.redhat.com/webassets/avalon/d/red-hat-jboss-enterprise-application-platform/7.0.0/javadocs//io/undertow/servlet/ServletExtension.html

https://access.redhat.com/webassets/avalon/d/red-hat-jboss-enterprise-application-platform/7.0.0/javadocs//io/undertow/servlet/api/DeploymentInfo.html#setSendCustomReasonPhraseOnError-boolean-

https://access.redhat.com/webassets/avalon/d/red-hat-jboss-enterprise-application-platform/7.0.0/javadocs//io/undertow/servlet/api/DeploymentInfo.html

org.apache.tomcat.util.http.Parameters.MAX_COUNT

Die maximale Anzahl an Parametern, die in einem Post-Bodyanalysiert werden können. Wird diese überschritten, schlägt dieAnalyse mit einer IllegalStateException fehl. DerStandardwert ist 512 Parameter.


/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=max-parameters,value=VALUE)/subsystem=undertow/server=default-server/https-listener=default:write-attribute(name=max-parameters,value=VALUE)/subsystem=undertow/server=default-server/ajp-listener=default:write-attribute(name=max-parameters,value=VALUE)

org.apache.tomcat.util.http.MimeHeaders.MAX_COUNT

Die maximale Anzahl an Headern, die in der HTTP-Anfragegesendet werden können. Wird diese überschritten, schlägt dieAnalyse mit einer IllegalStateException fehl. DerStandardwert ist 128 Header.


/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=max-headers,value=VALUE)/subsystem=undertow/server=default-server/https-listener=default:write-attribute(name=max-headers,value=VALUE)/subsystem=undertow/server=default-server/ajp-listener=default:write-attribute(name=max-headers,value=VALUE)

org.apache.tomcat.util.net.MAX_THREADS

Die maximale Anzahl an Threads, die ein Connector zurVerarbeitung von Anfragen verwenden wird. Der Standardwertist 32 x 512. (512 x Runtime.getRuntime().availableProcessors()für den JIO Connector)


/subsystem=io/worker=default:write-attribute(name=task-max-threads, value=VALUE)


109

org.apache.coyote.http11.Http11Protocol.MAX_HEADER_SIZE

Die maximale Größe der HTTP-Header in Bytes. Wird dieseüberschritten, schlägt die Analyse mit einer ArrayOutOfBoundsException fehl. Der Standardwert ist 8192 Bytes.


/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=max-header-size,value=VALUE)/subsystem=undertow/server=default-server/https-listener=default:write-attribute(name=max-header-size,value=VALUE)/subsystem=undertow/server=default-server/ajp-listener=default:write-attribute(name=max-header-size,value=VALUE)

org.apache.coyote.http11.Http11Protocol.COMPRESSION

Erlaubt die Verwendung einfacher Komprimierung mit demHTTP-Connector. Der Standardwert ist off. Verwenden Sie denWert on, um die Komprimierung bedingt zu aktivieren, oder force, um sie immer zu aktivieren.

Konfigurieren Sie einen Filter mithilfe der Management-CLI:

# Create a filter/subsystem=undertow/configuration=filter/gzip=gzipfilter:add()/subsystem=undertow/server=default-server/host=default-host/filter-ref=gzipfilter:add()

org.apache.coyote.http11.Http11Protocol.COMPRESSION_RESTRICTED_UA

Reguläre Ausdrücke für Benutzer-Agents, die keinekomprimierten Inhalte erhalten werden. Der Standardwert istleer.

Konfigurieren Sie ein Prädikat in einem Filter mithilfe derManagement-CLI:

# Use a predicate in a filter/subsystem=undertow/configuration=filter/gzip=gzipfilter:add()/subsystem=undertow/server=default-server/host=default-host/filter-ref=gzipfilter:add(predicate="regex[pattern='AppleWebKit',value=%{i,User-Agent}]")


110

org.apache.coyote.http11.Http11Protocol.COMPRESSION_MIME_TYPES

Präfixe für Inhaltstypen von komprimierbarem Inhalt. DerStandardwert ist text/html,text/xml,text/plain.


# Use a predicate in a filter/subsystem=undertow/configuration=filter/gzip=gzipfilter:add()/subsystem=undertow/server=default-server/host=default-host/filter-ref=gzipfilter:add(predicate="regex[pattern='text/html',value=%{o,Content-Type}]")

org.apache.coyote.http11.Http11Protocol.COMPRESSION_MIN_SIZE

Mindestgröße von Inhalten, die komprimiert werden. DerStandardwert ist 2048 Bytes.


# Use a predicate in a filter/subsystem=undertow/configuration=filter/gzip=gzipfilter:add()/subsystem=undertow/server=default-server/host=default-host/filter-ref=gzipfilter:add(predicate="max-content-size[value=MIN_SIZE]")

org.apache.coyote.http11.DEFAULT_CONNECTION_TIMEOUT

Standardmäßiger Socket-Timeout. Der Standardwert ist 60000ms.


/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=no-request-timeout,value=VALUE)/subsystem=undertow/server=default-server/https-listener=default:write-attribute(name=no-request-timeout,value=VALUE)/subsystem=undertow/server=default-server/ajp-listener=default:write-attribute(name=no-request-timeout,value=VALUE)


111

org.jboss.as.web.deployment.DELETE_WORK_DIR_ONCONTEXTDESTROY

Verwenden Sie diese Eigenschaft, um .java und .classDateien zu entfernen und so sicherzustellen, dass JSP-Quellenneu kompiliert werden. Der Standardwert ist false. Standard-Socket-Timeout für keep-alive. Der Standardwert lautet -1ms, was bedeutet, dass der Standard-Socket-Timeoutverwendet wird.


org.apache.tomcat.util.buf.StringCache.trainThreshold

Gibt an, wie oft toString() aufgerufen werden muss, bevorder Cache aktiviert wird. Der Standardwert lautet 100000.


Tabelle A.2. Zuordnung von EL-Systemeigenschaften



org.apache.el.parser.COERCE_TO_ZERO

If true, when coercing expressions to numbers, empty strings("") and null will be coerced to zero as required by thespecification. If a value is not specified, the default value of true is used.

Systemeigenschaft ist noch gültig und wird von der ELverarbeitet

Tabelle A.3. Zuordnung von JSP-Systemeigenschaften



org.apache.jasper.compiler.Generator.VAR_EXPRESSIONFACTORY

Der Name der Variable, die für die Expression Factory derExpression Language verwendet wird. Falls kein Wertangegeben ist, wird der Standardwert _el_expressionfactory verwendet.

Systemeigenschaft hat sich nicht verändert

org.apache.jasper.compiler.Generator.VAR_INSTANCEMANAGER

Der Name der Variable, die für die Instanz-Manager-Factoryverwendet wird. Falls kein Wert angegeben ist, wird derStandardwert _jsp_instancemanager verwendet.



112

org.apache.jasper.compiler.Parser.STRICT_QUOTE_ESCAPING

Falls false, wird die Anforderung, dass Anführungszeichen inJSP-Attributen mit Fluchtsymbolen versehen sein müssen,gelockert, sodass ein fehlendes erforderlichesAnführungszeichen keinen Fehler verursacht. Falls kein Wertangegeben ist, wird der spezifikationskonforme Standardwert true verwendet.


org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE

Jeglicher Tag-Puffer, der org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE übersteigt, wird gelöscht und ein neuer Puffer mitder Standardgröße wird erstellt. Falls kein Wert angegeben ist,wird der Standardwert 512 verwendet.


org.apache.jasper.runtime.JspFactoryImpl.USE_POOL

Falls true, wird ein ThreadLocal PageContext-Pool verwendet.Falls kein Wert angegeben ist, wird der Standardwert trueverwendet.


org.apache.jasper.runtime.JspFactoryImpl.POOL_SIZE

Die Größe des Thread-lokalen PageContext. Falls kein Wertangegeben ist, wird der Standardwert 8 verwendet.


org.apache.jasper.Constants.JSP_SERVLET_BASE

Die Basisklasse des Servlets, generiert vom JSP. Falls keinWert angegeben ist, wird der Standardwert org.apache.jasper.runtime.HttpJspBaseverwendet.


org.apache.jasper.Constants.SERVICE_METHOD_NAME

Der Name der Servicemethode, die von der Basisklasseaufgerufen wird. Falls kein Wert angegeben ist, wird derStandardwert _jspService verwendet.


org.apache.jasper.Constants.SERVLET_CLASSPATH

Der Name des ServletContext-Attributs, das den Klassenpfad fürJSP liefert. Falls kein Wert angegeben ist, wird der Standardwertorg.apache.catalina.jsp_classpath verwendet.



113

org.apache.jasper.Constants.JSP_FILE Der Name des Anfrageattributs für das <jsp-file>-Elementeiner Servlet-Definition. Falls auf einer Anfrage vorhanden,überschreibt dies den Wert, der von request.getServletPath() zurückgegeben wird, zurAuswahl der auszuführenden JSP-Seite. Falls kein Wertangegeben ist, wird der Standardwert org.apache.catalina.jsp_file verwendet.


org.apache.jasper.Constants.PRECOMPILE

Der Name des Anfrageparameters, der die JSP-Engine dazuveranlasst, das Servlet bereits zu generieren, jedoch nichtaufzurufen. Falls kein Wert angegeben ist, wird derStandardwert org.apache.catalina.jsp_precompileverwendet.


org.apache.jasper.Constants.JSP_PACKAGE_NAME

Der standardmäßige Paketname für kompilierte JSP-Seiten.Falls kein Wert angegeben ist, wird der Standardwert org.apache.jsp verwendet.


org.apache.jasper.Constants.TAG_FILE_PACKAGE_NAME

Der standardmäßige Paketname für Tag-Handler, generiert vonTag-Dateien. Falls kein Wert angegeben ist, wird derStandardwert org.apache.jsp.tag verwendet.


org.apache.jasper.Constants.TEMP_VARIABLE_NAME_PREFIX

Zu verwendendes Präfix für generierte temporäreVariablennamen. Falls kein Wert angegeben ist, wird derStandardwert _jspx_temp verwendet.


org.apache.jasper.Constants.USE_INSTANCE_MANAGER_FOR_TAGS

Falls true, wird der Instanzenmanager dazu verwendet, umTag-Handler-Instanzen zu beziehen. Falls kein Wert angegebenist, wird der Standardwert true verwendet.


org.apache.jasper.Constants.INJECT_TAGS

Falls true, werden in Tags spezifizierte Annotationenverarbeitet und eingespeist. Dies kann Auswirkungen auf diePerformance haben, wenn einfache Tags verwendet werdenoder wenn Tag-Pooling deaktiviert ist. Falls kein Wertangegeben ist, wird der Standardwert false verwendet.



114

Tabelle A.4. Zuordnung von Sicherheits-Systemeigenschaften



org.apache.catalina.connector.RECYCLE_FACADES

Falls true oder falls ein Sicherheitsmanager eingesetzt wird, sowird für jede Anfrage ein neues Fassaden-Objekt erstellt. Fallskein Wert angegeben ist, wird der Standardwert falseverwendet.


org.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH

Falls true, ist das »\« Zeichen als Pfadtrennzeichen zulässig.Falls kein Wert angegeben ist, wird der Standardwert falseverwendet.


org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH

Falls true, sind »%2F« und »%5C« als Pfadtrennzeichenzulässig. Falls kein Wert angegeben ist, wird der Standardwert false verwendet.


/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=allow-encoded-slash,value=VALUE)/subsystem=undertow/server=default-server/https-listener=default:write-attribute(name=allow-encoded-slash,value=VALUE)/subsystem=undertow/server=default-server/ajp-listener=default:write-attribute(name=allow-encoded-slash,value=VALUE)


115

org.apache.catalina.STRICT_SERVLET_COMPLIANCE

Falls kein Wert angegeben ist, wird true verwendet. Falls true, hat dies folgende Auswirkungen: Jegliches in einemWrapper eingeschlossene Anfrage- oder Antwortobjekt, das aneinen Applikations-Dispatcher übergeben wird, wird überprüft umsicherzustellen, dass die Originalanfrage oder -antworteingeschlossen wurde. (SRV.8.2 / SRV.14.2.5.1) Falls keineZeichenkodierung definiert wurde, verursacht ein Aufruf von Response.getWriter() für nachfolgende Aufrufe von Response.getCharacterEncoding() den Wert ISO-8859-1, und der Content-Type-Anfrage-Header enthält dieKomponente charset=ISO-8859-1 (SRV.15.2.22.1) JedeAnfrage, die mit einer Session verknüpft ist, verursacht eineAktualisierung des Zeitstempels für den letzten Zugriff auf dieseSession, ungeachtet dessen, ob die Anfrage ausdrücklich aufdiese Session zugreift. (SRV.7.6)

Standardmäßig konform

org.apache.catalina.core.StandardWrapperValve.SERVLET_STATS

Falls true oder fallsorg.apache.catalina.STRICT_SERVLET_COMPLIANCE truelautet, sammelt der Wrapper die JSR-77 Statistiken für einzelneServlets. Falls kein Wert angegeben ist, wird der Standardwert false verwendet.


org.apache.catalina.session.StandardSession.ACTIVITY_CHECK

Falls true oder falls org.apache.catalina.STRICT_SERVLET_COMPLIANCE true lautet, verfolgt Tomcat die Anzahl aktiver Anfragen fürjede Session. Bei der Überprüfung, ob eine Session gültig ist,wird jede Session mit mindestens einer aktiven Anfrage stets alsgültig betrachtet. Falls kein Wert angegeben ist, wird derStandardwert false verwendet.


A.5. KOMPATIBILITÄT UND INTEROPERABILITÄT ZWISCHENRELEASES

Dieser Abschnitt beschreibt die Kompatibilität und Interoperabilität von Client- und Server-EJB undMessaging-Komponenten zwischen den JBoss EAP 5, JBoss EAP 6 und JBoss EAP 7 Releases.

EJB Remoting über IIOPSie sollten keinerlei Probleme haben mit den folgenden Konfigurationen.

Verbindungen von einem JBoss EAP 5 Client mit einem JBoss EAP 7 Server





116

EJB Remoting mittels JNDISie sollten keinerlei Probleme haben mit den folgenden Konfigurationen.



JBoss EAP 6 bietet Unterstützung für die EJB 3.1 Spezifikation und führte die Verwendungstandardisierter, globaler JNDI Namespaces ein, die noch immer in JBoss EAP 7 verwendet werden.Aufgrund der Änderungen an den Namen der JNDI Namespaces sind die folgenden Konfigurationennicht kompatibel:

Verbindungen von einem JBoss EAP 5 Client mit einem JBoss EAP 7 oder JBoss EAP 6 Server

Verbindungen von einem JBoss EAP 7 oder JBoss EAP 6 Client mit einem JBoss EAP 5 Server

Weitere Informationen über die Änderungen der standardisierten JNDI Namespaces finden Sie unterJNDI-Änderungen im JBoss EAP 6 Migrationshandbuch.

EJB Remoting mittels @WebServiceSie sollten keinerlei Probleme haben mit den folgenden Konfigurationen.





Standalone Messaging-ClientSie sollten keinerlei Probleme haben mit den folgenden Konfigurationen.



In der folgenden Konfiguration ist die Verbindung möglich, sofern der Client die Messaging-Broker-spezifsche HornetQ-API anstelle der generischen JMS-API verwendet. Allerdings müssen JNDI-Lookups mithilfe der alten JBoss EAP JNDI-Naming-Erweiterung adressiert werden, die in JBoss EAP 7enthalten ist.


Aufgrund von Problemen bei der Protokollkompatibilität kann das in JBoss EAP 7 integrierte Messagingnicht mit HornetQ 2.2.x verbinden, das in JBoss EAP 5 enthalten war. Aus diesem Grund sind diefolgenden Konfigurationen nicht kompatibel.


Messaging-MDBsSie sollten keinerlei Probleme haben mit den folgenden Konfigurationen.




117

https://access.redhat.com/documentation/de-DE/JBoss_Enterprise_Application_Platform/6.4/html-single/Migration_Guide/index.html#sect-JNDI_Changes

In der folgenden Konfiguration ist die Verbindung möglich, sofern der Client die Messaging-Broker-spezifsche HornetQ-API anstelle der generischen JMS-API verwendet. Allerdings müssen JNDI-Lookups mithilfe der alten JBoss EAP JNDI-Naming-Erweiterung adressiert werden, die in JBoss EAP 7enthalten ist.


Aufgrund von Problemen bei der Protokollkompatibilität kann das in JBoss EAP 7 integrierte Messagingnicht mit HornetQ 2.2.x verbinden, das in JBoss EAP 5 enthalten war. Aus diesem Grund sind diefolgenden Konfigurationen nicht kompatibel.


JMS-BridgesSie sollten keinerlei Probleme haben mit den folgenden Konfigurationen.





Revised on 2018-01-05 08:53:47 EST


118

Red Hat JBoss Enterprise Application Platform 7.0 ... · Red Hat JBoss Enterprise Application...

Documents

Transcript of Red Hat JBoss Enterprise Application Platform 7.0 ... · Red Hat JBoss Enterprise Application...