Problèmes et restrictions connus concernant l'environnement d'exécution

Certaines restrictions connues sont applicables lorsque vous travaillez avec un environnement d'exécution Liberty.

Notes sur l'édition

Si le système d'exploitation ne possède pas de notes sur l'édition, lorsque vous cliquez sur le lien, la page qui s'affiche indique que les notes sur l'édition n'ont pas été trouvées.

Liste des problèmes et limitations connus :

Niveaux Java pris en charge

Liberty est pris en charge par tous les environnements d'exécution Java™ SE 7 ou Java SE 8 (JRE) ou SDK Java conforme SDK et est soumis aux niveaux minimaux pris en charge affichés pour les implémentations spécifiques ci-après. [17.0.0.3 and later]
Environnement d'exécution Java SE 6
[17.0.0.3 and later]Important : La prise en charge de l'utilisation de Java SE 6 avec WebSphere Liberty s'est terminée en septembre 2017. Le noyau Liberty a été recompilé à 17.0.0.3. A partir de 17.0.0.3, le noyau Liberty ne s'exécute plus avec Java SE 6. Si vous continuez d'utiliser Java SE 6 sur des versions antérieures après la date de fin de prise en charge, vous pouvez exposer votre environnement à des risques de sécurité.

Java Platform, Standard Edition 8 est le kit de développement de logiciels Java recommandé car il fournit les fonctions et les mises à jour de sécurité les plus récentes. Au lieu d'installer Java SE 8, vous pouvez également installer une autre versions Java SDK prise en charge.

Environnement d'exécution Java SE 7
Pour le SDK Java d'IBM, il s'agit du niveau IBM Runtime Environment, Java Technology Edition 7.0.4.1. Pour le JDK Oracle sous Windows et Linux, le niveau minimum pris en charge est Java SDK/JRE/JDK 7.0.17. Pour le JDK Oracle sous Mac OS X, le niveau minimum pris en charge est Java SDK/JRE/JDK 7.0 Mise à jour 15.
Important : A partir du groupe de correctifs 19.0.0.3, le noyau Liberty ne s'exécute plus avec Java SE 7. Pour en savoir plus, voir Avis de suppression.
Environnement d'exécution Java SE 8
For the Java SDK from IBM, the minimum supported level is IBM SDK, Java Technology Edition, Version 8. For the JDK from Oracle, the minimum supported level is Java 8 update 25.

For distributed platformsSur les plateformes réparties, les versions 32 bits et 64 bits de Java sont prises en charge. For z/OS platformsSur la plateforme z/OS, seule la version 64 bits de Java est prise en charge.

For distributed platformsPour les systèmes Windows et Linux, vous pouvez utiliser soit le JDK d'Oracle, soit le SDK Java d'IBM. Si vous développez des applications sur Windows ou Linux et prévoyez de les déployer sur un serveur s'exécutant sur WebSphere Application Server Traditional, utilisez le kit de développement logiciel Java d'IBM. Pour les systèmes HP et Mac OS, utilisez le JDK d'Oracle. For z/OS platformsPour les systèmes z/OS, utilisez le kit de développement logiciel Java SDK d'IBM.

For IBM i platforms[17.0.0.3 and later]Pour IBM i V7R1, le niveau JDK minimum est IBM Java SE 7.0 32 bits JVM (5761JV1 option 14) ou IBM Java SE 7.0 64 bits JVM (5761JV1 option 15). Pour IBM i V7R2 et V7R3, le niveau JDK minimum est IBM Java SE 7.0 32 bits JVM (5770JV1 option 14) ou IBM Java SE 7.0 64 bits JVM (5770JV1 option 15).

Le chemin et le nom du répertoire d'installation ne peuvent pas comporter de caractères autres que des caractères ASCII.

Les JVM récentes ne prennent pas en charge pleinement l'utilisation de caractères non-ASCII avec les commandes -jar et -javaagent. Utilisez uniquement des caractères ASCII dans les noms et chemins de votre répertoire d'installation.

Changer de source de données JDBC à l'exécution peut faire échouer JPA

Si le type de dictionnaire de base de données n'est pas spécifié via les propriétés, OpenJPA le détecte et le calcule à la création du premier gestionnaire d'entité, lorsque la connexion à la base de données est établie. Ce type de dictionnaire est utilisé pour tous les gestionnaires d'entité qui sont ensuite créés. Si vous changez de source de données JDBC alors que l'application est en cours d'exécution, la fabrique de gestionnaire d'entité ne détecte pas ce changement et continue à utiliser l'ancien dictionnaire pour les opérations portant sur la nouvelle source de données. Il peut en résulter des échecs si le changement de source de données implique également un changement de fournisseur.

