Problèmes et restrictions connues concernant l'environnement d'exécution
Certains problèmes et restrictions connus s'appliquent lors de l'utilisation de l'environnement d'exécution du profil Liberty.
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 profil complet de WebSphere Application Server ne fonctionnent pas avec le profil Liberty
- Restrictions concernant les ensembles de fichiers
- Remplacement de classes depuis le SDK Java
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"
- Restrictions spécifiques aux fonctions Liberty :
Restrictions concernant le centre d'administration
- Restrictions concernant la fonction appSecurity-2.0
- Restrictions concernant la fonction de validation de bean
- Restrictions concernant le dispositif de cache dynamique
- Restrictions concernant le dispositif ejbLite-3.1
Restrictions concernant la fonction eventLogging-1.0
Restrictions concernant la fonction jpa-2.1
- Restrictions concernant le dispositif jsp-2.2
- Restriction concernant la fonction monitor-1.0
Restrictions concernant la fonction requestTiming-1.0
- Restrictions concernant la fonction wmqJmsClient-1.1
Restrictions concernant la fonction wmqJmsClient-2.0
Restrictions concernant la fonction concurrent-1.0
Restrictions concernant la fonction jacc-1.5
- 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
- Environnement d'exécution Java SE 6
- Pour le SDK Java d'IBM®, il s'agit du niveau Java 6 mise à jour 26.
- 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.
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 indifféremment le JDK
d'Oracle ou celui d'IBM.
Si vous développez des applications sur Windows ou Linux et
que vous prévoyez de les déployer sur un serveur fonctionnant avec le
profil complet de WebSphere Application Server, vous
devez utiliser le JDK d'IBM.
Pour les systèmes HP et Mac OS, utilisez le JDK d'Oracle.

