Chapitre 4. Changements de configuration du serveur

Undertow remplace JBoss Web comme serveur web dans JBoss EAP 7. Cela signifie que la configuration du sous-système web hérité doit être migrée vers la nouvelle configuration du sous-système undertow de JBoss EAP 7.

Vous pouvez utiliser l'opération migrate dans l'interface en ligne de commande (CLI) pour migrer le sous-système web à undertow dans le fichier de configuration du serveur. Cependant, sachez que cette opération ne vous permettra pas de migrer toutes les configurations du sous-système de JBoss Web. Si vous apercevez des entrées "migration-warning", vous devrez exécuter des commandes supplémentaires pour migrer ces configurations vers Undertow. Pour obtenir davantage d'informations sur l'opération migrate de l'interface de ligne de commande de gestion, veuillez consulter les Opérations de migration en ligne de commande.

Ci-dessous figure un exemple de la configuration par défaut du sous-système web dans JBoss EAP 6.

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

Ci-dessous figure un exemple de la configuration par défaut du sous-système undertow dans JBoss EAP 7.

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

L'opération migrate de ligne de commande ne peut pas migrer les conditions de 'rewrite' automatiquement. Elles sont rapportées en tant que "migration-warnings" et vous devez les migrer manuellement. Vous pouvez créer une configuration équivalente dans JBoss EAP 7 en utilisant Undertow Predicates Attributes and Handlers.

Ci-dessous figure un exemple de la configuration par défaut du sous-système web de JBoss EAP 6, qui contient une configuration rewrite.

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

Suivre les instructions de Opérations de migration en ligne de commande pour démarrer votre serveur et l'outil de ligne de commande, puis migrer le fichier de configuration du sous-système web en utilisant la commande suivante.

/subsystem=web:migrate

Les "migration-warnings" sont rapportés quand vous exécutez l'opération migrate sur la configuration ci-dessus.

e /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\")
    ]
}"
    ]}
}

Vérifiez le fichier de configuration du serveur et vous verrez la configuration suivante pour le sous-système undertow.

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

Utiliser l'outil de ligne de commande (CLI) pour créer le filtre qui remplacera la configuration de 'rewrite' dans le sous-système d'Undertow. Vous devrez voir "{"outcome" ⇒ "success"}" pour chaque commande.

# 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

Vérifiez le fichier de configuration du serveur mis à jour. Le sous-système de JBos Web est maintenant complètement migré et configuré dans le sous-système undertow.

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

Pour plus d'informations sur la façon de configurer les filtres et les handlers en utilisant la ligne de commande, voir Configurer le serveur web dans le Guide de configuration de JBoss EAP 7.

Versions précédentes des valves prises en charge par JBoss EAP. Les valves sont des classes personnalisées insérées dans le pipeline de traitement de requêtes pour une application avant que les filtres servlet apportent des changements à la requête ou effectuent un traitement supplémentaire.

Cette section décrit la façon de migrer les valves globales. La migration de valves d'authenficateur personnalisées est expliquée dans la section Migration des valves d'applications personnalisées de ce guide.

Undertow, qui remplace JBoss Web dans JBoss EAP 7, ne prend pas en charge les valves globales. Cependant, vous devriez pouvoir utiliser des fonctionnalités similaires en utilisant les gestionnaires Undertow. Undertow inclut un certain nombre de gestionnaires intégrés qui fournissent des fonctionnalités . Undertow offre également la possibilité de créer des gestionnaires personnalisés, qui peuvent être utilisés pour remplacer les fonctionnalités des valves personnalisées.

Si votre application utilise des valves, vous devez les remplacer par le code du gestionnaire Undertow approprié afin d'atteindre les mêmes fonctionnalités lorsque vous effectuez la migration vers JBoss EAP 7.

Pour plus d'informations sur la façon de configurer les handlers, voir Configuration des Handlers du Guide de configuration de JBoss EAP 7.

Pour plus d'informations sur la façon de configurer les filtres, voir Configuration des Filtres du Guide de configuration de JBoss EAP 7.

Migrer les valves de JBoss Web

Le tableau suivant répertorie les valves fournies par JBoss Web dans la version précédente de JBoss EAP et le handler intégré d'Undertow correspondant. Les valves de JBoss Web se trouvent dans le paquet org.apache.catalina.valves.

Vous pouvez utiliser l'opération migrate de l'interface de ligne de commandes pour automatiquement migrer les valves globales qui remplissent les conditions suivantes :

Pour obtenir davantage d'informations sur l'opération migrate, veuillez consulter Opération de migration en interface de ligne de commande.

Procédure de migration manuelle JDBCAccessLogValve

La valve org.apache.catalina.valves.JDBCAccessLogValve est une exception à la règle et ne peut pas être migrée automatiquement dans le io.undertow.server.handlers.JDBCLogHandler. Suivre les étapes suivantes pour migrer l'exemple de valve suivant.

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