Lorsque vous changez de fournisseur de base de données, redémarrez l'application.

La modification des propriétés dataSource, jdbcDriver, connectionManager et du fournisseur JDBC à l'exécution peut être à l'origine de défaillances de JPA.

Si, alors que le serveur est lancé, vous modifiez la configuration des éléments dataSource, jdbcDriver ou connectionManager ou l'une quelconque des listes de propriétés du fournisseur JDBC (par exemple, properties.db2.jcc ou properties.oracle), cela risque d'entraîner des échecs J2CA8040E. Les messages indiquent qu'un même élément connectionManager ne peut pas être associé à plusieurs éléments dataSource. Ils sont générés même si, dans votre configuration, un seul élément connectionManager est associé à l'élément dataSource.

Lorsque vous mettez à jour la configuration de l'une de ces ressources JDBC, redémarrez ensuite le serveur.

Une application tributaire d'un résultat renvoyé par getRealPath doit être déployée non pas comme un fichier WAR, mais sous forme décompressée

La spécification Java EE stipule que la méthode getRealPath() renvoie une valeur null si le contenu est rendu disponible depuis un fichier WAR (archive Web). Lorsque vous déployez un fichier WAR dans Liberty, le fichier archive n'est pas extrait automatiquement dans une structure de répertoires. Il est donc possible que l'application ne démarre pas. Si votre application est tributaire d'un résultat renvoyé par l'appel getRealPath(), vous devez la déployer comme application Web décompressée, et non comme un fichier WAR. Par exemple, vous pouvez extraire manuellement le contenu du fichier WAR et copier la structure de répertoires obtenue dans le répertoire dropins.

Les scripts du WebSphere Application Server Traditional ne fonctionnent pas avec Liberty

Vous ne pouvez pas utiliser les scripts qui se trouvent dans le répertoire bin du WebSphere Application Server Traditional pour administrer Liberty.

Restrictions concernant les ensembles de fichiers

Les restrictions suivantes s'appliquent aux ensembles de fichiers :
  • L'élément fileset ne se prête pas à l'exploration récursive des sous-répertoires du répertoire de base. Par exemple, les instructions suivantes ne sont pas prises en charge :
    <fileset id="testFileset" dir="\temp" includes="**\a.jar"/> 
    <fileset id="testFileset" dir="\temp" includes="a\a.jar"/>
    <fileset id="testFileset" dir="\temp" includes="*\a.jar"/>
    <fileset id="testFileset" dir="\temp" includes="a\b\a.jar"/>
For Windows platforms

Lorsque vous annulez la publication d'une bibliothèque partagée, elle ne peut pas être supprimée tant que le serveur n'est pas arrêté

Lorsque vous retirez une bibliothèque partagée d'un serveur, son fichier JAR n'est pas immédiatement libéré par le serveur. Par conséquent, le système d'exploitation ne sait pas que le fichier n'est plus utilisé et il ne vous laisse pas le supprimer. Lorsque vous arrêtez ensuite le serveur, le fichier JAR de la bibliothèque est libéré et vous pouvez alors le supprimer.

For z/OS platforms

L'APAR z/OS OA37620 est indispensable pour permettre le traçage d'un groupe de trace spécifique sur le serveur

Si vous voulez tracer des groupes de trace individuels, appliquez l'APAR z/OS OA37620. Lorsque vous activez le traçage pour Liberty sur la plateforme z/OS, utilisez la syntaxe package/classe (à savoir com.ibm.ws.*=all) à moins que le support IBM ne vous donne des indications contraires.

Restrictions concernant les recherches java:global

Les ressources définies dans les applications avec des recherches java:global peuvent être utilisées pour accéder aux noms déclarés par les applications qui sont déployées uniquement dans le serveur en cours.

Applications ne démarrant pas sur un serveur Liberty imbriqué

Assurez-vous que le processus Java qui démarre le serveur Liberty imbriqué a été démarré avec l'argument de machine virtuelle Java -javaagent qui désigne le fichier rép_install_liberty/bin/tools/ws-javaagent.jar. Si l'argument de machine virtuelle Java -javaagent n'est pas utilisé, l'environnement d'exécution du serveur démarre mais le démarrage des applications échoue sans exception évidente.

Restrictions liées à la prise en charge JCA générique et à l'adaptateur de ressources WebSphere MQ

L'adaptateur de ressources MQ de WebSphere® peut être utilisé dans WebSphere Application Server Liberty soit avec la fonction wmqJmsClient-1.1 ou wmqJmsClient-2.0, soit à l'aide de la prise en charge JCA générique.

