Chapitre 4. Changements de configuration du serveur

4.1. Options de migration pour la configuration du système

Pour migrer votre configuration de serveur de JBoss EAP 6 à JBoss EAP 7, vous pouvez soit utiliser l'outil JBoss Server Migration ou procéder à une migration manuelle par l'opération d'interface en ligne de commande (CLI) migrate.

Outil JBoss Server Migration

L'outil JBoss Server Migration, qui est actuellement en cours de développement, est la méthode préconisée afin de mettre à jour votre configuration, pour qu'elle puisse inclure les dernières fonctionnalités et paramètres de configuration de JBoss EAP 7, tout en conservant votre configuration existante.

Opération de Migration par l'interface en ligne de commande

Vous pouvez utiliser l'opération d'interface CLI migrate pour mettre à jour les sous-systèmes jacorb, messaging, et web du fichier de configuration de JBoss EAP 6 pour qu'ils exécutent sur la nouvelle version, mais sachez que le résultat n'est pas une configuration JBoss EAP 7 complète. Par exemple :

  • L'opération ne met pas les configurations de port et le protocole distant à jour au nouveau http-remoting, et les nouvelles configurations de port sont maintenant utilisées dans JBoss EAP 7.
  • La configuration n'inclut pas les nouveaux sous-systèmes JBoss EAP ou les fonctionnalités comme les déploiements singleton clusterisés, ou encore, la fermeture normale.
  • La configuration n'inclut pas les nouvelles fonctionnalités de Java EE 7 comme le traitement par lots.

Pour plus d'informations sur la façon d'utiliser l'opération migrate pour migrer la configuration du serveur, voir Opération de Migration par l'Interface en ligne de commandes.

4.2. Opération de migration par ligne de commandes

Vous pouvez utiliser l'interface en ligne de commandes pour mettre à jour les fichiers de configuration du serveur JBoss EAP 6 afin qu'ils puissent être exécutés sur JBoss EAP 7. L'interface de ligne de commandes offre une opération migrate, permettant de mettre à jour automatiquement les sous-systèmes jacorb, messaging, et web de la version précédente à la nouvelle configuration. Vous pouvez également exécuter l'opération describe-migration pour les sous-systèmes jacorb, messaging, et web pour examiner les changements de configuration proposés de la migration avant d'effectuer la migration. Il n'y a pas de remplacement pour les sous-systèmes cmp, jaxr, ou threads et ils doivent être supprimés de la configuration du serveur.

Important

Voir Options de migration pour la configuration du serveur pour avoir des informations sur les limitations de l'opération migrate. L'outil JBoss Server Migration, qui est actuellement en cours de développement, est la méthode préconisée pour mettre à jour votre configuration, afin qu'elle puisse inclure les dernières fonctionnalités et paramètres de configuration de JBoss EAP 7, tout en conservant votre configuration existante.

Tableau 4.1. Opérations de l'interface de ligne de commandes et de migration de sous-systèmes

Sous-système JBoss EAP 6Sous-système JBoss EAP 7Opération en ligne de commandes

cmp

no replacement

remove

jacorb

iiop-openjdk

migrate

jaxr

no replacement

remove

messaging

messaging-activemq

migrate

threads

no replacement

remove

web

undertow

migrate

