Annexe A. Matériel de référence

A.1. Avertissements pour l'opération de migration du sous-système JacORB

L'opération migrate n'est pas en mesure de traiter toutes les ressources et les attributs. Voici quelques-uns des éventuels avertissements qui peuvent s'afficher lorsque vous exécutez une opération migrate ou describe-migration dans le sous-système jacorb.

Note

Si vous voyez «Impossible de migrer » dans la sortie de l'opération de migration, cela indique que la migration de la configuration du serveur est terminée, mais qu'on n'a pas pu migrer automatiquement tous les éléments et attributs. Vous devez suivre les conseils donnés dans les «avertissements de migration» pour modifier ces configurations.

Message d'avertissementCe que cela signifie / Comment les régler

La migration iiop peut être effectuée quand le serveur est en mode admin-only

L'opération migrate exige de démarrer le serveur en mode admin-only, ce qui est fait en ajoutant le paramètre --admin-only à la commande de démarrage du serveur : 

$ EAP_HOME/bin/standalone.sh --admin-only

Les propriétés X ne peuvent pas être émulées avec OpenJDK ORB et ne sont pas prises en charge.

La configuration de la propriété spécifiée n'est pas prise en charge et n'est pas incluse dans la nouvelle configuration de sous-système iiop-openjdk. Le comportement de cette propriété dans la version précédente de JBoss EAP n'est pas migré et l'administrateur doit vérifier que le nouveau sous-système iiop-openjdk de JBoss EAP 7 est capable de fonctionner correctement sans ce comportement.

Propriétés non prises en charge : 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.

Les propriétés X utilisent des expressions. Les propriétés de configuration qui sont utilisées pour résoudre ces expressions doivent être transformées manuellement au nouveau format du sous-système iiop-openjdk

Les propriétés qui utilisent des expressions doivent être configurées manuellement par l'administrateur.

Par exemple, le sous-système jacorb de JBoss EAP 6 définissait une propriété giop-minor-version. Le sous-système iiop-openjdk de JBoss EAP 7 définit une propriété giop-version. Supposons que l'attribut de la version mineure de sous-système jacorb soit défini sur ${iiop-giop-minor-version} et que la propriété du système soit configurée dans le fichier standalone.conf à -Diiop-giop-minor-version=1. Après l'opération de migration, l'administrateur doit modifier la valeur système de la propriété 1.1 pour assurer que le nouveau sous-système soit correctement configuré.

Impossible de migrer : le nouveau sous-système iiop-openjdk est déjà défini

Le message contient une explication

A.2. Avertissements pour l'opération de migration du sous-système de messagerie

L'opération migrate n'est pas en mesure de traiter toutes les ressources et attributs. Voici quelques-uns des éventuels avertissements qui peuvent s'afficher lorsque vous exécutez une opération migrate ou describe-migration dans le sous-système de messagerie.

Note

Si vous voyez «Impossible de migrer » dans la sortie de l'opération de migration, cela indique que la migration de la configuration du serveur est terminée, mais qu'on n'a pas pu migrer automatiquement tous les éléments et attributs. Vous devez suivre les conseils donnés dans les «avertissements de migration» pour modifier ces configurations.

Message d'avertissementCe que cela signifie / Comment les régler

L'opération migrate ne peut pas être effectuée : le serveur doit être en mode admin-only

L'opération migrate exige de démarrer le serveur en mode admin-only, ce qui est fait en ajoutant le paramètre --admin-only à la commande de démarrage du serveur : 

$ EAP_HOME/bin/standalone.sh --admin-only

Impossible de migrer l'attribut local-bind-address de la ressource X. Utiliser l'attributsocket-binding pour configurer broadcast-group à la place.

Le message contient une explication et indique la façon de régler ce problème.

Impossible de migrer l'attribut local-bind-port de la ressource X. Utiliser l'attributsocket-binding pour configurer broadcast-group à la place.

Le message contient une explication et indique la façon de régler ce problème.

Impossible de migrer l'attribut group-address de la ressource X. Utiliser l'attributsocket-binding pour configurer broadcast-group à la place.

Le message contient une explication et indique la façon de régler ce problème.

Impossible de migrer l'attribut group-port de la ressource X. Utiliser l'attributsocket-binding pour configurer broadcast-group à la place.

La ressource broadcast-group n'accepte plus les attributs local-bind-address, local-bind-port, groupe-address ou group-port. Elle accepte uniquement un attribut socket-binding. L'avertissement indique que la ressource X possède un attribut non pris en charge. Vous devez manuellement affecter cet attribut socket-binding à la ressource et vous assurer qu'il corresponde bien à une ressource socket-binding définie.

