Liberty : Problèmes et restrictions connues concernant l'environnement d'exécution

Certaines restrictions connues s'appliquent lors de l'utilisation de l'environnement d'exécution de Liberty.

Liste des problèmes et limitations connus :

Niveaux Java pris en charge

Liberty est pris en charge par tout environnement d'exécution Java™ SE 6, Java SE 7 ou Java SE 8 ou Java SDK et est soumis aux niveaux minimaux pris en charge affichés pour les implémentations spécifiques ci-après.
Environnement d'exécution Java SE 6
Pour le SDK Java d'IBM, il s'agit du niveau Java 6 mise à jour 26.

Pour plateformes IBM iJava SE 6 n'est pas pris en charge sur IBM i V7R3.

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

Pour plateformes répartiesSur les plateformes réparties, les versions 32 bits et 64 bits de Java sont prises en charge.

Pour plateformes répartiesPour 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 plateformes IBM iRemarque : Pour obtenir le niveau Java minimum pris en charge pour IBM i, installez IBM Java SE 6.0 32 bits JVM (5761-JV1 option 11 ou 5770-JV1 option 11) ou IBM Java SE 6.0 64 bits (5761-JV1 option 12 ou 5770-JV1 option 12). Pour IBM i V7R1, installez également le groupe de PTF Java SF99572 de niveau 8 ou d'un niveau supérieur.

Pour IBM i V7R3, le niveau JDK minimum est IBM Java SE 7.0 32 bits JVM (5770-JV1 option 14) ou IBM Java SE 7.0 64 bits JVM (5770-JV1 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épertoire. Il est donc possible que l'application ne puisse pas démarrer. 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"/>
Pour plateformes Windows

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 des applications avec des recherches java:global ne peuvent être utilisées que pour accéder aux noms déclarés par les applications déployées sur le serveur courant.

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

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 et ultérieur]Pour la version bêta de l'outil Java Batch, les restrictions suivantes sont applicables :
  • Les journaux de travail des machines distantes ne peuvent pas s'afficher en raison de problèmes au niveau de l'authentification de sécurité.
  • Si des journaux d'instance sont affichés, une erreur se produira si les exécutions sont réparties entre plusieurs hôtes.
  • Les listes non filtrées affichent uniquement les résultats triés en fonction des dernières instances mises à jour.
  • Lorsque un filtre est exécuté pour tous, les résultats ne sont pas triés en fonction des dernières instances mises à jour.
  • Seulement cinquante résultats ou moins s'affichent dans la liste, indépendamment du fait que celle-ci ait été filtrée ou non.
  • L'utilisation de la version bêta de 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

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.
  • Le mode de mise en cache-disque hautement performant seulement est pris en charge avec des techniques d'expulsion aléatoire et basée 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 lors de l'utilisation de la fonction EJB Lite car 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.

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 renvoyé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 logstashCollector-1.0

Les limitations suivantes concernent la fonction logstashCollector-1.0 :
  • Perte de données - Certains des événements générés dans liberty peuvent ne pas réacheminés vers Logstash comme prévu. 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 est compatible avec Logstash V2.x.

Restrictions concernant la fonction logmetCollector-1.0

Les limitations suivantes s'appliquent à la fonction logmetCollector-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 à logmet. Une perte de données peut se produire sous le scénario suivant :

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

  • Perte de connexion - La connexion au service logmet dans Bluemix est souvent perdue.

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.

Restrictions concernant la fonction requestTiming-1.0

Les restrictions suivantes s'appliquent à la fonction requestTiming-1.0 :
  • Comme mesuré par l'application DayTrader, la fonction requestTiming-1.0, lorsqu'elle est activée, induit une dégradation de 4 % du débit maximal possible de l'application. 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 lors de la recherche de groups.
  • Les attributs groups de users ne sont pas extraits lors de la recherche de 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 retourné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 auront la même valeur.
  • Les éléments List/query avec les registres Basic et SAF ne fonctionne pas comme le registre ldapRegistry.
  • Les opérateurs tels que pr, gt, ge, lt, le, and, or et (), ne fonctionneront 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.
  • Lors de la création de user, l'attribut groups ne peut pas être défini.

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.

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 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 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 ne sera 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 contiendra pas ce principal personnalisé.

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

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

Nom du fichier : rwlp_restrict.html