Vous pouvez utiliser l'adaptateur de ressources WebSphere version 7.5 avec Liberty version 8.5.5 et versions suivantes. Si vous voulez utiliser l'adaptateur de ressources WebSphere MQ version 8.0 qui est basé sur l'adaptateur de ressources JMS 2.0, vous devez vous assurer d'utiliser la dernière version de Liberty qui est compatible avec l'adaptateur de ressources JMS 2.0.

Remarques :
  • Avec Liberty version 8.5.5.2, la fonction wmqJmsClient-1.1 doit être utilisée avec un adaptateur de ressources IBM MQ version 7.5.0.5 ou ultérieure.
  • Avec Liberty version 8.5.5.6, la fonction wmqJmsClient-2.0 doit être utilisée avec un adaptateur de ressources IBM MQ version 8.0.0.3 ou ultérieure.

Pour en savoir plus sur les informations de compatibilité de version entre l'adaptateur de ressources WebSphere MQ et Liberty, voir Reference to obtain the WebSphere MQ resource adapter.

Si vous utilisez la prise en charge JCA générique, les restrictions suivantes s'appliquent :
  • Pour exécuter l'adaptateur de ressources IBM® WebSphere MQ sur z/OS, vous devez utiliser la fonction wmqJmsClient-1.1 ou wmqJmsClient-2.0.
  • Le traçage et la journalisation ne sont pas intégrés dans le système de trace Liberty avec la prise en charge JCA générique. La trace est écrite dans un fichier distinct et elle doit être activée avec les propriétés système. La procédure d'activation de la trace est la même que la procédure de configuration des classes WebSphere MQ pour la fonction de trace JMS pour un environnement Java Standard. Voir Java Standard Environment Trace stanza.
  • Les classes IBM MQ pour Java ne sont pas prises en charge dans Liberty. Elles ne doivent pas être utilisées avec la fonction de messagerie IBM MQ Liberty ou avec la prise en charge JCA générique. Pour plus d'informations, voir Using WebSphere MQ Java Interfaces in J2EE/JEE Environments.

La gestion de versions n'est pas possible pour les applications du répertoire dropins

Dans le cas des applications qui se trouvent dans le répertoire dropins, le nom et l'extension de fichier sont utilisés par le moniteur d'applications afin de déterminer le type de l'application et de générer l'ID et le nom de l'application. Il est donc impossible de spécifier le numéro de version de l'application en utilisant le nom de fichier ou l'extension de fichier. Dans un environnement de production, il n'est pas recommandé d'utiliser le répertoire dropins.

Les fonctions de collectivité, de routage dynamique et de dimensionnement ne peuvent pas être utilisées avec la fonction cdi-1.2

N'utilisez pas la fonction collectiveController-1.0, collectiveMember-1.0, clusterMember-1.0, dynamicRouting-1.0, scalingController-1.0 ou scalingMember-1.0 avec la fonction Contexts and Dependency Injection 1.2 (cdi-1.2).

Les applications de session partagée doivent stocker les objets dans des bibliothèques partagées

Lorsque vous utilisez l'extension d'application shared-session-context, ou <shared-session-context value="true"/> dans ibm-application-ext.xml, tous les objets qui sont stockés dans la session doivent être disponibles de sorte que la session puisse être invalidée.

Configuration de la persistance de session

Il existe un seul fichier server.xml pour chaque serveur et non un fichier server.xml pour chaque fichier EAR ou WAR. Pour définir la persistance de session dans une base de données, ajoutez :

<httpSessionDatabase id="SessionDB" dataSourceRef="SessionDS" ... /> 

Dans Liberty, ce réglage de la base de données s'applique à tous les fichiers EAR et WAR. Il n'est pas possible de définir des bases de données avec une persistance de session et d'autres sans.

Les sessions JMS déplacées et traitées localement ne fonctionnent pas dans Liberty

Dans WebSphere Application Server Traditional, vous pouvez développer des applications pour tirer parti des sessions JMS traitées localement. Lorsque vous déplacez ces applications vers Liberty, elles se comportent différemment ou ne fonctionnent pas du tout.

Même si WebSphere Application Server Traditional permet les sessions JMS traitées localement, le déplacement d'une session JMS WebSphere Application Server Traditional traitée localement vers Liberty n'est pas autorisé.

Utilisation par Liberty de la messagerie IBM MQ

Lorsque Liberty utilise IBM MQ comme fournisseur de messagerie, le critère de réutilisation d'une connexion gratuite du pool de connexion JMS est différent du critère de réutilisation dans WebSphere Application Server Traditional. De manière plus spécifique, le taux de réutilisation de Liberty est largement inférieur au taux de réutilisation de WebSphere Application Server Traditional si une application JMS utilise une authentification des conteneurs pour une fabrique de connexions et plusieurs utilisateurs authentifiés utilisent le même pool de connexion. Le taux de réutilisation de Liberty est inférieur car la connexion gratuite qui est créée par un utilisateur authentifié ne peut pas être réutilisée par un autre utilisateur authentifié dans Liberty et peut entraîner des régénérations de connexions fréquentes. Vous pouvez utiliser l'authentification d'application avec les propriétés username et password de properties.wmqJms si le taux de réutilisation de Liberty ne répond pas aux exigences de performances.

