Astuces pour le traitement des incidents liés à Liberty

Cette section décrit les solutions relatives à des problèmes courants.

Pour vous aider à identifier et résoudre les problèmes, le produit comporte un composant de journalisation unifiée. Voir Journalisation et Trace.

Si vous recevez un message d'exception, vous trouverez des informations sur celui-ci dans la section Liberty: Messages.

La documentation d'API Java™ de chaque API Liberty est disponible dans un fichier .zip séparé des sous-répertoires javadoc du répertoire ${wlp.install.dir}/dev.

For distributed platformsDes détails concernant les principales restrictions connues qui s'appliquent lors de l'utilisation de Liberty sont fournis dans les deux rubriques suivantes :

For IBM i platformsPour plus d'informations sur les principales restrictions connues qui s'appliquent lors de l'utilisation de Liberty, voir Problèmes et restrictions connus concernant l'environnement d'exécution.

Vérifiez que vos JDK sont d'un niveau pris en charge

Si vous rencontrez des problèmes dont la cause vous échappe, vérifiez que les kits JDK que vous utilisez sont compatibles avec Java version 7 ou ultérieure, et que leur niveau de service est à jour. Voir Niveaux Java pris en charge.

Dépannage de la sécurité

Cette section décrit quelques problèmes de sécurité courants et les solutions que vous pouvez appliquer.

SESN0008E: Un utilisateur authentifié comme anonyme a tenté d'accéder à une session détenue par l'utilisateur : LdapRegistry/cn=steven,o=myCompany,c=US.
Cette erreur survient lorsqu'un utilisateur non authentifié tente d'accéder à une session créée par un utilisateur authentifié. La sécurité des sessions activée par défaut empêche tout accès non autorisé aux sessions. Seul l'utilisateur ayant créé une session peut accéder à celle-ci. Pour plus d'informations, voir session security.

Cette erreur peut survenir lorsqu'un JSP (par exemple login.jsp) est utilisé pour la connexion par formulaire et que le jeton SSO envoyé par le navigateur a expiré. Vu que le jeton SSO a expiré, l'utilisateur est invité à se connecter à nouveau en utilisant la page login.jsp configurée comme formulaire de connexion. Par défaut, cette page tente d'obtenir une session. Cette session a été initialement créée par l'utilisateur dont le jeton a expiré. Comme le jeton a expiré, l'utilisateur n'est pas authentifié, aucune donnée d'identification n'est vérifiée lorsque vous accédez à cette session, ce qui engendre cette erreur.

Pour éviter cette erreur, redémarrez le navigateur pour ouvrir une nouvelle session ou configurez le fichier login.jsp de sorte que, par défaut, il ne crée pas de session. Si vous choisissez de modifier le fichier login.jsp, spécifiez <%@ page session="false" %>.

CWWKS9104A: L'autorisation a échoué pour l'utilisateur {0} lors de l'appel de {1} sur {2}. Aucun des rôles requis n'est affecté à l'utilisateur : {3}.
Cette erreur se produit si l'utilisateur ne possède aucun des rôles requis par l'application. Assurez-vous que l'utilisateur ou le groupe dont il fait partie est mappé à au moins un des rôles mentionnés dans le message d'erreur. Un mappage entre utilisateur et rôle qui a été défini dans le fichier ibm-application-bnd.xmi/xml est prioritaire par rapport à un mappage défini dans le fichier server.xml. Vérifiez ces deux ressources et assurez-vous que le mappage correct est défini. Voir Configuration de l'autorisation pour les applications dans Liberty.
CWWKS9104A: L'autorisation a échoué pour l'utilisateur {0}.
Cette erreur peut se produire si vous spécifiez à la fois une valeur application et une valeur webApplication pour la même racine de contexte. Si un conflit se produit, la dernière configuration qui est définie est ignorée et elle génère une erreur inattendue, comme CWWKS9104A.
CWWKZ0013E: It is not possible to start two applications called {0} followed by unexpected security behavior and error messages such as CWWKS9104A.
Cette erreur survient si vous spécifiez votre application dans le fichier server.xml via l'élément application ainsi que dans le dossier dropins. Le système tente alors d'installer l'application deux fois et la configuration de sécurité définie dans le fichier server.xml peut ou non être appliquée. Pour corriger ce problème, vous devez supprimer votre application du dossier dropins et la copier dans un autre répertoire. Si vous devez la maintenir dans le dossier dropins, vous devez désactiver la surveillance des applications en ajoutant le code suivant dans votre fichier server.xml :
<applicationMonitor dropinsEnabled="false"/>
Un utilisateur non authentifié est parvenu à accéder à mon servlet ou JSP.
Un utilisateur avec le principal UNAUTHENTICATED (ou l'utilisateur SAF non authentifié sur z/OS) est créé lorsque l'authentification échoue ou lorsque votre servlet ou JSP n'est pas protégé. Un utilisateur non authentifié peut accéder à votre servlet ou JSP si vous ne définissez pas de contraintes de sécurité ou si vous mappez le sujet spécial EVERYONE au rôle requis par votre application. Vérifiez les mappages utilisateur-rôle dans les fichiers ibm-application-bnd.xmi/xml et server.xml. Choisissez l'une des options suivantes :
  • Si votre servlet ou JSP n'est pas protégé, ajoutez des contraintes de sécurité au descripteur de déploiement de l'application. Voir Authentification.
  • Si vous ne voulez pas qu'un utilisateur non authentifié puisse accéder à votre application, supprimez le mappage entre le sujet spécial EVERYONE et le rôle requis par l'application. Voir Configuration de l'autorisation pour les applications dans Liberty.
  • Si un utilisateur particulier ne peut pas être autorisé à accéder à votre servlet ou JSP, déterminez qui est mappé à ce rôle en examinant les fichiers ibm-application-bnd.xmi/xml et server.xml. Un rôle peut être mappé à un utilisateur, un groupe ou un sujet spécial. Si votre rôle est mappé au sujet spécial EVERYONE, tous les utilisateurs peuvent accéder à votre servlet ou JSP. S'il est mappé au sujet spécial ALL_AUTHENTICATED, tous les utilisateurs authentifiés peuvent accéder à votre servlet ou JSP. Supprimez ces mappages aux sujet spéciaux si vous voulez limiter davantage l'accès à votre servlet ou JSP. Enfin, pensez à vérifier à quel groupe appartient l'utilisateur. Car si l'utilisateur n'est pas mappé explicitement au rôle qui l'autorise à accéder à votre ressource, rien ne dit que son groupe ne l'est pas. Dans ce cas, vous pouvez retirer l'utilisateur du groupe autorisé ou dissocier le groupe du rôle en question afin de supprimer le mappage correspondant. Voir Configuration de l'autorisation pour les applications dans Liberty.
La connexion unique (SSO) ne fonctionne pas.
Si la connexion unique ne fonctionne pas, vérifiez que les différents serveurs Liberty qui utilisent les mêmes clés LTPA, le même mot de passe et le même attribut ssoCookieName de l'élément webAppSecurity appliquent le même temps universel et partagent le même registre d'utilisateurs. Par ailleurs, si le jeton SSO expire ou si le cookie est envoyé depuis un navigateur Web après une modification incohérente du registre d'utilisateurs (par exemple, un changement de domaine ou le retrait de l'utilisateur représenté par ce cookie), il est normal que la connexion unique échoue et que l'utilisateur doive à nouveau entrer ses données d'identification. Voir Customizing SSO configuration using LTPA cookies in Liberty.
Débogage des API publiques de sécurité
Les API WSSecurityHelper et RegistryHelper sont chargées même si la sécurité est désactivée, par exemple si aucune fonction de sécurité (comme appSecurity-1.0,appSecurity-2.0 ou zosSecurity-1.0) n'est spécifiée. Si la sécurité n'est pas activée, les méthodes WSSecurityHelper.isServerSecurityEnabled() et WSSecurityHelper.isGlobalSecurityEnabled() renvoient toutes les deux false, tandis que la méthode RegistryHelper.getUserRegistry() renvoie null.