Les classes fournissant X sont ignorées pendant la migration. Pour les utiliser dans le nouveau sous-système messaging-activemq, vous devrez étendre l'intercepteur basé Artemis.

Le support aux intercepteurs de messagerie est sensiblement différent dans JBoss EAP 7. Les intercepteurs configurés dans la version précédente du sous-système sont ignorés lors de la migration. Pour plus d'informations, voir Migrer les intercepteurs de messagerie.

N'a pas pu migrer la configuration HA de X. Ses attributs shared-store et backup contiennent des expressions, et il n'est pas possible de déterminer sans ambiguïté comment créer la ha-policy correspondante pour le serveur de la messagerie-activemq.

Cela signifie que les attributs hornetq-server X : shared-store ou backup contiennent une expression, qui ressemble à ${xxx}, et que l'opération de migration n'a pas pu la résoudre en expression concrète. La valeur est ignorée et la ha-policy de messaging-activemq doit être mise à jour manuellement.

Impossible de migrer l'attribut local-bind-address de la ressource X. Utiliser l'attributsocket-binding pour configurer discovery-group à la place.

Le message contient une explication et indique la façon de régler ce problème.

Impossible de migrer l'attribut local-bind-port de la ressource X. Utiliser l'attributsocket-binding pour configurer discovery-group à la place.

Le message contient une explication et indique la façon de régler ce problème.

Impossible de migrer l'attribut group-address de la ressource X. Utiliser l'attributsocket-binding pour configurer discovery-group à la place.

Le message contient une explication et indique la façon de régler ce problème.

Impossible de migrer l'attribut group-port de la ressource X. Utiliser l'attributsocket-binding pour configurer discovery-group à la place.

Les ressources discovery-group n'acceptent plus les attributs local-bind-address, local-bind-port, group-address ou group-port. Elles acceptent uniquement un socket-binding. L'avertissement indique que la ressource X possède un attribut non pris en charge. Vous devez manuellement affecter cet attribut socket-binding à la ressource et vous assurer que cela correspond à une ressource socket-binding définie.

Ne peut pas créer un legacy-connection-factory basé sur connexion-factory X. Utilise un connecteur in-vm HornetQ qui n'est pas compatible avec le connecteur in-vm d'Artemis

Les ressources distantes héritées de connection-factory d'HornetQ sont migrées dans les ressources legacy-connection-factory pour permettre aux clients de JBoss EAP 6 de se connecter à JBoss EAP 7. Cependant, les ressources legacy-connection-factory ne sont créés que lorsque connection-factory utilise des connecteurs distants. Toute connection-factory utilisant in-vm n'est pas migrée car les clients in-vm sont basés sur JBoss EAP 7, et non pas JBoss EAP 6. Cet avertissement est pour vous notifier que la in-vm connection-factory n'a pas migrée.

Impossible de migrer l'attribut X de la ressource Y. L'attribut utilise une expression qui peut être résolue différemment suivant les propriétés système. Après la migration, cet attribut doit être ajouté à nouveau avec la valeur réelle et non pas l'expression.

Cet avertissement apparaît lorsque la migration ne peut pas résoudre l'attribut X en une valeur réelle lors du processus de migration. La valeur est ignorée et l'attribut doit être migré manuellement. Cela se produit dans les cas suivants :

  • cluster-connection forward-when-no-consumers :

    Cet attribut de booléen a été remplacé par l'attribut message-load-balancing-type, qui est un enum avec une valeur correspondant à OFF, STRICT, ou ON_DEMAND.

  • Pour broadcast-group et discovery-group, les attributs jgroups-stack et jgroups-channel

    Ils référencent d'autres ressources et JBoss EAP 7 n'accepte plus ces expressions.

Impossible de migrer l'attribut X de la ressource Y. Cet attribut n'est pas pris en charge par le nouveau sous-système messaging-activemq.

Certains attributs ne sont plus pris en charge par le nouveau sous-système messaging-activemq et sont ignorés tout simplement :

  • Attribut hornetq-server’s failback-delay
  • Attribut http-connector use-nio
  • Attribut http-acceptor use-nio
  • Attribut remote-connector use-nio
  • Attribut remote-acceptor use-nio

Impossible de migrer l'attribut failback-delay de la ressource X. Artemis détecte la restauration automatique de façon déterministe et il n'a plus besoin de spécifier un délai pour que la restauration automatique ait lieu.

Le message contient une explication

Remplacer les attributs broadcast-group et discovery-group

Si on vous conseille de remplacer les attributs broadcast-group et discovery-group par l'attribut socket-binding, vous pouvez ajouter le nouvel attribut en ligne de commande (CLI).