[17.0.0.3 and later]

Applications Liberty s'exécutant dans IBM Cloud Private

Lorsque vous déployez des applications Liberty dans IBM Cloud Private, les restrictions suivantes existent :
  • La mise à l'échelle automatique est uniquement basée sur l'utilisation de l'unité centrale, et non sur les métriques personnalisées.
  • Ingress prend uniquement en charge les annotations et la configuration de base, telles que la racine de contexte unique.
  • Il se peut que vous rencontriez un problème lors de l'accès aux applications qui utilisent Ingress sur le protocole HTTP. Si vous accédez à une application sur http://proxy_host/, vous êtes redirigé vers le port 80, lequel est incorrect, et l'application est inaccessible. Retirez le port 80 de l'URL pour remédier à ce problème.
  • Actuellement, le diagramme Liberty Helm ne prend en charge la persistance des journaux de transaction que pour une seule réplique.
[18.0.0.1 and later]

Restrictions relatives à la consignation JSON

Les limitations suivants s'appliquent lors de l'utilisation de la consignation JSON :
  • Lorsque la consignation binaire est configurée, les enregistrements de journal écrits sur la console conservent un format de base même lorsque la consignation JSON est activée.
  • Lorsque la consignation JSON est activée sur z/OS, il se peut que certains messages soient manquants pendant la période de démarrage de serveur.
  • Lorsque la consignation JSON est activée, les objets Throwable qui sont consignés dans le fichier System.out/err ne sont pas tronqués avec [internal classes].

Restrictions concernant la fonction Centre d'administration

Les restrictions suivantes s'appliquent à la fonction adminCenter-1.0 :
  • L'utilisation d'une machine virtuelle IBM Java (JVM) disponible avec un produit WebSphere Application Server Traditional, tel que WebSphere Application Server Network Deployment Liberty, peut empêcher l'affichage de l'interface Administrative Center de Liberty ("Centre d'administration") dans un navigateur. Par défaut, la machine virtuelle Java IBM disponible avec un produit WebSphere Application Server Traditional pointe vers les classes de sécurité qui sont uniquement disponibles avec un produit WebSphere Application Server Traditional et non vers les classes de sécurité requises par Centre d'administration, qui nécessite Secure Sockets Layer (SSL). Utilisez une machine virtuelle Java qui prend en charge Liberty et SSL.
    Vous pouvez obtenir via les offres Installation Manager ou developerWorks une machine virtuelle Java (JVM) prenant en charge les produits Liberty et SSL :
    • Depuis Installation Manager, sélectionnez d'abord le produit Liberty, puis WebSphere SDK for Liberty. Utilisez Installation Manager pour installer le produit Liberty et le kit de développement de logiciel (SDK). Le SDK WebSphere SDK pour Liberty inclut la prise en charge requise pour les produits Liberty et SSL et comprend un client Java, JConsole.
    • Accédez à http://www.ibm.com/developerworks/java/jdk/index.html sur le site Web developerWorks et téléchargez un kit de développement de logiciel (JDK) IBM Java pour votre système d'exploitation. Le site Web developerWorks ne propose pas de JVM pour tous les systèmes d'exploitation. Par exemple, vous devez obtenir le kit JDK d'Eclipse pour les systèmes d'exploitation Windows.
  • Le graphique Utilisation de l'unité centrale de la vue Moniteur du Centre d'administration indique une utilisation de 0 de l'unité centrale pour les machines virtuelles Java qui ne fournissent pas de statistiques sur leur utilisation par les processus. Pour plus d'informations sur le graphique, voir Surveillance des métriques dans le Centre d'administration.
[16.0.0.4 and later]Les restrictions suivantes s'appliquent pour l'outil Java Batch :
  • Les journaux des travaux des machines distantes ne peuvent pas être affichés à moins que chaque serveur distant ayant des travaux par lots ou des journaux de travaux ait une configuration CORS. Voir Affichage des travaux par lots Java dans le Centre d'administration.
  • Si des journaux d'instance sont affichés, une erreur se produira si les exécutions sont réparties entre plusieurs hôtes.
  • L'outil Java Batch implique l'utilisation d'une base de données persistante avec la fonction batchManagement-1.0.

Restriction concernant la fonction appClient-1.0