Les autres classes des API publiques de sécurité ne sont normalement pas chargées si la sécurité n'est pas activée. Si vous tentez d'accéder à ces classes et appelez une méthode de l'une de ces classes, il se peut qu'une exception java.lang.NoClassDefFoundError soit émise.

Pour éviter l'exception java.lang.NoClassDefFoundError, vous devez d'abord tester si la sécurité est activée en appelant la méthode WSSecurityHelper.isServerSecurityEnabled() ou WSSecurityHelper.isGlobalSecurityEnabled(). Si cet appel renvoie true, vous savez que la sécurité est activée et vous pouvez alors solliciter les autres classes des API de sécurité. Pour des exemples de cette technique de codage, voir API publiques de sécurité dans Liberty.

Remarque : Ce comportement est différent de celui du WebSphere Application Server Traditional. Dans le WebSphere Application Server Traditional, toutes les classes sont toujours chargées, que la sécurité soit activée ou non.
Impossible d'authentifier les utilisateurs avec des caractères Unicode
Pour authentifier les utilisateurs dont les noms contiennent des caractères Unicode, vous devez définir le type de codage de caractères utilisé par le serveur Liberty sur UTF-8 en ajoutant l'option jvm suivante dans la commande de démarrage du serveur :
-Dclient.encoding.override=UTF-8
Vous devez aussi indiquer charset et pageEncoding dans votre page de connexion. Voici un exemple d'indication de ces paramètres dans une page JSP de connexion :
<%@page contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
java.lang.annotation.AnnotationFormatError: java.lang.IllegalArgumentException:Wrong type at constant pool index at sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:87)
Cette erreur peut se produire lorsqu'un fournisseur OpenID Connect ou OAuth utilise un magasin de base de données pour l'enregistrement client avec certaines versions JDK 7.

Pour éviter ce problème, effectuez une mise à niveau vers JDK version 7.1.

LDAP

Cette section décrit quelques problèmes LDAP courants et les solutions que vous pouvez appliquer.