Cet exemple assume que vous migrez un serveur autonome qui contient la configuration discovery-group dans le sous-système de messagerie. 

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

Quand vous exécutez l'opération migrate pour le sous-système messaging, vous verrez les messages d'avertissement et de sortie suivants : 

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

L'opération migrate crée un discovery-group nommé "my-discovery-group" dans le nouveau sous-système messaging-activemq qui est maintenant configuré ainsi : 

<discovery-group name="my-discovery-group"/>

Vous devez maintenant utiliser la commande CLI pour créer un élément socket-binding dans le fichier de configuration de serveur nommé "my-discovery-group-socket-binding". 

/socket-binding-group=standard-sockets/socket-binding=my-discovery-group-socket-binding:add(multicast-address=224.0.1.105, multicast-port=56789)

Ensuite, ajoutez la socket-binding nouvellement créée au discovery-group nommé "my-discovery-group" dans le sous-système messaging-activemq du fichier de configuration de serveur à l'aide de la commande CLI suivante : 

/subsystem=messaging-activemq/server=default/discovery-group=my-discovery-group:write-attribute(name=socket-binding,value=my-discovery-group-socket-binding)

Ces commandes créent le XML suivant dans le fichier de configuration du serveur. 

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

A.3. Avertissements pour l'opération de migration du sous-système Web

L'opération migrate n'est pas en mesure de traiter toutes les ressources et les attributs. Voici quelques-uns des éventuels avertissements qui peuvent s'afficher lorsque vous exécutez une opération migrate ou describe-migration dans le sous-système web.

Note

Si vous voyez «Impossible de migrer » dans la sortie de l'opération de migration, cela indique que la migration de la configuration du serveur est terminée, mais qu'on n'a pas pu migrer automatiquement tous les éléments et attributs. Vous devez suivre les conseils donnés dans les «avertissements de migration» pour modifier ces configurations.

Message d'avertissementCe que cela signifie / Comment les régler

L'opération migrate n'est autorisée qu'en mode admin

L'opération migrate exige de démarrer le serveur en mode admin-only, ce qui est fait en ajoutant le paramètre --admin-only à la commande de démarrage du serveur : 

$ EAP_HOME/bin/standalone.sh --admin-only

Impossible de migrer la ressource X

Le comportement de cette ressource dans la version précédente de JBoss EAP n'a pas migré. L'administrateur doit vérifier si le nouveau sous-système d'Undertow dans JBoss EAP 7 est capable de fonctionner correctement sans que ce comportement et si le comportement doit être migré manuellement.

Impossible de migrer l'attribut X de la ressource Y

Le comportement de cet attribut de ressource dans la version précédente de JBoss EAP n'a pas été migré. L'administrateur doit vérifier si le nouveau sous-système d'Undertow de JBoss EAP 7 est capable de fonctionner correctement sans ce comportement et si le comportement doit être migré manuellement.

N'a pas pu migrer le connecteur SSL car aucune config SSL n'est définie

Le message contient une explication

N'a pas pu migrer l'attribut verify-client X dans l'équivalent d'Undertow.

Le message contient une explication

Impossile de migrer l'expression verify-client X

Le message contient une explication

Impossible de migrer la valve X

Le comportement de cette valve dans la version précédente de JBoss EAP n'a pas été migré. L'administrateur doit vérifier si le nouveau sous-système d'Undertow dans JBoss EAP 7 est capable de fonctionner correctement sans ce comportement et si le comportement doit être migré manuellement.

Ce message d'avertissement peut s'afficher pour les valves suivantes :

  • org.apache.catalina.valves.RemoteAddrValve

    Doit posséder une valeur autorisée ou non au moins

  • org.apache.catalina.valves.RemoteHostValve

    Doit posséder une valeur autorisée ou non au moins

  • 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
  • valves personnalisées

Impossible de migrer l'attribut X de la valve Y

Le comportement de cet attribut de valve dans la version précédente de JBoss EAP n'a pas été migré. L'administrateur doit vérifier si le nouveau sous-système d'Undertow de JBoss EAP 7 est capable de fonctionner correctement sans ce comportement et si le comportement doit être migré manuellement. Ce message d'avertissement peut se produire pour les attributs de valve suivants :

  • 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

    • remoteIpHeader

      Si défini, mais non configuré à "x-forwarded-for"

    • protocolHeader

      Si défini, mais non configuré à "x-forwarded-proto"

A.4. Compatibilité et Interopérabilité entre les versions