Effectuez les étapes ci-dessous pour mettre à jour votre configuration de serveur JBoss EAP 6 pour une exécution sur JBoss EAP 7.

  1. Avant de commencer, vérifier Back Up Important Data and Review Server State. Il contient des informations importantes sur la façon de vérifier que le serveur est en bon état, et que les bons fichiers sont sauvegardés.
  2. Lancez le serveur JBoss EAP 7 avec la configuration JBoss EAP 6.

    1. Effectuez une copie de sauvegarde des fichiers de configuration du serveur JBoss EAP 7.
    2. Copiez le fichier de configuration de la version précédente dans le répertoire JBoss EAP 7.

      $ cp EAP6_HOME/standalone/configuration/standalone-full.xml EAP7_HOME/standalone/configuration
    3. Rendez-vous sur le répertoire d'installation JBoss EAP 7 et lancez le serveur avec l'argument --admin-only.

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

      Vous remarquerez les erreurs org.jboss.as.controller.management-operation suivantes dans le journal du serveur quand vous démarrez le serveur. Ces erreurs sont prévues et indiquent que les configurations du sous-système héritées doivent être supprimées et migrées dans JBoss EAP 7.

      • WFLYCTL0402 : Les sous-systèmes [cmp] fournis par l'extension héritée « org.jboss.as.cmp » ne sont pas pris en charge sur les serveurs exécutant cette version. Le sous-système et l'extension doivent être supprimés ou doivent migrer pour que le serveur puisse fonctionner.
      • WFLYCTL0402 : Les sous-systèmes [jacorb] fournis par l'extension héritée « org.jboss.as.jacorb » ne sont pas pris en charge sur les serveurs exécutant cette version. Le sous-système et l'extension doivent être supprimés ou doivent migrer pour que le serveur puisse fonctionner.
      • WFLYCTL0402 : Les sous-systèmes [jaxr] fournis par l'extension héritée « org.jboss.as.jaxr » ne sont pas pris en charge sur les serveurs exécutant cette version. Le sous-système et l'extension doivent être supprimés ou doivent migrer pour que le serveur puisse fonctionner.
      • WFLYCTL0402 : Les sous-systèmes [messaging] fournis par l'extension héritée « org.jboss.as.messaging » ne sont pas pris en charge sur les serveurs exécutant cette version. Le sous-système et l'extension doivent être supprimés ou doivent migrer pour que le serveur puisse fonctionner.
      • WFLYCTL0402 : Les sous-systèmes [threads] fournis par l'extension héritée « org.jboss.as.threads » ne sont pas pris en charge sur les serveurs exécutant cette version. Le sous-système et l'extension doivent être supprimés ou doivent migrer pour que le serveur puisse fonctionner.
      • WFLYCTL0402 : Les sous-systèmes [web] fournis par l'extension héritée « org.jboss.as.web » ne sont pas pris en charge sur les serveurs exécutant cette version. Le sous-système et l'extension doivent être supprimés ou doivent migrer pour que le serveur puisse fonctionner.
  3. Ouvrez un nouveau terminal, rendez-vous sur le répertoire d'installation JBoss EAP 7, et lancez l'interface de ligne de commande de gestion en utilisant les arguments --controller=remote://localhost:9999.

    $ bin/jboss-cli.sh --connect --controller=remote://localhost:9999
  4. Effectuez la migration des sous-systèmes jacorb, messaging, et web.

    1. Pour vérifier les changements de configuration qui seront apportés au sous-système avant d'effectuer la migration, veuillez exécuter l'opération describe-migration.

      L'opération describe-migration utilise la syntaxe suivante.

      /subsystem=SUBSYSTEM_NAME:describe-migration

      L'exemple suivant décrit les changements de configuration qui seront apportés au fichier de configuration JBoss EAP 6.4 standalone-full.xml lorsqu'il est migré sur JBoss EAP 7. Les entrées ont été supprimées de la sortie pour améliorer la lisibilité et pour gagner de l'espace.

      Exemple : opération describe-migration

      [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")]
                  },
                  <!-- *** Entries removed for readability *** -->
                  {
                      "operation" => "remove",
                      "address" => [("subsystem" => "messaging")]
                  },
                  {
                      "operation" => "remove",
                      "address" => [("extension" => "org.jboss.as.messaging")]
                  }
              ]
          }
      }

    2. Exécutez l'opération migrate pour migrer la configuration du sous-système qui le remplace dans JBoss EAP 7. L'opération utilise la syntaxe suivante.

      /subsystem=SUBSYSTEM_NAME:migrate
      Note

      Les opérations du sous-système de messagerie describe-migration et migrate vous permettent de faire passer un argument pour configurer l'accès aux anciens clients. Pour plus d'informations sur la syntaxe de la commande, voir Migration du sous-système de messagerie et compatibilté ascendante.

    3. Examinez le résultat de la commande. Assurez-vous que l'opération se termine correctement et qu'il n'y ait pas d'entrées « migration-warning ». Cela signifie que la configuration de la migration pour le sous-système est terminée.

      Exemple : opération de migration sans avertissement réussie

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

      Si vous voyez des entrées « migration-warnings » dans ce journal, cela indique que la migration de la configuration du serveur s'est correctement terminée, mais qu'il n'a pas été possible de migrer tous les éléments et attributs. Veuillez suivre les suggestions offertes par les entrées « migration-warnings » et exécutez des commandes de l'interface en ligne de commandes pour modifier ces configurations. Vous trouverez ci-dessous un exemple d'opération migrate qui retourne des « migration-warnings ».

      Exemple : opération migrate avec avertissements

      [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 [
          (\"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."
          ]}
      }

      Note

      La liste des avertissements migrate et describe-migration de chaque sous-système qui se trouve dans la section Matériel de référence à la fin de ce guide.

    4. Examiner le fichier de configuration du serveur pour vérifier que l'extension, le sous-système, et l'espace-nom ont bien été mis à jour que la configuration existante du sous-système a effectivement migré sur JBoss EAP 7.
    Note

    Vous devrez répéter ce processus pour chaque sous-système jacorb, messaging, et web à l'aide des commandes suivantes.

    /subsystem=jacorb:migrate
    /subsystem=messaging:migrate
    /subsystem=web:migrate
  5. Supprimez les sous-systèmes et extensions cmp, jaxr, et threads de la configuration du serveur.

    Alors que vous vous trouvez toujours dans l'invite de l'interface de ligne de commandes, supprimez les sous-systèmes obsolètes cmp, jaxr, et threads en exécutant les commandes suivantes.

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