FFDC1015I: Un incident FFDC a été créé : javax.naming.ServiceUnavailableException: myldapserver.mycompany.com:636; socket closed com.ibm.ws.security.registry.ldap.internal.LdapRegistry 298
Ce message consigné dans messages.log indique que le serveur LDAP configuré n'a pas pu être joint. Vérifiez que votre serveur LDAP est en opération et que son adresse IP est accessible depuis le serveur Liberty.
The javax.naming.CommunicationException: simple bind failed: myldapserver.mycompany.com:636 [Root exception is javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.g: PKIX path building failed: java.security.cert.CertPathBuilderException: unable to find valid certification path to requested target]
Si vous activez SSL sur votre serveur LDAP sans copier le signataire de ce serveur dans le fichier de clés certifiées référencé par l'élément LDAPSSLSettings, l'établissement de liaison SSL ne peut aboutir et la connexion au serveur LDAP échoue. Veillez à copier le signataire du serveur LDAP dans votre fichier de clés certifiées.
The javax.naming.CommunicationException: myldapserver.mycompany.com:389 [Root exception is java.net.BindException: Address already in use: connect]
Ce message peut apparaître dans les journaux de l'outil de diagnostic de premier niveau (FFDC) pour indiquer qu'il n'y a plus de socket utilisable sur le serveur local, ce qui conduit à un échec lors de la connexion à votre serveur LDAP. Vérifiez que le socket n'est pas utilisé et renouvelez l'opération.
CWWKS1100A: L'authentification n'a pas réussi pour l'ID utilisateur xxxxx. Un ID utilisateur ou un mot de passe non valide a été spécifié.
Cette exception de l'outil de diagnostic de premier niveau peut être émise sur le serveur même si l'utilisateur mentionné dans le message est valide sur le serveur LDAP qui connaît une charge élevée. Dans la configuration LDAP, vous pouvez ajouter la propriété reuseConnection=false ou la désactiver à l'aide des outils de développement. Pour corriger le problème, associez cette propriété à la valeur par défaut true.

SSL

Cette section décrit quelques problèmes SSL courants et les solutions que vous pouvez appliquer.

CWWKS9105E: Impossible de déterminer le port SSL pour la redirection automatique.
Cette erreur se produit si vous tentez d'accéder à une application qui vous redirige sur un port SSL et que celui-ci n'est pas disponible. Le port peut être indisponible en raison d'une configuration SSL manquante ou d'une erreur dans la définition de la configuration SSL existante. Vérifiez qu'il existe une configuration SSL dans le fichier server.xml et qu'elle est correcte. Voir Securing communications with Liberty.
FFDC1015I: Un incident FFDC a été créé : "java.lang.IllegalArgumentException: Unknown, incomplete configuration: missing id field com.ibm.ws.config.internal.cm.ManagedServiceFactoryTracker aSyncReadNupdate. Exception thrown while trying to read configuration and update ManagedServiceFactory. Exception = java.lang.IllegalArgumentException: Unknown, incomplete configuration: missing id field" at ffdc_12.04.18_16.09.42.0.log
Cette erreur survient lorsqu'un élément keystore existe dans la configuration sans zone d'ID. Si vous utilisez une configuration SSL minimale, spécifiez defaultKeyStore pour l'attribut ID.
Vous pouvez rencontrer une exception su vous utilisez un registre utilisateurs LDAP sur lequel SSL est activé (sslEnabled) et qu'une valeur sslRef n'a pas été spécifiée.
Par exemple, dans une configuration, sslEnabled est associé à la valeur true mais il n'existe pas de valeur sslRef, comme dans l'exemple suivant :
<ltldapRegistry id="ldap" realm="SampleLdapIDSRealm" 
host="ccwin12.austin.ibm.com" port="636" ignoreCase="true"
baseDN="o=ibm,c=us"
bindDN="cn=root"
bindPassword="rootpwd"
ldapType="IBM Tivoli Directory Server"
idsFilters="ibm_dir_server"
sslEnabled="true"
searchTimeout="8m" />
Vous devez entrer une valeur sslRef. Si vous utilisez une configuration SSL minimale similaire à la suivante :
<ltkeyStore id="defaultKeyStore" location="key.jks"
password="mypassword" />
La zone sslRef doit indiquer defaultSSLConfig.

Si une configuration SSL personnalisée est définie, le nom de cette configuration doit être placé dans la zone sslRef.

Si vous utilisez un JDK à partir de WebSphere Application Server, vous pouvez rencontrer l'erreur suivante si SSL est activé sur votre serveur Liberty.
java.net.SocketException: java.lang.ClassNotFoundException: Cannot find the specified class com.ibm.websphere.ssl.protocol.SSLSocketFactory 
      at javax.net.ssl.DefaultSSLSocketFactory.a(SSLSocketFactory.java:11) 
      at javax.net.ssl.DefaultSSLSocketFactory.createSocket(SSLSocketFactory.java:6) 
      at com.ibm.net.ssl.www2.protocol.https.c.afterConnect(c.java:161) 
      at com.ibm.net.ssl.www2.protocol.https.d.connect(d.java:36) 
      at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1184) 
      at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:390) 
      at com.ibm.net.ssl.www2.protocol.https.b.getResponseCode(b.java:75) 
      at com.ibm.ws.jmx.connector.client.rest.internal.RESTMBeanServerConnection.loadJMXServerInfo(RESTMBeanServerConnection.java:142) 
      at com.ibm.ws.jmx.connector.client.rest.internal.RESTMBeanServerConnection.<init>(RESTMBeanServerConnection.java:114) 
      at com.ibm.ws.jmx.connector.client.rest.internal.Connector.connect(Connector.java:315) 
      at com.ibm.ws.jmx.connector.client.rest.internal.Connector.connect(Connector.java:103) 
Cette erreur survient car les fabriques de sockets SSL WebSphere Application Server ne sont pas prises en charge par Liberty. Vous pouvez éviter ce problème en procédant comme suit :
  • Créez un fichier texte, par exemple my.java.security, avec les deux entrées vides suivantes
    ssl.SocketFactory.provider=
    ssl.ServerSocketFactory.provider=
  • Créez un fichier jvm.options pour votre serveur Liberty
  • Ajoutez la propriété suivante dans votre fichier jvm.options, incluant le chemin d'accès complet au fichier texte que vous venez de créer
    -Djava.security.properties=fullPathTo/my.java.security 
  • Si vous voulez rendre cette opération davantage réutilisable, vous pouvez placer le fichier my.java.security dans votre répertoire serveur, puis utiliser alors un chemin relatif tel que :
    -Djava.security.properties=./my.java.security 

