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 :

Niveaux Java pris en charge

Le profil Liberty est pris en charge par tout environnement d'exécution Java™ SE 60 ou Java SE 7 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.
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.
[8.5.5.5 ou ultérieure]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 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.

Pour plateformes IBM iRemarque : Pour obtenir le niveau Java pris en charge minimal pour IBM iSeries, installez la machine virtuelle Java IBM J2SE 6.0 32 bits (5761-JV1 option 11 [8.5.5.2 ou ultérieure] ou 5770-JV1 option 11) ou IBM SE 6.0 64 bits (5761-JV1 option 12 [8.5.5.2 ou ultérieure] ou 5770-JV1 option 12), ainsi que le groupe de PTF Java SF99562 niveau 19 (ou ultérieur) pour IBM i 6.1 ou SF99572 niveau 8 (ou ultérieur) pour IBM i 7.1.

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

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

Remplacement de classes depuis le SDK Java

Certaines technologies Java EE 6 prises en charge par le profil Liberty requièrent des versions plus récentes des API mises à disposition par Java SE 6. JAX-WS, JAXB et l'annotation javax.annotation.Resource sont des exemples pour lesquels un SDK Java 6 contient des classes plus anciennes que celles requises par Java EE 6. Lorsque vous compilez votre code d'application avec ces API à l'aide du SDK Java SDK version 6, vous devez utiliser les classes fournies par le profil Liberty plutôt que celles fournies par le SDK Java. Vous devez effectuer l'une des opérations suivantes :
  • 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>
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.

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

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.

Remarques :
  • 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.

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

Pour la fonction adminCenter-1.0, la restriction suivante s'applique :
  • [8.5.5.2 ou ultérieure]L'utilisation d'une machine virtuelle IBM Java disponible avec un produit profil complet de WebSphere Application Server, comme Network Deployment, peut empêcher l'affichage du centre d'administration WebSphere Liberty ("Centre d'administration") dans un navigateur. Par défaut, la machine virtuelle Java IBM disponible avec le profil complet pointe vers des classes de sécurité qui ne sont disponibles qu'avec un profil complet, et non vers les classes de sécurité requises par le Centre d'administration, qui requiert Secure Sockets Layer (SSL). Utilisez une machine virtuelle Java qui prend en charge le profil Liberty et SSL.
    [8.5.5.4 ou ultérieure]Vous pouvez obtenir une machine virtuelle Java qui prend en charge le profil Liberty et SSL depuis les offres Installation Manager ou developerWorks :
    • A l'aide d'Installation Manager, sélectionnez d'abord le produit de profil Liberty puis sélectionnez WebSphere SDK for Liberty. Utilisez Installation Manager pour installer le produit de profil Liberty et le kit de développement logiciel SDK. WebSphere SDK for Liberty inclut la prise en charge nécessaire pour les produits de profil Liberty et SSL et il propose un client java, JConsole.
    • Connectez-vous à l'adresse http://www.ibm.com/developerworks/java/jdk/index.html sur le site Web de developerWorks et téléchargez un kit Java Development Kit IBM (JDK) pour votre système d'exploitation. Le site Web de developerWorks n'a pas de machine virtuelle Java pour tous les systèmes d'exploitation. Par exemple, vous devez obtenir le kit JDK depuis Eclipse pour les systèmes d'exploitation windows.
  • [8.5.5.4 ou ultérieure]Les packages serveur ne peuvent pas être déployés sur un contrôleur si le serveur a déjà rejoint un contrôleur.

    Lors du déploiement d'un package serveur sur un contrôleur, n'utilisez qu'un serveur qui n'a pas rejoint de contrôleur.

    Vous pouvez aussi, si le serveur a rejoint un contrôleur, déplacer le répertoire $WLP_INSTALL_DIR/usr/servers/server_name/resources/collective (avec ses sous-répertoires) vers un répertoire temporaire tel que /tmp avant d'exécuter la commande serveur package. Ensuite, une fois le package serveur créé, redéplacez le répertoire resources/collective (avec ses sous-répertoires) dans $WLP_INSTALL_DIR/usr/servers/server_name depuis le répertoire temporaire.

  • [8.5.5.4 ou ultérieure]Depuis l'outil de déploiement du Centre d'administration, vous ne pouvez pas utiliser l'option Utiliser la méthode et les identifiants de connexion configurés pour chaque hôte cible de Données d'identification pour la gestion à distance pour déployer un profil Liberty version 8.5.5.3 ou un package serveur de version précédente sur un hôte enregistré. Le package serveur doit prendre en charge le le profil Liberty version 8.5.5.4 ou suivante.
  • [8.5.5.6 ou ultérieure]Les étiquettes s'affichent dans l'outil Explorer du Centre d'administration uniquement pour les ressources de serveur, de cluster et d'application. Les étiquettes relatives aux ressources d'exécution ne s'affichent pas. Pour plus d'informations sur les étiquettes, voir Définition de métadonnées d'administration pour les ressources Liberty et Définition et affichage des métadonnées d'administration dans le Centre d'administration.
  • [8.5.5.5 ou ultérieure]Le graphique Utilisation de l'unité centrale de la vue Surveillance du Centre d'administration affiche une utilisation UC de 0% ou null% pour les machines virtuelles qui ne fournissent pas de statistiques sur UC de traitement. Pour plus d'informations sur le graphique, voir Surveillance des métriques dans le Centre d'administration.

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.
[8.5.5.6 ou ultérieure]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.

Restrictions concernant le dispositif 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 concernant le dispositif ejbLite-3.1

Les restrictions suivantes s'appliquent à la fonction 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]

Restrictions concernant la fonction eventLogging-1.0

Les restrictions suivantes s'appliquent à 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]

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

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.

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.
[8.5.5.6 ou ultérieure]

Restrictions concernant la fonction requestTiming-1.0

Les restrictions suivantes s'appliquent à 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

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

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

[8.5.5.4 ou ultérieure]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]

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

Dispositions pour les centres de documentation | Commentaires


Icône d'horodatage Dernière mise à jour: Wednesday, 2 September 2015
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-libcore-mp&topic=rwlp_restrict
Nom du fichier : rwlp_restrict.html