Dans la confuguration par défaut deJBoss EAP 6, JGroups utilisait l'interface publique définie dans la section <interfaces> du fichier de configuration du serveur.

Comme il est normalement conseillé d'utiliser une interface de réseau dédiée exclusivement, par défaut, JGroups utilise maintenant l'interface privée définie dans la section <interfaces> du fichier de configuration du serveur dans JBoss EAP 7.

JGroups fournit un support de communication de groupe pour les services HA, sous forme de canaux de JGroups. JBoss EAP 7 introduit des éléments de < canaux> dans le sous-système jgroups qui se trouve dans le fichier de configuration de serveur. Vous pouvez ajouter, supprimer ou modifier la configuration de canaux JGroups par l'outil de ligne de commandes.

Pour obtenir des informations sur la façon de configurer JGroups, voir Communication Cluster avec JGroups dans le Guide de configuration de JBoss EAP.

Dans JBoss EAP 6, la valeur par défaut des caches en cluster des réplications de sessions web et EJB étaient des caches ASYNC répliqués. Cela a changé dans JBoss EAP 7. Les caches en cluster par défaut sont maintenant des caches ASYNC distribués. Les caches répliqués ne sont même plus configurés par défaut. Voir Configurer le mode de cache dans le Guide de configuration pour obtenir des informations sur la façon d'ajouter un cache répliqué et de le rendre 'par défaut'.

Cela ne vous affectera que lorsque vous utiliserez la nouvelle configuration par défaut de JBoss EAP 7. Si vous migrez la configuration de JBoss EAP 6, la configuration du sous-système infinispan sera préservée.

Le comportement de la stratégie de cache ASYNC a changé dans JBoss EAP 7.

Dans JBoss EAP 6, les lectures de caches ASYNC n'avaient pas de verrous. Bien qu'elles ne pouvaient être bloquées, elles étaient prônes aux lectures erronées des données obsolètes, par exemple, en cas de basculement. C'est parce que cela permettait aux demandes consécutives d'un même utilisateur de démarrer avant que la requête précédente fût terminée. Cette permissivité n'est pas acceptable en mode distribué, étant donné que les modifications de topologie de cluster peuvent avoir un impact sur l'affinité de session et facilement entraîner des données obsolètes.

Dans JBoss EAP 7, les lectures de caches ASYNC requièrent des verrous. Comme elles bloquent maintenant les nouvelles demandes de la part d'un même utilisateur jusqu'à ce que la réplication se termine, cela évite les lectures erronnées.

Le module d'extension org.jboss.as.messaging, situé dans EAP_HOME/modules/system/layers/base/, a été remplacé par le module d'extentsion org.wildfly.extension.messaging-activemq.

L'espace-nom de la configuration du sous-système urn:jboss:domain:messaging:3.0 a été remplacé par l'espace-nom urn:jboss:domain:messaging-activemq:1.0.

Modèle de gestion

Dans la plupart des cas, un effort a été fait pour garder les noms d'éléments et d'attributs aussi proches que possible de ceux utilisés dans des versions précédentes. Le tableau suivant répertorie certains de ces changements.

Les opérations de gestion invoquées sur le nouveau sous-système messaging-activemq sont passées de /subsystem=messaging/hornetq-server= à /subsystem=messaging-activemq/server=.

Vous pouvez migrer une configuration du sous-système de messagerie messaging de JBoss EAP 6 dans le sous-système messaging-activemq d'un serveur JBoss EAP 7 en invoquant son opération migrate.

/subsystem=messaging:migrate

Avant d'exécuter l'opération migrate, vous devriez invoquer l'opération describe-migration pour réviser la liste des opérations de gestion qui vont être effectuées pour migrer la configuration du sous-système de messagerie messaging JBoss EAP 6 dans le sous-système messaging-activemq du serveur JBoss EAP 7.

/subsystem=messaging:describe-migration

Les opérations migrate et describe-migration affichent également une liste d'avertissements migration-warnings pour les ressources ou attributs qui ne peuvent pas être migrés automatiquement.

Migration du sous-système de messagerie et Compatibilté ascendante

Les opérations describe-migration et migrate du sous-système messaging fournissent un argument de configuration supplémentaire. Si vous souhaitez configurer la messagerie pour permettre aux anciens clients JBoss EAP 6 de se connecter au serveur JBoss EAP 7, vous pouvez ajouter un argument add-legacy-entries à l'opération describe-migration ou migrate, comme suit.

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

Si l'argument de booléen add-legacy-entries est défini sur true, le sous-système messaging-activemq crée la ressource legacy-connection-factory et ajoute les legacy-entries aux ressources jms-queue et jms-topic.

Si l'argument de booléen add-legacy-entries est défini sur false, aucune ancienne ressource ne sera créée dans le sous-système messaging-activemq et les anciens clients JMS ne seront pas en mesure de communiquer avec les serveurs de JBoss EAP 7. Il s'agit de la valeur par défaut.