Pour plus d'informations, voir Personnalisation de l'environnement Liberty.

Identification et résolution des problèmes relatifs aux communication CORBA/IIOP

Cette section décrit quelques problèmes CORBA courants et les solutions que vous pouvez mettre en oeuvre.

Si vous utilisez un kit JDK de WebSphere Application Server, vous pouvez voir l'erreur suivante si votre application utilise les communications CORBA/IIOP.
15:21:58.096 com.ibm.rmi.pi.InterceptorManager runPreInit:178 Init Process ORBRas [default]  java.lang.ClassNotFoundException:
com.ibm.ISecurityLocalObjectBaseL13Impl.CSIClientRI
        at com.ibm.CORBA.iiop.UtilDelegateImpl.loadClass(UtilDelegateImpl.java:685)
        at javax.rmi.CORBA.Util.loadClass(Util.java:246)
        at com.ibm.rmi.pi.InterceptorManager.runPreInit(InterceptorManager.java:172)
        at com.ibm.rmi.corba.ORB.initializeInterceptors(ORB.java:664)
        at com.ibm.CORBA.iiop.ORB.initializeInterceptors(ORB.java:1084)
        at com.ibm.rmi.corba.ORB.orbParameters(ORB.java:1359)
        at com.ibm.rmi.corba.ORB.set_parameters(ORB.java:1271)
        at com.ibm.CORBA.iiop.ORB.set_parameters(ORB.java:1694)
        at org.omg.CORBA.ORB.init(ORB.java:371) 
        ...

Cette erreur se produit car les intercepteurs ORB de WebSphere Application Server ne sont pas pris en charge par Liberty. Pour éviter ce problème, éditez le fichier orb.properties dans JDK afin de ne pas utiliser ces intercepteurs. Ce fichier réside dans le répertoire WebSphere <JAVA_HOME>/jre/lib, mais peut avoir été supplanté par une copie dans le répertoire <USER_HOME> de l'utilisateur. L'exemple suivant illustre les lignes du fichier orb.properties qui doivent être mises en commentaire :

# WS Interceptors
#org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.ws.Transaction.JTS.TxInterceptorInitializer
#org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.ejs.ras.RasContextSupport
#org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.ISecurityLocalObjectBaseL13Impl.ClientRIWrapper
#org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.ws.activity.remote.cos.ActivityServiceClientInterceptor
#org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.ISecurityLocalObjectBaseL13Impl.CSIClientRI 
#org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.debug.olt.ivbtrjrt.OLT_RI
#org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.ws.wlm.client.WLMClientInitializer

# WS ORB & Plugins properties
#com.ibm.ws.orb.transport.ConnectionInterceptorName=com.ibm.ISecurityLocalObjectBaseL13Impl.SecurityConnectionInterceptor

Traitement des incidents liés à la journalisation et à la trace

Cette section décrit certains problèmes courants liés à la journalisation et à la trace.

Interface de programmation de journalisation Java java.util.logging
Liberty ne prend pas en charge l'utilisation du fichier logging.properties pour configurer java.util.logging. Utilisez du code Java, par exemple dans une application déployée ou une fonction utilisateur, pour créer et ajouter des gestionnaires java.util.logging, des filtres ou des programmes de formatage.
Etant donné que le serveur Liberty gère les niveaux de consignateur java.util.logging conformément à l'attribut traceSpecification de l'élément de configuration de journalisation, évitez d'utiliser la méthode Logger.setLevel.

Traitement des incidents liés à JAX-WS

Cette section décrit certains problèmes courants liés à JAX-WS et les solutions que vous pouvez appliquer.

Une exception org.apache.cxf.bus.extension.ExtensionException est renvoyée lors du déploiement d'une application de services Web sur Liberty.
Si votre application comporte des bibliothèques et des configurations CXF déjà imbriquées et que vous désirez déployer l'application dans Liberty, assurez-vous que la fonction serveur jaxws-2.2 est désactivée en la supprimant du fichier server.xml.
Une exception java.lang.NoClassDefFoundError est renvoyée lors de l'exécution du raccourci IBM® de la machine virtuelle Java d'Oracle.
Pour utiliser le raccourci IBM JAXB (Java Architecture for XML Binding), vous pouvez configurer la propriété personnalisée com.ibm.xml.xlxp.jaxb.opti.level afin de contrôler l'activation des méthodes d'optimisation pour la déconversion de paramètres (désérialisation) et la conversion de paramètres (sérialisation) JAXB. Si vous rencontrez l'exception java.lang.NoClassDefFoundError lorsque vous utilisez le raccourci IBM de la machine virtuelle Java d'Oracle, vous pouvez modifier la propriété com.ibm.xml.xlxp.jaxb.opti.level en lui attribuant la valeur 0 afin de désactiver l'optimisation. Par exemple, vous pouvez utiliser la propriété -Dcom.ibm.xml.xlxp.jaxb.opti.level=0 dans la ligne de commande ou ajouter la ligne suivante dans le fichier jvm.options :
# Turn off the JAXB optimization
-Dcom.ibm.xml.xlxp.jaxb.opti.level=0
Pour plus d'informations sur la propriété com.ibm.xml.xlxp.jaxb.opti.level, reportez-vous à la page Propriétés personnalisées de la machine virtuelle Java.
Une exception java.lang.NoClassDefFoundError : com.ibm.CORBA.iiop.ORB est renvoyée lors de l'exécution du client léger de WebSphere Application Server Traditional avec la machine virtuelle Java d'Oracle.
Cette erreur se produit lorsque vous tentez d'exécuter le client léger WebSphere Application Server Traditional avec la machine virtuelle Java Oracle et lorsque la fonction jaxws-2.2 est déjà activée sur Liberty. Pour résoudre ce problème, vous pouvez utiliser la propriété -Dcom.ibm.websphere.thinclient=true lorsque vous exécutez le client léger WebSphere Application Server Traditional comme suit :
java -Dcom.ibm.websphere.thinclient=true 
     -cp <classpath_entries_including_tWAS_thinclient_jar> <WebServicesClientEntryClass> <any_more_parameters>
