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 :
- Restrictions générales :
- Niveaux Java pris en charge
- Le chemin et le nom du répertoire d'installation ne peuvent pas comporter de caractères autres que des caractères ASCII.
- Changer de source de données JDBC à l'exécution peut faire échouer JPA
- 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
- Les scripts du WebSphere Application Server Traditional ne fonctionnent pas avec Liberty
- Restrictions concernant les ensembles de fichiers
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é
- Restrictions concernant les recherches java:global
- Applications ne démarrant pas sur un serveur Liberty imbriqué
- Restrictions liées à la prise en charge JCA générique et à l'adaptateur de ressources WebSphere MQ
- La gestion de versions n'est pas possible pour les applications du 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
- Les applications de session partagée doivent stocker les objets dans des bibliothèques partagées
- Configuration de la persistance de session
- Les sessions JMS déplacées et traitées localement ne fonctionnent pas dans Liberty
- Utilisation par Liberty de la messagerie IBM MQ
Applications Liberty s'exécutant dans IBM Cloud Private
Restrictions relatives à la consignation JSON
- Restrictions spécifiques aux fonctions Liberty :
- Restrictions concernant la fonction Centre d'administration
- Restriction concernant la fonction appClient-1.0
- Restrictions concernant la fonction appSecurity-2.0
- Restrictions concernant la fonction de validation de bean
- Restrictions concernant la fonction concurrent-1.0
- Restrictions concernant la fonction de cache dynamique
- Restrictions relatives à la fonction EJB (Enterprise JavaBeans)
- Restrictions concernant la fonction jacc-1.5
- Restrictions concernant la fonction jpa-2.1
- Restrictions concernant la fonction jsf-2.2
- Restrictions concernant la fonction jsp-2.2
- Restrictions concernant la fonction logstashCollector-1.0
- Restriction concernant la fonction monitor-1.0
Restrictions concernant la fonction openapi-3.0
- Restrictions concernant la fonction requestTiming-1.0
- Restriction concernant la fonction restConnector-1.0
- Restrictions concernant la fonction scim-1.0
- Restrictions concernant la fonction socialLogin-1.0
- Restrictions concernant la fonction sipServlet-1.1
- Restrictions concernant la fonction wmqJmsClient-1.1
- Restrictions concernant la fonction wmqJmsClient-2.0
- 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.
Niveaux Java pris en charge
![[17.0.0.3 and later]](../ng_v17003plus.gif)
- Environnement d'exécution Java SE 6
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.
Sur les
plateformes réparties, les versions 32 bits et 64 bits
de Java sont
prises en charge.
Pour 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.
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
- 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"/>

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.
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.
- 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.
- 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]](../ng_v17003plus.gif)
Applications Liberty s'exécutant dans IBM Cloud Private
- 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]](../ng_v18001plus.gif)
Restrictions relatives à 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
![[16.0.0.4 and later]](../ng_v16004plus.gif)
- 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
- 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
- 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
- Aucun support n'est prévu pour la validation des beans à l'intérieur des applications OSGi.
- 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
- jvm.options
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
- 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 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.
Restrictions concernant la fonction jacc-1.5
- 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.
Restrictions concernant 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
- 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
- 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 :
- Démarrage du serveur Liberty avant le serveur Logstash. Il est recommandé de démarrer le serveur Logstash avant le serveur Liberty.
- 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
- 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]](../ng_v17003plus.gif)
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
- 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 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
- 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
- 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
- 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
- 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.