Vous devez effectuer la migration des sous-systèmes messaging, jacorb, et web et supprimer les extensions et sous-systèmes cmp, jaxr, et threads avant de pouvoir redémarrer le serveur pour une opération normale. Si vous devez redémarrer le serveur avant de terminer ce processus, assurez-vous de bien inclure l'argument --admin-only sur la ligne de commande du démarrage du serveur. Ceci vous permet de continuer avec les changements de configuration.

4.3. Changement au niveau de la Journalisation des préfixes de messages

Les messages de journalisation ont pour préfixes le code du projet du sous-système qui rapporte le message. Les préfixes de tous les messages ont changé dans JBoss EAP 7.

Pour obtenir une liste de tous les préfixes de code de projets de messages de journalisation de JBoss EAP 7, voir Codes de projet utilisés dans JBoss EAP dans le Guide de développement de JBoss EAP.

4.4. Changements de configuration du serveur web

4.4.1. Remplacer le sous-système web d'Undertow

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.

  • L'espace-nom de la configuration du sous-système urn:jboss:domain:web:2.2 dans le fichier de configuration du serveur a été remplacé par l'espace-nom urn:jboss:domain:undertow:3.1.
  • Le module d'extension org.jboss.as.web, situé dans EAP_HOME/modules/system/layers/base/, a été remplacé par le module d'extension org.wildfly.extension.undertow.

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>

4.4.2. Migrer les conditions de ré-écriture web de JBoss Web

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.

Note

La configuration de 'rewrite' a été abandonnée.

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

4.4.3. Migrer des valves globales

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.

  • Les valves globales sont insérées dans le pipeline de traitement de requête de toutes les applications déployées et sont configurées dans le fichier de configuration du serveur.
  • Les valves d'authentification authentifient les informations d'identification de la requête.
  • Des valves d'applications personnalisées ont été créées en étendant la classe org.apache.catalina.valves.ValveBase et configurées dans l'élément <valve> du fichier de descripteur jboss-web.xml. Ces valves doivent être migrées manuellement.

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.

Tableau 4.2. Mapper les valves avec les gestionnaires

ValveGestionnaire

AccessLogValve

io.undertow.server.handlers.accesslog.AccessLogHandler

CrawlerSessionManagerValve

io.undertow.servlet.handlers.CrawlerSessionManagerHandler

ExtendedAccessLogValve

io.undertow.server.handlers.accesslog.AccessLogHandler

JDBCAccessLogValve

Voir JDBCAccessLogValve Manual Migration Procedure ci-dessous pour obtenir des instructions.

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