Les restrictions suivantes s'appliquent à la fonction appClient-1.0 :
  • La fonction ne prend pas en charge les clients d'application Java EE et ne peut lancer que des programmes client autonomes.

Restrictions concernant la fonction appSecurity-2.0

Les restrictions suivantes s'appliquent à la fonction appSecurity-2.0 :
  • Pour les applications EJB, run-as-mode pour SYSTEM_IDENTITY n'est pas pris en charge dans les paramètres d'extension du fichier ibm-ejb-jar-ext.xml.
  • L'API getCallerIdentity n'est pas prise en charge pour les beans session singleton.
  • Des noms de rôle peuvent être référencés par les API HttpServletRequest.isUserInRole et EJBContext.isCallerInRole ou par des éléments du descripteur de déploiement sans qu'il ne soit nécessaire de les déclarer d'abord avec l'annotation @DeclareRoles ou l'élément <security-role/> dans le descripteur de déploiement. Toutefois, les rôles doivent être déclarés avant d'être utilisés dans WebSphere Application Server Traditional.

Restrictions concernant la fonction de validation de bean

La restriction suivante s'applique à la fonction beanvalidation-1.0 :
  • Aucun support n'est prévu pour la validation des beans à l'intérieur des applications OSGi.
Les restrictions suivantes s'appliquent à la fonction beanValidation-1.1 :
  • Aucun support n'est prévu pour la validation des beans à l'intérieur des applications OSGi.
  • Les applications qui fournissent un implémentation de ConstraintValidatorFactory personnalisée dans un fichier validation.xml avec la fonction beanValidation-1.0 ne se compilent pas dans l'API Validation 1.1.
  • Si un fichier validation.xml ne se trouve pas dans le module auquel il est associé, il peut alors y avoir un seul fichier validation.xml et la propriété com.ibm.ws.beanvalidation.allowMultipleConfigsPerApp doit être définie sur false dans l'un des fichiers suivants :
    • jvm.options
      -Dcom.ibm.ws.beanvalidation.allowMultipleConfigsPerApp=false
    • bootstrap.properties
      com.ibm.ws.beanvalidation.allowMultipleConfigsPerApp=false

Restriction concernant la fonction collectiveController-1.0

Si vous démarrez un serveur de contrôleur de collectivité, puis changez votre configuration IP, le contrôleur ne fonctionne plus correctement.

Restrictions concernant la fonction concurrent-1.0

Les restrictions suivantes s'appliquent à la fonction concurrent-1.0 :

Pour le contexte d'unité d'exécution de type securityContext, toute information personnalisée dans le sujet qui n'a pas été ajoutée à l'aide d'un module de connexion JAAS n'est pas propagée. Par exemple, si le sujet de l'émetteur contient un principal personnalisé qui a été ajouté par un intercepteur de relations de confiance, le sujet propagé ne contient pas ce principal personnalisé.

Restrictions concernant la fonction de cache dynamique

Les fonctions de cache dynamique suivantes ne sont pas disponibles ou leur disponibilité est limitée :
  • La réplication de cache n'est pas prise en charge.
  • Seul le mode de mise en cache sur disque hautement performant est pris en charge par les techniques d'expulsion aléatoires et basées sur la taille.
  • La mise en cache côté serveur et la mise en cache côté client de services Web, ainsi que le cache de portlet dans le fichier cachespec.xml, ne sont pas pris en charge.
  • La mise en cache de servlet pour les servlets SingleThreadModel n'est pas prise en charge.
  • La définition de la configuration du cache à l'aide de fichiers de propriétés n'est pas prise en charge pour les fichiers JAR contenant des EJB (Enterprise JavaBeans) seulement.
  • La limitation de la taille du cache de segment de mémoire ne fonctionne que pour les machines virtuelles Java 32 bits.

Restrictions relatives à la fonction EJB (Enterprise JavaBeans)

Les restrictions suivantes s'appliquent aux fonctions EJB :
  • Les modules EJB antérieurs à la version 3.0 ne sont pas pris en charge si vous utilisez uniquement les fonctions EJB Lite parce que les interfaces EJB home ne sont pas incluses dans EJB Lite. Cette restriction signifie également que les liaisons et les extensions utilisant le format de fichier .xmi au lieu du format de fichier .xml ne sont pas prises en charge.
  • Les beans session ne sont pas liés à l'espace de nom ejblocal, ce qui signifie que les recherches JNDI et les noms de liaison ejb-ref doivent utiliser des noms java:global, java:app ou java:module. Les éléments simple-binding-name et les éléments d'interface binding-name sont ignorés dans les fichiers ibm-ejb-jar-bnd.xml.
  • Le répertoire de passivation de bean avec état ne peut pas être configuré. Les fichiers sont passivés dans la zone de travail du serveur.