Voir les informations similaires sur la propriété com.ibm.websphere.thinclient dans la page PM39777: ADMINISTRATIVE THIN CLIENT USING SOAP CONNECTOR AND SUN JDK DOES NOT WORK.
Un fichier vide est renvoyé lors de l'extraction des fichiers binaires depuis un service MTOM vers un client MTOM.
Ce scénario se produit lorsqu'un client MTOM a envoyé des fichiers binaires à un service MTOM mais qu'un fichier vide est renvoyé lors de l'extraction de ces mêmes fichiers binaires depuis le service MTOM.
Pour contourner le problème, vous pouvez créer un gestionnaire de données (DataHandler) et l'initialiser en remplissant le contenu du fichier binaire. Par exemple, utilisez un objet FileDataStore afin de lire les entrées-sorties et renvoyer le nouveau gestionnaire de données (DataHandler), puis transmettre ce dernier à d'autres services Web.
...
File f = new File("received_image");
	if (f.exists()) {
		f.delete();
	}

	FileOutputStream fos = new FileOutputStream(f);
	img_in.writeTo(fos);

	FileDataSource fos_out = new FileDataSource(f);
	DataHandler img_out = new DataHandler(fos_out);
	return img_out;
...
Une erreur javax.xml.ws.soap.SOAPFaultException: Unmarshalling est renvoyée lorsque vous utilisez XMLGregorianCalendar et le format xsd:gMonth avec la machine virtuelle Java d'Oracle.
Cette erreur survient lorsque vous utilisez la classe XMLGregorianCalendar pour stocker des constantes au format gMonth dans le cadre de votre demande SOAP côté client et que la fonction jaxws-2.2 est activée dans Liberty avec la machine virtuelle Java d'Oracle. La cause première est que la machine virtuelle Java d'Oracle prend en charge le nouveau format standard --MM pour le type xsd:gMonth alors que l'implémentation de référence la plus récente, JAXB RI, prend seulement en charge le format --MM--.
Pour résoudre ce problème, vous pouvez remplacer la machine virtuelle Java d'Oracle par la machine virtuelle Java d'IBM dans les applications côté client et côté serveur.
Une exception java.io.FileNotFoundException est renvoyée lors de la résolution des fichiers WSDL spécifiés par l'attribut wsdlLocation.
Cette erreur survient lorsque vous spécifiez le fichier WSDL comme dans le code wsdlLocation = "file:/WEB-INF/wsdl/a.wsdl" et que le fichier WSDL est conditionné dans votre application. Pour vous référer au fichier WSDL de votre package d'application, vous devez utiliser des URI relatifs pour l'attribut wsdlLocation défini dans l'annotation @WebService, @WebServiceProvider, @WebServiceClient, ou @WebServieRef.
L'URI relatif pour l'attribut wsdlLocation doit être l'un des suivants :
  • wsdlLocation = "/WEB-INF/wsdl/a.wsdl"
  • wsdlLocation = "WEB-INF/wsdl/a.wsdl"