Pour obtenir des informations sur la compatibilité ascendante et descendante, consulter Compatibilité ascendante et descendante dans Configurer la messagerie de JBoss EAP.

Pour obtenir davantage d'informations sur les opérations migrate et describe-migration en ligne de commande, veuillez consulter Opération de migration en interface de ligne de commande.

Configuration du sous-système de messagerie XML

La configuration XML a changé de manière significative avec le nouveau sous-système messaging-activemq afin de fournir un schéma XML plus consistant avec d'autres sous-systèmes JBoss EAP.

Il est fortement déconseillé de tenter de modifier la configuration XML du sous-système de messagerie messaging JBoss EAP afin de se conformer au nouveau sous-système messaging-activemq. Au lieu de cela, veuillez invoquer l'opération migrate du sous-système hérité. Cette opération écrira la configuration XML du nouveau sous-système messaging-activemq comme faisant partie de son exécution.

Le préfixe des messages de journalisation du sous-système de messagerie, messaging, est passé de "JBAS" à "WFLYMSGAMQ". Pour obtenir une liste de tous les préfixes de code de projets de messages de journalisation de JBoss EAP 7, voir Codes de projets utilisés dans JBoss EAP dans le Guide de développement de JBoss EAP.

En raison du passage du fournisseur de Support JMS d'HornetQ à ActiveMQ Artemis, le format et l'emplacement des données de messagerie ont changé dans JBoss EAP 7.

Vous pouvez adopter les deux approches suivantes pour migrer les données :

Voir Mappage des noms de dossier de messagerie pour obtenir des détails sur les changements à apporter aux dossiers de données de messagerie entre les différentes versions.

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

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

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

Dans les versions précédentes de JBoss EAP, les files d'attente des destinations JMS étaient configurées dans l'élément <jms-destinations> situé sous l'élément <hornetq-server> dans le sous-système de messagerie messaging.

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

Dans JBoss EAP 7, la file d'attente de destination JMS est configurée dans l'élément par défaut <server> du sous-système messaging-activemq.

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

Les intercepteurs de messagerie ont beaucoup changé dans JBoss EAP 7, suite au remplacement d'HornetQ par ActiveMQ Artemis comme fournisseur de messagerie JMS.

Le sous-système de messagerie d'HorneQ inclus dans la dernière version de JBoss EAP exige que vous installiez les intercepteurs d'HornetQ en les ajoutant à un JAR et en modifiant ensuite le fichier module.xml d'HornetQ.

Le sous-système de messagerie-activemq inclus dans JBoss EAP 7 ne nécessite pas de modification de fichier module.xml. Les classes d'intercepteur d'utilisateur qui implémentent maintenant l'interface d'intercepteur Apache ActiveMQ Artemis Interceptor peuvent maintenant être chargées depuis n'importe quel module de serveur. Vous spécifiez le module à partir duquel l'intercepteur doit être chargé dans le sous-système du fichier de configuration du serveur, messagerie-activemq.

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

Dans JBoss EAP 6, vous pouvez configurer un moteur de servlet pour qu'il puisse travailler avec le transport du Netty Servlet. Comme ActiveMQ Artemis remplace HornetQ en tant que fournisseur de messagerie intégrée dans JBoss EAP 7, cette configuration n'est plus disponible. Vous devez remplacer la configuration de servlet pour utiliser les nouveaux connecteurs http de messagerie intégrés et les accepteurs de http à la place.

Lorsque vous configuriez une source de données dans la version précédente de JBoss EAP, la valeur spécifiée de nom du pilote dépendait du nombre de classes répertoriées dans le fichier META-INF/services/java.sql.Driver contenu dans la JAR du pilote JDBC.

Pilote contenant une classe unique

Si le fichier META-INF/services/java.sql.Driver spécifiait une seule classe uniquement, la valeur du nom du pilote correspondait tout simplement au nom du JAR du pilote JDBC. Cela n'a pas été modifié dans JBoss EAP 7.

Pilote contenant plusieurs classes

Dans JBoss EAP 6, s'il y avait plus d'une classe listée dans le fichier META-INF/services/java.sql.Driver, vous pouviez spécifier laquelle était la classe de pilote en ajoutant son nom au nom du JAR, avec la version mineure ou majeure, dans le format suivant :

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

Dans JBoss EAP7, cela a changé. Vous devez maintenant spécifier le nom du pilote en utilisant le format suivant :

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

Le pilote JDBC MySQL 5.1.31 est un exemple de pilote qui contient deux classes. Le nom de classe du pilote est com.mysql.jdbc.Driver. Les exemples suivants illustrent les différences entre la manière dont vous spécifiez un nom du pilote dans la version précédente de JBoss EAP et celle dont vous le spécifiez dans la version actuelle.

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

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