Voir Migrate JBoss Web Rewrite Conditions pour obtenir des instructions sur la façon de migrer ces valves manuellement.

StuckThreadDetectionValve

io.undertow.server.handlers.StuckThreadDetectionHandler

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 :

  • Elles se limitent aux valves listées dans le tableau précédent, et qui ne requièrent pas de traitement manuel.
  • Elles doivent être définies dans le sous-système web du fichier de configuration du serveur.

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>
  1. Créer un module de pilote pour la base de données qui va stocker les entrées de journalisation.
  2. Configurer la source de données de la base de données et ajouter le pilote à la liste des pilotes disponibles dans le sous-système des sources de données.

    <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>
  3. Configurer un expression-filter dans le sous-système undertow avec l'expression suivante : jdbc-access-log(datasource=DATASOURCE_JNDI_NAME).

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

4.5. Changements de configuration du serveur JGroups

4.5.1. JGroups est, par défaut, une Interface de réseau privé

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.

4.5.2. Changements aux canaux de JGroups

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.

4.6. Changements de configuration du serveur Infinispan

4.6.1. Changements dans la configuration des caches par défaut d'Infinispan

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.

4.6.2. Changements dans la stratégie de caches d'Infinispan

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.

4.7. Changements de configuration du serveur de messagerie

Sur JBoss EAP 7, ActiveMQ Artemis remplace HornetQ comme fournisseur de support JMS. Cette section décrit comment migrer la configuration et les données connexes de messagerie.

4.7.1. Changements de configuration du serveur du sous-système de messagerie

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.

Tableau 4.3. Mapper les attributs de messagerie

Nom HornetQNom ActiveMQ 

hornetq-server

serveur

hornetq-serverType

serverType

connecteurs

connecteur

discovery-group-name

discovery-group

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.

4.7.2. Changements de la journalisation de la messagerie

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.

4.7.3. Migrer les données de messagerie

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.

4.7.3.1. Migrer les données de messagerie par moyen d'exportation ou d'importation

Avec cette approche, vous exportez les données de la version précédente par l'utilitaire exporter d'HornetQ. Vous pouvez ensuite importer le fichier de sortie XML formaté par l'opération import-journal.

Avertissement

Il y a actuellement un problème connu avec cette approche. Pour vérifier l’état de cette question, voir JBEAP-4407 - Consumer crashes with IndexOutOfBoundsException when reading large messages from imported journal.

Exportation des données de messagerie de la version précédente
Important

Le serveur JBoss EAP 6 doit être arrêté avant d'exporter les données de messagerie.

L'utilitaire exporter d'HornetQ génère et exporte les données de messagerie de JBoss EAP 6 vers un fichier au format XML. Cette commande nécessite que vous spécifiez les chemins vers les JAR HornetQ nécessaires fournis dans JBoss EAP 6, que vous communiquiez les chemins aux dossiers messagingbindings /, messagingjournal /, messagingpaging /, et messaginglargemessages / de la version précédente en tant qu'arguments, et que vous spécifiez un fichier de sortie dans lequel écrire les données XML exportées.

Voici la syntaxe requise par l'utilitaire exporter de HornetQ.

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

Créez un module personnalisé afin de s'assurer que les bonnes versions de JAR HornetQ, y compris les JAR installées avec des correctifs ou des mises à niveau, sont chargées et mises à la disposition de l'utilitaire exporter. À l'aide de votre éditeur favori, créez un nouveau fichier module.xml dans le répertoire EAP6_HOME/modules/org/hornetq/exportateur/main/ et copier le contenu suivant :

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

Le module personnalisé est créé dans le répertoire modules/, et non pas dans le répertoire modules/system/layers/base/.

Suivre les étapes ci-dessous pour exporter les données.

  1. Stopper le serveur JBoss EAP 6.
  2. Créer le module personnalisé comme décrit ci-dessus.
  3. Exécutez la commande suivante pour exporter les données.

    $ java -jar jboss-modules.jar -mp modules/ org.hornetq.exporter standalone/data/messagingbindings/ standalone/data/messagingjournal/ standalone/messagingpaging standalone/data/messaginglargemessages/ > OUTPUT_DIRECTORY/OldMessagingData.xml
  4. Veillez à ce qu'il n'y ait aucun message d'erreur ou d'avertissement dans le fichier journal une fois que la commande est complétée.
  5. Utiliser les outils disponibles dans votre système d'exploitation pour valider l'XML dans le fichier de sorties généré.