De nombreux messages "Creating service" (Création d'un service) figurent dans le fichier messages.log.
Ce scénario survient lorsque vous appelez la méthode getPort ou des méthodes connexes dans les classes de module de remplacement client générées. Liberty est configuré avec la configuration de journalisation par défaut et tous les messages d'information sont écrits dans le fichier messages.log. De nombreux messages similaires au suivant sont enregistrés :
00000037 org.apache.cxf.service.factory.ReflectionServiceFactoryBean I Creating Service {http://www.echo.org/}EchoService from WSDL: 
    wsjar:file:/wlp/usr/servers/default/workarea/org.eclipse.osgi/bundles/100/data/cache/
    com.ibm.ws.app.manager_gen_15a42559-f979-4ee6-b488-9fa1fb212c96/.cache/Echo.war!/WEB-INF/wsdl/Echo.wsdl
Pour supprimer ces messages d'information, vous pouvez modifier la configuration de journalisation dans le fichier server.xml comme ceci :
<logging traceSpecification="org.apache.cxf.*=warning=enabled"/>
Exception SOAPFaultException : l'élément SOAPAction test indiqué ne correspond pas à une opération qui a été exécutée lorsqu'une application client a envoyé une action SOAP.
Remarque : test est la valeur de l'attribut soapAction dans l'en-tête HTTP de la demande.
Chaque opération dans un service SOAP peut être associée à une chaîne d'action SOAP, comme dans une liaison WSDL ou via une annotation. Le client de service Web envoie la chaîne d'action SOAP sous forme d'en-tête dans la demande pour mettre en correspondance l'opération du fournisseur de services Web. Le message d'erreur s'affiche dans les cas suivants :
  • Lorsque l'action SOAP envoyée par le client ne correspond pas à l'action SOAP de l'opération.
  • Lorsque vous utilisez WebSphere Application Server Traditional comme client JAX-WS et Liberty comme service JAX-WS et que l'élément soapAction défini dans le fichier WSDL est égal à un valeur vide"".
Pour résoudre cet incident :
  • Assurez-vous d'avoir spécifié la même action SOAP pour le client de service Web et le fournisseur de services.
  • Indiquez une valeur valide pour l'attribut soapAction qui est défini dans le fichier WSDL ou n'utilisez pas soapAction dans le fichier WSDL.
Un exception javax.xml.ws.WebServiceException est renvoyée lorsque vous utilisez la méthode Service.create() pour créer un service.
Cette erreur survient lorsque vous utilisez la méthode Service.create() pour créer un service alors que le document WSDL n'est pas fourni. Si vous voulez utiliser la méthode Service.create() pour créer un service et la méthode getPort() pour obtenir le numéro de port, vous devez utiliser la méthode addPort() afin de fournir les informations de liaison.
L'exemple de code suivant est mis à disposition et illustre l'utilisation de la méthode addPort() :
QName serviceName = new QName("http://test.com/wssvt/acme/InsBusiness/", "MTOM11Service");
QName portName = new QName("http://test.com/wssvt/acme/InsBusiness/", "MTOM11Port");

// Setup the necessary JAX-WS artifacts
Service svc = Service.create(serviceName);
// Add the port in the service instance
svc.addPort(portName, SOAPBinding.SOAP11HTTP_MTOM_BINDING, mtom11URL); 

port = svc.getPort(portName, MTOMInterface.class);
La réponse Null est renvoyée lorsque l'attribut name figurant dans l'annotation @WebResult est différent de l'élément name figurant dans le document WSDL.
Ce problème survient lorsque vous utilisez une classe d'interface d'activation de sécurité (SEI) pour définir l'attribut name de l'annotation @WebResult et que la classe SEI est associée à un emplacement WSDL comme suit :
@WebService(wsdlLocation="WEB-INF/wsdl/WebServiceIfc.wsdl")
public interface WebServiceRuntimeIfc {
        @WebMethod
        @WebResult(name="nononoreturn") 
        public String echo (String parm);
}
alors que la déclaration d'élément XML figurant dans le document WSDL fourni est :
<xs:element name="echoResponse">
	<xs:complexType>
		<xs:sequence>
			<xs:element name="return" type="xs:string" minOccurs="0"/>
		</xs:sequence>
	</xs:complexType>
</xs:element>
Dans ce cas, le client de service Web reçoit une réponse NULL lorsque la méthode echo() est appelée.
Pour résoudre ce problème, assurez-vous que l'attribut name de l'annotation @WebResult correspond à la valeur de l'élément name dans le document WSDL.
L'application client JAX-WS n'est pas parvenue à obtenir les modifications du document WSDL effectuées côté serveur.
Le problème survient lorsque le client de service Web et le fournisseur de services se trouvent dans deux applications différentes dans Liberty et que le client doit extraire le document WSDL depuis le fournisseur de services dynamiquement. En effet, Liberty met en cache la définition WSDL lors du premier accès au document WSDL, ce qui n'est pas le comportement dans WebSphere Application Server Traditional. En mettant en cache la définition WSDL dans Liberty, les applications peuvent éviter d'établir une connexion au document WSDL et de l'analyser fréquemment.
Pour résoudre ce problème, vous devez redémarrer l'application client de manière à recharger les définitions WSDL mises à jour.
Avertissement JAXB lors de l'importation du WSDL
Le message d'avertissement suivant peut être émis lors de l'importation d'un fichier WSDL.
[WARNING] unknown extensibility element or attribute "wsdl" (in namespace "http://www.w3.org/2000/xmlns/" (http://www.w3.org/2000/xmlns/%27) )

Traitement des incidents liés à la sécurité de services Web

Cette section décrit certaines solutions courantes que vous pouvez appliquer pour résoudre les problèmes liés à la sécurité de services Web.
  1. Vérifiez le fichier server.xml pour vous assurer que les fonctions JAX-WS (jaxws-2.2) et de sécurité (appSecurity-2.0) requis sont configurées correctement.
  2. Pour que votre application de service Web soit protégée avec la sécurité de services Web, votre application JAX-WS doit contenir un fichier WSDL dans lequel est imbriquée une règle de sécurité de services Web. Un élément PolicyReference lié à la règle de sécurité de services Web imbriquée doit figurer dans la section wsdl:binding ou wsdl:operation, ou les deux.
  3. Si vous utilisez un gestionnaire d'appel pour l'extraction de mots de passe afin de générer des jetons de nom d'utilisateur ou pour l'extraction des mots de passe de clés privées de fichiers de clés, le gestionnaire d'appel de mot de passe doit être conditionné et déployé en tant que fonction utilisateur dans Liberty.

Activation de la trace de sécurité de services Web

Si l'origine du problème ne peut pas être identifiée à l'aide des informations figurant dans le message d'erreur, vous pouvez utiliser les fonctions de journalisation et de trace de Liberty afin de collecter une trace pour le composant WS-Security (Sécurité de services Web). Voir Liberty: Trace and logging.

Vous pouvez utiliser la chaîne de trace suivante pour collecter une trace en vue de déboguer les échecs liés à la sécurité de services Web :
org.apache.ws.security.*=all=enabled:
org.apache.cxf.ws.security.*=all=enabled:
org.apache.cxf.ws.policy.*=all=enabled
org.apache.xml.security.*=all=enabled:
com.ibm.ws.wssecurity.*=all=enabled

Cette section décrit certains problèmes courants liés à la sécurité de services Web et les solutions que vous pouvez appliquer.

org.apache.cxf.ws.policy.PolicyException : Aucune des alternative de règle n'a pu être respectée.
En général, cette erreur survient lorsque la fonction de sécurité de services Web wsSecurity-1.1 n'est pas définie dans le fichier server.xml. Pour l'éviter, vous devez définir la fonction wsSecurity-1.1 dans le fichier server.xml comme suit :
<featureManager>
  <feature>usr:wsseccbh-1.0</feature>
  <feature>servlet-3.0</feature>
  <feature>appSecurity-2.0</feature>
  <feature>jaxws-2.2</feature>
  <feature>wsSecurity-1.1</feature>
</featureManager>
org.apache.cxf.ws.policy.PolicyException : Aucune gestionnaire d'appel et aucun mot de passe disponible.
Cette erreur survient lorsque l'environnement d'exécution de la sécurité de services Web ne peut pas extraire un mot de passe qui est requis pour la génération d'un jeton de nom d'utilisateur ou pour accéder à une clé privée qui se trouve dans le fichier de clés. Pour l'éviter, vérifiez la configuration suivante :
  1. Vérifiez que la fonction de gestionnaire d'appel de mot de passe wsseccbh-1.0 est définie en tant que fonction utilisateur dans le fichier server.xml :
    <featureManager>
      <feature>usr:wsseccbh-1.0</feature>
      <feature>servlet-3.0</feature>
      <feature>appSecurity-2.0</feature>
      <feature>jaxws-2.2</feature>
      <feature>wsSecurity-1.1</feature>
    </featureManager>
  2. Vérifiez que la propriété de gestionnaire d'appel ws-security.callback-handler est définie dans l'élément <wsSecurityClient> ou <wsSecurityProvider> du fichier server.xml :
    ws-security.callback-handler="<full class name of the callback handler>"
    
    example:
    ws-security.callback-handler="com.ibm.ws.wssecurity.example.cbh.CommonPasswordCallback"
  3. Vérifiez que le gestionnaire d'appel de mot de passe renvoie le mot de passe correct pour le nom d'utilisateur ou l'alias de clé spécifié dans le fichier server.xml. Le mot de passe doit être en texte en clair ; il ne doit pas être codé ni chiffré.
org.apache.ws.security.WSSecurityException : La signature ne couvre pas les éléments requis (soap:Body).
Cette erreur survient lorsqu'une application de fournisseur de services Web s'attend à ce que le corps SOAP figurant dans le message de demande soit signé alors que le corps SOAP figurant dans le message reçu n'est pas signé. Pour éviter cette erreur, assurez-vous que votre client de service Web est configuré avec la règle de sécurité de services Web correcte correspondant à celle du fournisseur de services Web.
org.apache.ws.security.WSSecurityException : La signature ou le déchiffrement n'est pas valide.
Cette erreur survient lorsque l'environnement de sécurité de services Web ne parvient pas à valider la signature ou à déchiffrer une partie de message chiffrée dans le message SOAP reçu. Pour éviter cette erreur, vérifiez que les clés correctes sont utilisées lorsque vous configurer la sécurité de services Web dans les éléments <wsSecurityClient> et <wsSecurityProvider> du fichier server.xml. Si un client de service Web utilise la clé publique de Bob pour chiffrer une partie de message, le fournisseur de services Web doit avoir accès à la clé privée de Bob pour déchiffrer le message. De même, si un client de service Web signe une partie de message en utilisant la clé privée d'Alice, le fournisseur de services Web doit utiliser la clé publique d'Alice pour valider la signature.
org.apache.cxf.ws.policy.PolicyException : Impossible de répondre à ces alternatives de règle.
Cette erreur survient lorsque l'environnement d'exécution de la sécurité de services Web ne parvient pas à traiter le message SOAP entrant à l'aide de la règle de sécurité de services Web qui est configurée pour le traitement de cette demande. Pour éviter cette erreur, consultez les messages qui suivent cette exception afin de déterminer les assertions de règle de sécurité de services Web spécifiques à l'origine de l'exception. Par exemple, le fichier journal peut contenir les messages suivants :
Caused by: org.apache.cxf.ws.policy.PolicyException: These policy alternatives can not be satisfied: 
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}AsymmetricBinding: The encryption algorithm does not match the requirement
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}InitiatorEncryptionToken
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}RecipientEncryptionToken
at org.apache.cxf.ws.policy.AssertionInfoMap.checkEffectivePolicy(AssertionInfoMap.java:167)
at org.apache.cxf.ws.policy.PolicyVerificationInInterceptor.handle(PolicyVerificationInInterceptor.java:101)
Dans ce cas, l'erreur survient car l'algorithme de chiffrement qui est utilisé par le client de service Web ne correspond pas à l'algorithme de chiffrement qui est spécifié par l'assertion AlgorithmSuite. Les suites d'algorithme qui sont spécifiées dans la règle de sécurité de services Web du client de service Web et du fournisseur de services Web doivent spécifier le même algorithme de chiffrement.
javax.xml.ws.soap.SOAPFaultException: Le message a expiré (WSSecurityEngine: Horodatage non valide. Les sémantiques de sécurité du message ont expiré).
Ce message s'affiche lorsque l'horodatage du message est arrivé à expiration ou lorsque le message a été créé avec un horodatage qui se situe dans le futur.
For distributed platformsFor IBM i platforms

Application de groupes de correctifs et de correctifs provisoires à une installation d'archive

Si vous avez installé l'environnement d'exécution de Liberty depuis un fichier archive plutôt qu'en utilisant Installation Manager, vous devez prendre des mesures spéciales lorsque vous appliquez des mises à jour de service. Pour plus d'informations, voir Application d'un groupe de correctifs à une installation d'archive Java Liberty et Application d'un correctif temporaire à une installation d'archive Liberty.

Traitement des incidents de performances

Cette section décrit certains problèmes courants liés aux performances ainsi que leurs solutions.

Utilisation de l'unité centrale élevée de la part du moniteur d'application

Cette erreur peut survenir si votre moniteur d'application possède de nombreux fichiers dans le répertoire apps/ qu'il interroge trop fréquemment.

Pour éviter ce problème, vous pouvez changer plusieurs choses.

  1. Augmentez la valeur de l'attribut pollingRate dans l'élément applicationMonitor.
  2. Mettez à jour le fichier server.xml pour inclure un élément applicationMonitor avec un élément updateTrigger qui n'est pas associé à la valeur polled.
    server.xml                                                                      
    <applicationMonitor updateTrigger="mbean" /> 
  3. Réduisez le nombre de fichiers dans le répertoire apps/.

Pour plus d'informations sur l'élément applicationMonitor, voir Contrôle des mises à jour dynamiques.

Traitement des incidents affectant les collectivités

Cette section décrit un problème affectant les collectivités et la solution que vous devez appliquer.

java.lang.IllegalArgumentException: CWWKX0219E : Le bean géré 'WebSphere:feature=collectiveController,type=CollectiveRepository,name=CollectiveRepository' n'a pas d'opération nommée 'retrieveMemberRootCertificate'
Un serveur avec fonction collectiveMember-1.0 (membre) ne peut pas s'enregistrer auprès d'un serveur avec fonction collectiveController-1.0 (contrôleur) à un niveau inférieur de Liberty. Par exemple, un membre à cette version bêta de Liberty ne peut pas s'enregistrer auprès d'un contrôleur de la version 8.5.5.2 de Liberty.

Avec la consignation par défaut, ce problème est signalé comme un événement FDCC (First Failure Data Capture) dans les journaux FFDC du membre.

Pour corriger ce problème, vous devez faire passer le contrôleur au même niveau Liberty que le membre (ou à un niveau supérieur).

Traitement des incidents SAML

Cette section décrit un problème affectant SAML et la solution que vous devez appliquer.

java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 0
Cette exception peut se produire lors de plusieurs tentatives de connexion via une demande initiée par un prestataire de services non sollicité sans suppression du jeton du fournisseur d'identité.
Pour éviter cela, ajoutez <httpSession invalidateOnUnauthorizedSessionRequestException="true" /> dans le fichier server.xml non sollicité.
java.lang.IllegalStateException: CWWKS0010E: Lors de l'obtention du principal appelant, plus d'un principal de type WSPrincipal a été trouvé pour le sujet appelant. Un seul élément WSPrincipal peut exister dans le sujet. Les noms des principaux WSPrincipals sont les suivants : {0}.
Cette exception peut se produire si un utilisateur SAML s'est préalablement connecté directement dans un registre d'utilisateur local. Pour éviter ce problème, aucun utilisateur SAML ne doit se connecter directement à un registre d'utilisateur local.

Traitement des incidents de détection des API REST

Si la sélection de "Try it out" de l'infrastructure de détection des API REST IBM est appelée à distance et échoue avec un code de réponse 0, vérifiez que le nom d'hôte complet ou l'adresse IP complète sont renvoyés à cette infrastructure dans l'URL cURL et l'URL de demande associées à l'opération GET, PUT, POST ou DELETE. Si le nom d'hôte complet ou l'adresse IP complète n'est pas contenue dans la cURL et l'URL de demande, effectuez les actions suivantes :

  1. Ajoutez l'élément de variable dans server.xml et spécifiez le nom d'hôte complet. L'exemple ci-dessous illustre l'ajout d'un élément de variable spécifiant le nom d'hôte complet dans le fichier server.xml :
     <httpEndpoint host="*" httpPort="9080" httpsPort="9443" id="defaultHttpEndpoint"/>          
    <variable name="defaultHostName" value="developer.rtp.raleigh.ibm.com"/>
  2. For distributed platforms Spécifiez le nom complet de l'ordinateur de votre système d'exploitation comme nom d'hôte complet.
  3. Vérifiez que le nom d'hôte complet ou l'adresse IP complète sont renvoyés dans l'URL Curl et l'URL de demande associées aux opérations GET, PUT, POST, ou DELETE dans l'explorateur de détection des API REST IBM. Pour plus d'informations, voir Définition du nom d'hôte par défaut d'un serveur Liberty et consultez la section portant sur la configuration de votre réseau dans la documentation produit d'IBM InfoSphere Information Server, Version 11.3.1.

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

Nom du fichier : rwlp_trouble.html