![[8.5.5.2 ou ultérieure]](../ng_v8552.gif)
![[8.5.5.2 ou ultérieure]](../ng_v8552.gif)
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. Pour cette raison, utilisez uniquement des caractères ASCII dans le nom et le chemin 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 le profil Liberty, le profil n'extrait pas automatiquement le fichier archive 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 profil complet de WebSphere Application Server ne fonctionnent pas avec le profil Liberty
Vous ne pouvez pas utiliser les scripts qui se trouvent dans le répertoire bin du profil complet de WebSphere Application Server pour administrer le profil 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"/>
Remplacement de classes depuis le SDK Java
- Si vous utilisez javac pour effectuer la génération à partir de la ligne de commande, compilez votre code avec l'option javac -endorseddirs et les fichiers JAR qui se trouvent dans le répertoire ${wlp.install.dir}/dev/specs.
- Si vous utilisez Apache Ant pour la génération, compilez votre
code avec l'élément enfant <compilerarg de la
tâche javac et les fichiers JAR qui se trouvent dans
le répertoire ${wlp.install.dir}/dev/specs.
Dans le script de génération, spécifiez l'option
-endorseddirs et le répertoire
${wlp.install.dir}/dev/specs en tant qu'éléments
<compilerarg distincts. Exemple :
<javac srcdir="src" destdir="classes"/> <compilerarg value="-endorseddirs"/> <compilerarg value="${wlp.install.dir}/dev/specs"/> </javac>
- Si vous utilisez Apache Maven pour la génération, compilez votre code avec l'élément
endorseddirs du plug-in de compilation Maven et les fichiers JAR qui se trouvent dans le répertoire ${wlp.install.dir}/dev/specs.
Exemple :
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.6</source> <target>1.6</target> <compilerArguments> <endorseddirs>${wlp.install.dir}/dev/specs</endorseddirs> </compilerArguments> </configuration> </plugin>

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.
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 le profil complet.
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.
![[8.5.5.6 ou ultérieure]](../ng_v8556.gif)
Restrictions liées à la prise en charge JCA générique et à l'adaptateur de ressources WebSphere MQ
L'adaptateur de ressources WebSphere® MQ peut être utilisé au sein du profil Liberty de WebSphere Application Server à l'aide de la fonction wasJmsClient-1.1 ou wasJmsClient-2.0 ou d'une prise en charge JCA générique.
Vous pouvez utiliser l'adaptateur de ressources WebSphere version 7.5 avec le profil 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 du profil Liberty qui est compatible avec l'adaptateur de ressources JMS 2.0.
- Dans le profil Liberty version 8.5.5.2, la fonction wasJmsClient-1.1 doit être utilisée avec l'adaptateur de ressources IBM MQ version 7.5.0.5 ou suivante.
- Dans le profil Liberty version 8.5.5.6, la fonction wasJmsClient-2.0 doit être utilisée avec l'adaptateur de ressources IBM MQ version 8.0.0.3 ou suivante.
Pour en savoir plus sur les informations de compatibilité de version entre l'adaptateur de ressources WebSphere MQ et le profil Liberty, voir Reference to obtain the WebSphere MQ resource adapter.
- Pour exécuter l'adaptateur de ressources IBM® WebSphere MQ sous z/OS, vous devez utiliser la fonction wasJmsClient-1.1orwasJmsClient-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.
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".
Restrictions concernant le centre d'administration
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.
![[8.5.5.6 ou ultérieure]](../ng_v8556.gif)
- 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.
Restrictions concernant le dispositif de cache dynamique
- 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 concernant le dispositif ejbLite-3.1
- Les modules EJB antérieurs à la version 3.0 ne sont pas pris en charge. Cette restriction signifie également que les liaisons et les extensions utilisant le format de fichier .xmi plutôt que le 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.
![[8.5.5.6 ou ultérieure]](../ng_v8556.gif)
Restrictions concernant la fonction eventLogging-1.0
- Si la fonction eventLogging-1.0 est retirée d'un serveur en cours d'exécution, cela entraîne le redémarrage des applications Web déployées.
![[8.5.5.6 ou ultérieure]](../ng_v8556.gif)
Restrictions concernant la fonction jpa-2.1
Pour la fonction jpa-2.1, l'échange d'entité JPA sur CORBA/RMI-IIOP exige que les deux participants de la communication activent des niveaux de fonction JPA identiques.
Restrictions concernant le dispositif 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.
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.
![[8.5.5.6 ou ultérieure]](../ng_v8556.gif)
Restrictions concernant la fonction requestTiming-1.0
- Si la fonction requestTiming-1.0 est retirée d'un serveur en cours d'exécution, cela entraîne le redémarrage des applications Web déployées.
- La fonction requestTiming-1.0, lorsqu'elle est activée, démontre un impact de 8% sur le rendement d'application possible maximum lorsqu'il est mesuré avec l'application DayTrader. Même si l'impact sur votre application peut être inférieur ou supérieur à cela, vous devez savoir qu'une dégradation des performances est possible.
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 WebSphere MQ. Vous devez définir cette variable de chemin lorsque l'application utilise le mode de connexion liaison.
- Les classes WebSphere MQ pour Java (généralement appelées Base Java) ne sont pas incluses dans la fonction wmqJmsClient-1.1. Elles sont incluses dans l'adaptateur de ressources pour d'autres serveurs d'applications mais ne sont pas recommandées pour les API Base Java dans les environnements Java Enterprise Edition. 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 WebSphere 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.
![[8.5.5.6 ou ultérieure]](../ng_v8556.gif)
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 WebSphere MQ. Vous devez définir cette variable de chemin lorsque l'application utilise le mode de connexion liaison.
- Les classes WebSphere MQ pour Java (généralement appelées Base Java) ne sont pas incluses dans la fonction wmqJmsClient-2.0. Elles sont incluses dans l'adaptateur de ressources pour d'autres serveurs d'applications mais ne sont pas recommandées pour les API Base Java dans les environnements Java Enterprise Edition. 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 WebSphere MQ n'est pas pris en charge pour la fonction wmqJmsClient-2.0.
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é.
![[8.5.5.6 ou ultérieure]](../ng_v8556.gif)
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.