Importer les données de messagerie formatées en XML

Vous pouvez ensuite importer le fichier de sorties formatées XML par l'opération import-journal, comme suit.

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

4.7.3.2. Migrer les données de messagerie par un pontage JMS

En utilisant cette approche, vous configurez et déployez un pont JMS vers le serveur JBoss EAP 7 qui déplace les messages de la file d’attente de JBoss EAP 6 HornetQ à la file d’attente de JBoss EAP 7 ActiveMQ Artemis.

Un pontage JMS consomme des messages d'une file d'attente ou d'un topic JMS source et les envoie à une file d'attente JMS de cible ou sujet, se trouvant en général sur un autre serveur. Il peut être utilisé pour faire un pontage entre les messages et les serveurs JMS, tant qu'ils sont compatibles avec JMS 1.1. Les ressources JMS de source et de destination sont recherchées à l'aide de JNDI et les classes de client doivent être regroupées dans un module pour la recherche JNDI. Le nom du module est ensuite déclaré dans la configuration de pontage JMS.

Cette section décrit comment configurer les serveurs et déployer un pont JMS pour déplacer les données de messagerie de JBoss EAP 6 à JBoss EAP 7.

Configurer un serveur JBoss EAP 6
  1. Stopper le serveur JBoss EAP 6.
  2. Sauvegardez les fichiers de configuration et de journalisation d'HornetQ.

    • Par défaut, le journal HornetQ se trouve dans le répertoire EAP6_HOME/standalone/data/.
    • Voir Mappage des noms de dossiers de messagerie pour trouver les emplacements de dossiers de messagerie par défaut de chaque version.
  3. Veillez à ce que la file d'attente InQueue JMS contenant les messages JMS soit bien définie dans le serveur JBoss EAP 6.
  4. Veillez à ce que la configuration du sous-système de messaging contienne une entrée pour la RemoteConnectionFactory qui ressemble à ce qui suit.

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

    Si elle ne contient pas cette entrée, créez-en une par la commande suivante :

    /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)
Configurer le serveur JBoss EAP 7
  1. La configuration de pont JMS a besoin du module org.hornetq pour se connecter au serveur HornetQ de la version précédente. Ce module et ses dépendances directes ne sont pas présents dans JBoss EAP 7, donc vous devez copier les modules suivants de la version précédente.

    • Copier le module org.hornetq dans le répertoire JBoss EAP 7 EAP_HOME/modules/org/.

      • Si vous n’avez pas appliqué de correctif à ce module, copiez ce dossier à partir du serveur JBoss EAP 6.4 : EAP6_HOME/modules/system/layers/base/org/hornetq/
      • Si vous avez appliqué des correctifs à ce module, copiez ce dossier à partir du serveur JBoss EAP 6.4 : EAP6_HOME/modules/system/layers/base/.overlays/layer-base-jboss-eap-6.4.x.CP/org/hornetq/

        Note

        Pour la version corrigée, vous devez supprimer la ligne suivante du fichier JBoss EAP 7 modules/system/layers/base/org/hornetq/main/module.xml :

        <resource-root path="../../../../../org/hornetq/main/lib"/>
    • Copier le module org.jboss.netty dans le répertoire JBoss EAP 7 EAP_HOME/modules/org/jboss.

      • Si vous n’avez pas appliqué de correctifs à ce module, copiez ce dossier à partir du serveur JBoss EAP 6.4 : EAP6_HOME/modules/system/layers/base/org/jboss/netty
      • Si vous avez appliqué des correctifs à ce module, copiez ce dossier à partir du serveur JBoss EAP 6.4 : EAP6_HOME/modules/system/layers/base/.overlays/layer-base-jboss-eap-6.4.x.CP/org/jboss/netty
  2. Créer la file d’attente JMS pour contenir les messages reçus du serveur JBoss EAP 6. Voici un exemple de commande qui crée la file d’attente JMS MigratedMessagesQueue pour recevoir le message.

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

    Cela aura comme effet de créer la configuration jms-queue du serveur par défaut dans le sous-système messaging-activemq du serveur JBoss EAP 7.

    <jms-queue name="MigratedMessagesQueue" entries="jms/queue/MigratedMessagesQueue java:jboss/exported/jms/queue/MigratedMessagesQueue"/>
  3. Veillez à ce que le serveur du sous-système messaging-activemq par défaut contienne une configuration de InVmConnectionFactory connection-factory qui ressemble à ceci :

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

    Si elle ne contient pas cette entrée, créez-en une par la commande suivante :

    /subsystem=messaging-activemq/server=default/connection-factory=InVmConnectionFactory:add(factory-type=XA_GENERIC, connectors=[in-vm], entries=[java:/ConnectionFactory])
  4. Créer et déployer un pont JMS qui puisse lire les messages de la file JMS InQueue configurée dans le serveur JBoss EAP 6 et qui les transfère dans la file d'attente MigratedMessagesQueue configurée dans le serveur JBoss EAP 7 .

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

    Cela aura pour effet de créer la configuration jms-bridge dans le sous-système messaging-activemq du serveur JBoss EAP 7.

    <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>
        <target destination="jms/queue/MigratedMessagesQueue" connection-factory="java:/ConnectionFactory"/>
    </jms-bridge>
  5. Si la sécurité est configurée pour JBoss EAP 6, vous devez également configurer l’élément de configuration <source > du pont JMS pour qu'il puisse inclure un contexte source qui spécifie le nom d’utilisateur et mot de passe à utiliser pour la recherche JNDI quand on crée la connexion.