Restriction concernant la fonction j2eeManagement-1.1

Les restrictions suivantes s'appliquent à la fonction j2eeManagement-1.1 :

  • La méthode Management EJB getListenerRegistry() n'est pas prise en charge. Vous ne pouvez pas enregistrer un programme d'écoute de notification dans un composant Management EJB.

Restrictions concernant la fonction jacc-1.5

Pour la fonction jacc-1.5, les configurations suivantes sont ignorées :
  • Informations d'autorisation (attributs users et groups de l'attribut auhtorizations) dans un fichier ibm-application-bnd.xml ou un fichier ibm-application-bnd.xmi du fichier ear de l'application.
  • Informations d'autorisation (attribut user, group et special-subject de l'attribut security-role dans l'élément application-bnd) dans le fichier server.xml.

Restriction concernant la fonction jaxb-2.2

Les restrictions suivantes s'appliquent à la fonction jaxb-2.2 :
  • Si votre application requiert des classes d'API JAXB et a déjà été démarrée alors que la fonction de serveur jaxb-2.2 doit être activée, vous devez redémarrer le serveur avec l'option --clean pour que votre application puisse appeler l'API JAXB et les classes d'implémentation fournies par la fonction jaxb-2.2. Sinon, votre application peut rester liée à l'API JAXB et aux classes d'implémentation du SDK Java.
  • Si la fonction de serveur jaxb-2.2 est activée et que vous voulez utiliser votre propre API JAXB et vos propres classes d'implémentation pour votre application, vous devez placer votre propre API JAXB et vos propres fichiers JAR d'implémentation dans le répertoire /WEB-INF/lib de votre application, et configurer le chargeur de classe de votre application de sorte qu'il utilise le comportement de délégation parentLast. Sinon, l'API JAXB et les classes d'implémentation fournies par la fonction jaxb-2.2 entrent en vigueur. Pour plus d'informations concernant la configuration du comportement du chargeur de classe pour vos applications dans Liberty, voir Remplacement d'une API spécifique par une autre version fournie par l'environnement du serveur.

Restrictions concernant la fonction jaxws-2.2

Les restrictions suivantes s'appliquent à la fonction jaxws-2.2 :
  • Si votre application fournit sa propre copie de fichiers JAR CXF comme bibliothèques d'application, par exemple, dans le répertoire WEB-INF/lib d'une application Web, vous ne pouvez pas activer la fonction jaxws-2.2 dans le fichier server.xml.
  • Etant donné que la fonction jaxws-2.2 dépend de la fonction jaxb-2.2, les restrictions de la fonction jaxb-2.2 concernent également la fonction jaxws-2.2.
  • Si votre application requiert des classes d'API JAX-WS et a déjà été démarrée alors que la fonction de serveur jaxws-2.2 doit être activée, vous devez redémarrer le serveur avec l'option --clean pour que votre application puisse appeler l'API JAX-WS 2.2 et les classes d'implémentation fournies par la fonction jaxws-2.2. Sinon, votre application peut rester liée à l'API JAX-WS et aux classes d'implémentation du SDK Java.
  • Le fichier de liaison des services Web pour Liberty est le fichier ibm-ws-bnd.xml. Les fichiers de liaison des services Web suivants pour WebSphere Application Server Traditional ne sont pas pris en charge :
    • ibm-webservices-ext.xmi
    • ibm-webservices-bnd.xmi
    • ibm-webservicesclient-ext.xmi
    • ibm-webservicesclient-bnd.xmi
    • ws-security.xml
  • Les classes ou les configurations Apache Axis2 ne sont pas prises en charge.
  • Les fournisseurs de services Web qui implémentent l'interface javax.xml.ws.Provider<OMElement> ou javax.xml.ws.Provider<String> ne sont pas pris en charge.
  • L'attribut content-id des pièces jointes MIME doit être entourés par des signes supérieurs ou inférieurs pour Liberty, par exemple <testID>.
  • L'option -inlineSchemas n'est pas prise en charge par l'outil wsgen fourni par Liberty.
  • Activez MTOM si vous désirez transférer des données binaires volumineuses à l'aide des services Web JAX-WS pour éviter une erreur de saturation de la mémoire (OOM).
  • Pour les applications de service Web, si le client du service et le fournisseur du service ne proviennent pas de la même application et que le fichier WSDL dans l'application du fournisseur de services a été modifié, vous devez redémarrer manuellement l'application du client de service Web pour éviter le problème du cache de la définition WSDL.

Restrictions concernant la fonction jsf-2.2