Cette section décrit la compatibilité et l'interopérabilité Client/Serveur EJB et les composants de messagerie entre les versions de JBoss EAP 5, JBoss EAP 6, et JBoss EAP 7.

EJB distant via IIOP

Vous ne devriez pas rencontrer de problèmes avec les configurations suivantes :

  • Se connecter d'un client JBoss EAP 5 à un serveur JBoss EAP 7
  • Se connecter d'un client JBoss EAP 6 à un serveur JBoss EAP 7
  • Se connecter d'un client JBoss EAP 7 à un serveur JBoss EAP 6
  • Se connecter d'un client JBoss EAP 7 à un serveur JBoss EAP 5

EJB distant via JNDI

Vous ne devriez pas rencontrer de problèmes avec les configurations suivantes :

  • Se connecter d'un client JBoss EAP 6 à un serveur JBoss EAP 7
  • Se connecter d'un client JBoss EAP 7 à un serveur JBoss EAP 6

JBoss EAP 6 fournit un support pour la spécification EJB 3.1 et introduit l'usage des espace-noms JNDI globaux normalisés, encore utilisés dans JBoss EAP 7. En raison du changement dans les espace-noms JNDI, les configurations suivantes ne sont pas compatibles :

  • Se connecter d'un client JBoss EAP 5 à un serveur JBoss EAP 7 ou à un serveur JBoss EAP 6
  • Se connecter d'un client JBoss EAP 7 ou JBoss EAP 6 à un serveur JBoss EAP 5

Pour plus d'informations sur les changements d'espace-noms JNDI standardisés, voir Changements JNDI dans le Guide de migration de JBoss EAP 6.

EJB distant utilisant @WebService

Vous ne devriez pas rencontrer de problèmes avec les configurations suivantes :

  • Se connecter d'un client JBoss EAP 5 à un serveur JBoss EAP 7
  • Se connecter d'un client JBoss EAP 6 à un serveur JBoss EAP 7
  • Se connecter d'un client JBoss EAP 7 à un serveur JBoss EAP 6
  • Se connecter d'un client JBoss EAP 7 à un serveur JBoss EAP 5

Client autonome de messagerie

Vous ne devriez pas rencontrer de problèmes avec les configurations suivantes :

  • Se connecter d'un client JBoss EAP 6 à un serveur JBoss EAP 7
  • Se connecter d'un client JBoss EAP 7 à un serveur JBoss EAP 6

Dans la configuration suivante, si le client utilise l'API HornetQ d'une messagerie spécifique plutôt que l'API JMS générique, la connexion est possible. Cependant, les recherches JNDI doivent être adressées via l'extension de nommage JNDI de l'ancien JBoss EAP hérité fournie dans JBoss EAP 7.

  • Se connecter d'un client JBoss EAP 5 à un serveur JBoss EAP 7

La messagerie intégrée de JBoss EAP 7 n'est pas en mesure de se connecter à HornetQ 2.2.x fourni dans JBoss EAP 5 en raison de problèmes de compatibilité de protocole. Pour cette raison, les configurations suivantes ne sont pas compatibles.

  • Se connecter d'un client JBoss EAP 7 à un serveur JBoss EAP 5

MDB Messagerie

Vous ne devriez pas rencontrer de problèmes avec les configurations suivantes :

  • Se connecter d'un client JBoss EAP 6 à un serveur JBoss EAP 7
  • Se connecter d'un client JBoss EAP 7 à un serveur JBoss EAP 6

Dans la configuration suivante, si le client utilise l'API HornetQ d'une messagerie spécifique plutôt que l'API JMS générique, la connexion est possible. Cependant, les recherches JNDI doivent être adressées via l'extension de nommage JNDI de l'ancien JBoss EAP hérité fournie dans JBoss EAP 7.

  • Se connecter d'un client JBoss EAP 5 à un serveur JBoss EAP 7

La messagerie intégrée de JBoss EAP 7 n'est pas en mesure de se connecter à HornetQ 2.2.x fourni dans JBoss EAP 5 en raison de problèmes de compatibilité de protocole. Pour cette raison, les configurations suivantes ne sont pas compatibles.

  • Se connecter d'un client JBoss EAP 7 à un serveur JBoss EAP 5

Ponts JMS

Vous ne devriez pas rencontrer de problèmes avec les configurations suivantes :

  • Se connecter d'un client JBoss EAP 5 à un serveur JBoss EAP 7
  • Se connecter d'un client JBoss EAP 6 à un serveur JBoss EAP 7
  • Se connecter d'un client JBoss EAP 7 à un serveur JBoss EAP 6
  • Se connecter d'un client JBoss EAP 7 à un serveur JBoss EAP 5