Migrer les données
  1. Vérifier que les informations que vous fournissez pour les configurations suivantes soient correctes.

    • Les noms de file d'attente et de sujets
    • Le java.naming.provider.url pour la recherche JNDI
  2. Veillez à bien déployer la destination JMS cible dans le serveur JBoss EAP 7.
  3. Démarrez à la fois les serveurs JBoss EAP 6 et JBoss EAP 7.

4.7.3.3. Mappage des noms de dossiers de messagerie

Le tableau suivant montre les noms de répertoires de messagerie utilisés dans les versions précédentes et dans la version actuelle de JBoss EAP. Les répertoires sont relatifs au répertoire jboss.server.data.dir, qui est définit par défaut dans EAP_HOME/standalone/data/, s'il n'est pas spécifié.

Nom de répertoire de JBoss EAP 6Nom de répertoire de JBoss EAP 7

messagingbindings/

activemq/bindings/

messagingjournal/

activemq/journal/

messaginglargemessages/

activemq/largemessages/

messagingpaging/

activemq/paging/

Note

Les répertoires messaginglargemessages/ et messagingpaging/ risquent de ne pas être présents s'il n'y a pas de messages volumineux ou si la pagination est désactivée.

4.7.4. Migrer les destinations JMS

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>

4.7.5. Migrer les intercepteurs de messagerie

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.

Exemple de configuration d'intercepteur

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

4.7.6. Remplacer la configuration de Netty Servlet

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.

4.8. Changements de configuration du serveur ORB

Dans JBoss EAP 7, l'implémentation de JacORB a été remplacée par une branche en aval d'ORB d'OpenJDK.

Le module d'extension org.jboss.as.jacorb situé dans EAP_HOME/modules/system/layers/base/ a été remplacé par le module d'extension org.wildfly.iiop-openjdk.

L'espace de noms de la configuration du sous-système urn:jboss:domain:jacorb:1.4 dans le fichier de configuration du serveur a été remplacé par l'espace de noms urn:jboss:domain:iiop-openjdk:1.0.

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

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

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

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

La nouvelle configuration du sous-système iiop-openjdk accepte uniquement un sous-ensemble des éléments et attributs hérités. Ci-dessous figure un exemple de configuration du sous-système jacorb dans la version précédente de JBoss EAP qui contient tous les éléments et les attributs valides :

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

Les attributs de l'élément ci-dessous ne sont plus pris en charge et doivent être supprimés.