Les restrictions suivantes s'appliquent à la fonction jsf-2.2 :
  • Lorsque vous utilisez la fonction jsf-2.2 avec un fichier faces-config.xml et spécifiez la version 2.2 et un espace de nom, une erreur est générée.
  • Des conflits surgissent entre les fonctions si vous activez jsf-2.2 avec cdi-1.2, ejb-3.2 et jpa-2.1.

Restrictions concernant la fonction jsp-2.2

Les restrictions suivantes s'appliquent à la fonction jsp-2.2 :
  • Aucun support n'est prévu pour l'option de configuration useInMemory, ce qui exclut toute possibilité de stocker le fichier JSP traduit uniquement en mémoire.

Restrictions concernant la fonction jpa-2.1

Pour la fonction jpa-2.1, les restrictions suivantes s'appliquent :
  • Vous ne pouvez pas utiliser un autre fournisseur JPA 2.1. Si vous avez besoin d'une prise en charge 2.1, vous devez utiliser le fournisseur intégré.
  • Vous ne pouvez pas utiliser des fonctions ou annotations spécifiques à EclipseLink dans votre application. Vous pouvez uniquement utiliser les API javax.persistence.

Restrictions concernant la fonction logstashCollector-1.0

Les limitations suivantes concernent la fonction logstashCollector-1.0 :
  • Perte de données – Il se peut que certains événements générés dans Liberty ne soient pas acheminés comme prévu à Logstash. Une perte de données peut se produire dans les scénarios suivants :
    1. Démarrage du serveur Liberty avant le serveur Logstash. Il est recommandé de démarrer le serveur Logstash avant le serveur Liberty.
    2. Conditions de charge élevée. Des événements peuvent être éliminés si leur création dans Liberty est plus rapide que leur traitement par le pipeline d'événements Liberty, par Logstash, et d'autres consommateurs d'événements en aval. Liberty utilise des mémoires tampon pour éviter toute perte de données lorsque la création d'événements est plus rapide que la consommation d'événements.
  • La fonction logstashCollector-1.0 est testée et compatible avec Logstash V2.x et Logstash V5.x.

Restriction concernant la fonction monitor-1.0

La restriction suivante s'applique à la fonction monitor-1.0 :
  • Si la fonction est retirée du fichier server.xml, vous devez redémarrer le serveur pour que les applications JAX-WS fonctionnent.
[17.0.0.3 and later]

Restrictions concernant la fonction openapi-3.0

Les restrictions suivantes sont applicables pour la fonction openapi-3.0 :

  • Contrairement à apiDiscovery-1.0, openapi-3.0 ne prend pas actuellement en charge la fonction d'essai Try it out! .
  • Lorsque vous affichez votre documentation sous http://hôte_Liberty:port_http/api/docs, https://hôte_Liberty:port_https/api/docs ou https://hôte_Liberty:port_https/ibm/api/docs avec Microsoft Internet Explorer 11, il renvoie un document YAML qui n'est pas formaté correctement. Pour régler ce problème, utilisez un navigateur tel que Mozilla Firefox ou Google Chrome.
  • openapi-3.0 ne prend pas en charge les configurations OASProvider multilingues. Spécifiez des fournisseurs qui renvoient un seul résultat.
  • Les annotations JAX-RS et OpenAPI ne sont pas toutes prises en charge actuellement.
  • Si la valeur de l'attribut de validation est modifiée durant l'exécution du serveur, les applications précédemment chargées devront être redémarrées pour que le nouveau paramètre de validation prenne effet pour ces applications.
  • Les portions suivantes du document OpenAPI ne sont pas validées :
    • composant
    • discriminateur
    • codage
    • extension
    • en-tête
    • lien
    • schéma
    • portées
    • xml

Restrictions concernant la fonction requestTiming-1.0

Les restrictions suivantes s'appliquent à la fonction requestTiming-1.0 :
  • Lorsqu'elle est activée, la fonction requestTiming-1.0 induit une dégradation de 4 % du débit maximal possible de l'application lorsqu'elle est mesurée avec l'application DayTrader. Même si l'impact sur votre application peut être inférieur ou supérieur, vous devez savoir qu'une dégradation des performances peut être perceptible.

Restriction concernant la fonction restConnector-1.0

Les restrictions suivantes s'appliquent à la fonction restConnector-1.0 :

  • Les utilisateurs de la fonction restConnector-1.0 ou de toute fonction incluant restConnector-1.0, telle que collectiveMember-1.0 et collectiveController-1.0, qui souhaitent exécuter des applications contenant un environnement d'exécution JAXRS 2.0 personnalisé doivent ajouter la fonction jaxrs-2.0 à ce serveur.

Restrictions concernant la fonction scim-1.0

