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 Messages.
La documentation d'API Java™ de chaque API Liberty est détaillée dans la section Interfaces de programmation (Javadoc) du site en ligne IBM® Knowledge Center et est également disponible sous forme de fichier .zip séparé dans l'un des sous-répertoires javadoc du répertoire ${wlp.install.dir}/dev.

Pour 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.
- Les JDK
- Dépannage de la sécurité
- LDAP
- SSL
- Identification et résolution des problèmes relatifs aux communication CORBA/IIOP
- Traitement des incidents liés à la journalisation et à la trace
Application de groupes de correctifs et de correctifs provisoires à une installation d'archive
- Traitement des incidents de performances
- Traitement des incidents affectant les collectivités
- Traitement des incidents SAML
- Identification et résolution des incidents de l'API REST Discovery
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 :
La zone sslRef doit indiquer defaultSSLConfig.<ltkeyStore id="defaultKeyStore" location="key.jks" password="mypassword" />
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.
- Créez un fichier texte, par
exemple my.java.security, avec les deux
entrées vides suivantes
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.


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.
- Augmentez la valeur de l'attribut pollingRate dans l'élément applicationMonitor.
- 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" />
- 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 :
- 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"/>
Spécifiez le nom complet de l'ordinateur de votre système d'exploitation comme nom d'hôte complet.
- 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.