Tableau 4.4. Attributs à supprimer

ÉlémentAttributs non pris en charge

<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

Les attributs suivants de on/off ne sont plus pris en charge et ne seront donc pas migrés lorsque vous exécutez l'opération migrate en ligne de commande. S'ils sont définis sur on, vous obtiendrez un avertissement de migration. D'autres attributs on/off qui ne sont pas mentionnés dans ce tableau, par exemple <security support-ssl="on|off">, sont toujours pris en charge et pourront donc être migrés. La seule différence est que leurs valeurs vont passer de on/off à true/false.

Tableau 4.5. Attributs à désactiver ou à supprimer

ÉlémentAttributs à définir sur « Off »

<orb>

  • cache-poa-names
  • cache-typecodes
  • print-version
  • use-bom
  • use-imr

<interop>

(tout sauf sun)

  • comet
  • iona
  • chunk-custom-rmi-valuetypes
  • indirection-encoding-disable
  • lax-boolean-encoding
  • strict-check-on-tc-creation

<poa/>

  • monitoring
  • queue-wait

4.9. Migrer la configuration du sous-système de threads

La configuration de serveur de JBoss EAP 6 incluse dans le sous-système de threads qui était utilisée pour gérer les pools de threads à travers les divers sous-systèmes du serveur.

Le sous-système de threads n'est plus disponible dans JBoss EAP 7. À la place, chaque sous-système est chargé de gérer ses propres pools de threads.

Pour obtenir plus d'informations sur la façon de configurer les pools de threads du sous-système infinispan, consulter Configurer les pools de threads d'Infinispan dans le Guide de configuration de JBoss EAP.

Pour obtenir plus d'informations sur la façon de configurer les pools de threads du sous-système jgroups, voir Configurer les pools de threads de JGroups dans le Guide de configuration de JBoss EAP.

Dans JBoss EAP 6, vous avez configuré des pools de threads pour connecteurs et listeners du sous-système de web en référençant un exécuteur défini dans le sous-système threads. Dans JBoss EAP 7, vous pouvez maintenant configurer les pools de threads pour le sous-système undertow en référençant un worker défini dans le sous-système e/s. Pour plus d'informations, consultez Configurer le sous-système e/s dans le Guide de configuration de JBoss EAP.

Pour obtenir plus d'informations sur les changements apportés à la configuration du pool de threads dans le sous-système distant , voir Migrer la configuration du sous-système distant de ce guide, et Configurer le point de terminaison du Guide de configuration de JBoss EAP.

4.10. Migrer la configuration du sous-système distant

Dans JBoss EAP 6, vous pouviez configurer le pool de threads du sous-système distant en définissant des attributs de worker-*. Le pool de threads de workers n'est plus configuré dans le sous-système distant de JBoss EAP 7 et si vous tentez de modifier la configuration existante, vous verrez le message suivant.

WFLYRMT0022: Worker configuration is no longer used, please use endpoint worker configuration

Dans JBoss EAP 7, le pool de threads de workers est remplacé par une configuration de point de terminaison qui référence un worker défini dans le sous-système e/s.

Pour plus d'informations sur la façon de configurer les points de terminaison, voir Configurer les points de terminaison du Guide de configuration de JBoss EAP 7.

4.11. Changements de configuration du serveur WebSocket

Pour utiliser WebSockets sur JBoss EAP 6, vous deviez activer le protocole du connecteur Java NIO2 non bloquant pour le connecteur http dans le sous-système web du fichier de configuration du serveur JBoss EAP en utilisant une commande similaire à la suivante.

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

Pour utiliser les WebSockets dans une application, vous deviez également créer un élément <enable-websockets> dans le fichier de l'application WEB-INF/jboss-web.xml et le définir sur true.

Dans JBoss EAP 7, il n'est plus nécessaire de configurer le serveur pour la prise en charge par défaut de WebSocket, ni de configurer l'appliquer pour qu'elle puisse l'utiliser . Les WebSockets sont une condition préalable de la spécification Java EE 7 et les protocoles requis sont configurés par défaut. Une configuration WebSocket plus complexe est effectuée dans le servlet-container du sous-système Undertow du fichier de configuration du serveur JBoss EAP. Vous pouvez afficher les paramètres disponibles en utilisant la commande suivante.

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