Les restrictions suivantes concernent la fonction scim-1.0 :
  • Les attributs members ne sont pas extraits lorsque vous recherchez des attributs groups.
  • Les attributs groups de users ne sont pas extraits lorsque vous recherchez des attributs users.
  • Le type canonique direct/indirect ne peut pas être défini pour l'attribut groups de users.
  • Seul l'attribut email de l'utilisateur de type canonique, work, peut être défini.
  • Un seul attribut ims du type d'utilisateur canonique, work, peut être défini.
  • Les attributs de schéma étendus de SCIM, tels que entitlements, roles et x509Certificates, ne peuvent pas être définis ou renvoyés.
  • L'attribut userName ne peut pas être utilisé avec d'autres attributs dans un filtre.
  • Pour les utilisateurs des registres Basic et SAF, seuls les attributs userName, displayName, id, schema, meta.location et groups peuvent être définis. Les attributs userName et displayName ont la même valeur.
  • Les éléments List/query avec les registres Basic et SAF ne fonctionnent pas comme le registre ldapRegistry.
  • Les opérateurs tels que pr, gt, ge, lt, le, and, or et (), ne fonctionnent pas avec les registres Basic et SAF. De plus, un seul opérateur doit être utilisé dans le filtre pour les registres Basic et SAF.
  • Les registres Basic et SAF sont en lecture seule.
  • L'attribut groups ne peut pas être défini lorsque vous créez un attribut user.

Restrictions concernant la fonction sipServlet-1.1

Pour la fonction sipServlet-1.1, les restrictions suivantes ne s'appliquent qu'à la prise en charge du protocole SIP (Session Initiation Protocol) :
  • Les compteurs SIP pour l'infrastructure PMI (Performance Monitoring Infrastructure) ne sont pas pris en charge.
  • L'authentification simplifiée SIP et la section de sécurité (JSR 289 Section 17) ne sont pas prises en charge.
  • La mise en cluster et la persistance de boîte de dialogue SIP ne sont pas prises en charge.

Restrictions concernant la fonction socialLogin-1.0

La restriction suivante s'applique à la fonction socialLogin-1.0 :
  • Pour la fonction socialLogin-1.0, le formulaire de sélection de médias sociaux par défaut peut ne pas fonctionner correctement dans Internet Explorer sur le système d'exploitation Windows Server 2012. Lorsque vous choisissez un fournisseur et que le formulaire est soumis, Internet Explorer peut soumettre le texte du bouton affiché comme valeur par défaut à la place de la valeur HTML configurée pour le bouton. Pour contourner cette restriction, vous pouvez utiliser un autre navigateur Web. Les navigateurs autre que Internet Explorer fonctionnent correctement avec le formulaire de sélection par défaut.

Restrictions concernant la fonction wmqJmsClient-1.1

Les restrictions suivantes s'appliquent à la fonction wmqJmsClient-1.1 :
  • Vous devez définir manuellement la variable PATH dans les variables d'environnement Windows afin de désigner le répertoire bin de l'installation IBM MQ. Vous devez définir cette variable de chemin lorsque l'application utilise le mode de connexion liaison.
  • Les classes IBM MQ pour Java ne sont pas prises en charge dans Liberty. Elles ne doivent pas être utilisées avec la fonction de messagerie Liberty d'IBM MQ ou avec la prise en charge JCA générique. Pour plus d'informations, voir Using WebSphere MQ Java Interfaces in J2EE/JEE Environments.
  • Le type de transport BINDINGS_THEN_CLIENT de l'adaptateur de ressources de IBM MQ n'est pas pris en charge pour la fonction wmqJmsClient-1.1.
  • La fonction AMS (Advanced Messaging Security) n'est pas incluse dans la fonction wmqJmsClient-1.1.

Restrictions concernant la fonction wmqJmsClient-2.0

Les restrictions suivantes s'appliquent à la fonction wmqJmsClient-2.0 :
  • Vous devez définir manuellement la variable PATH dans les variables d'environnement Windows afin de désigner le répertoire bin de l'installation IBM MQ. Vous devez définir cette variable de chemin lorsque l'application utilise le mode de connexion liaison.
  • Les classes IBM MQ pour Java ne sont pas prises en charge dans Liberty. Elles ne doivent pas être utilisées avec la fonction de messagerie Liberty d'IBM MQ ou avec la prise en charge JCA générique. Pour plus d'informations, voir Using WebSphere MQ Java Interfaces in J2EE/JEE Environments.
  • Le type de transport BINDINGS_THEN_CLIENT de l'adaptateur de ressources de IBM MQ n'est pas pris en charge pour la fonction wmqJmsClient-2.0.

Icône indiquant le type de rubrique Rubrique de référence

Nom du fichier : rwlp_restrict.html