Des exemples de code WebSocket se trouvent également dans les guides de mise en route rapide (« quickstarts ») fournis avec JBoss EAP.

4.12. Changements du serveur « Single Sign-on »

Le sous-système Infinispan fournit toujours une prise en charge de cache distribué pour les services HA sous la forme de caches Infinispan dans JBoss EAP 7 ; cependant, la mise en cache et la distribution des informations d'authentification sont gérées de manière différente par rapport aux versions précédentes.

Dans JBoss EAP 6, si SSO (« Single Sign-on ») n'a pas reçu de cache Infinispan ; le cache n'a pas été distribué.

Dans JBoss EAP 7, SSO est distribué automatiquement lorsque vous sélectionnez le profil HA. Lors de l'exécution du profil HA, chaque hôte possède son propre cache Infinispan, qui est basé sur le cache par défaut du conteneur du cache web. Ce cache stocke la session pertinente et les informations du cookie SSO pour l'hôte. JBoss EAP gère la propagation de chaque cache individuel vers tous les hôtes. Il n'y a pas de manière spécifique d'assigner un cache Infinispan à SSO dans JBoss EAP 7.

Dans JBoss EAP 7, SSO est configuré dans le sous-système Undertow du fichier de configuration du système.

Aucun changement du code d'application n'est requis pour SSO lors de la migration vers JBoss EAP 7.

4.13. Changements dans la configuration de la source de données

4.13.1. Le nom du pilote de la source de données JBDC

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
Note

Un trait de soulignement a été ajouté entre le JAR_NAME et le DRIVER_CLASS_NAME.

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.

Exemple de nom de pilote JBoss EAP 6

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

Exemple de nom de pilote JBoss EAP 7

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

4.14. Changements de configuration du serveur de sécurité

Pour obtenir des informations sur les changements de configuration au serveur du Gestionnaire de sécurité Java, voir Considérations quand on passe d'une ancienne à une nouvelle version dans Comment configurer la sécurité dans les serveurs de JBoss EAP.

4.15. Modifications apportées au sous-système de transactions

Certains attributs de configuration du Gestionnaire de transactions, qui étaient disponibles dans le sous-système transactions de JBoss EAP 6 ont changé dans JBoss EAP 7.

Attributs du sous-système de transactions supprimés

Le tableau suivant répertorie les attributs de JBoss EAP 6 qui ont été retirés du sous-système transactions dans JBoss EAP 7 et les attributs de remplacement équivalents.

Attribut de JBoss EAP 6Remplacement dans JBoss EAP 7

path

object-store-path

relative-to

object-store-relative-to

Attributs de sous-systèmes de transactions dépréciés

Les attributs suivants qui étaient disponibles dans le sous-système de transactions de JBoss EAP 6 sont dépréciés dans JBoss EAP 7. Les attributs dépréciés risquent d'être supprimés dans une version ultérieure du produit. Le tableau suivant répertorie les attributs de remplacement équivalents.

Attribut de JBoss EAP 6Remplacement dans 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.16. Changements à la configuration de mod_cluster

La configuration des listes de proxy statiques de mod_cluster a été modifiée dans JBoss EAP 7.

Dans JBoss EAP 6, vous configuriez l'attribut proxy-list, qui correspondait à une liste des adresses de proxy httpd séparées par des virgules, sous le format hostname:port.

L'attribut proxy-list est déprécié dans JBoss EAP 7. Il a été remplacé par l'attribut proxies , qui correspond à une liste de noms de liaisons de sockets de sortie.

Ce changement a un impact sur la façon de définir une liste de proxys statiques, par exemple, quand on désactive les annonces dans mod_cluster. Pour obtenir des informations sur la façon de désactiver les annonces dans mod_cluster, voir Désactiver les annonces dans mod_cluster dans le Guide de configuration de JBoss EAP.

Pour obtenir des informations sur les attributs de mod_cluster, voir mod_cluster Subsystem Attributes dans le Guide de configuration de JBoss EAP.