Sugerencias de resolución de problemas para Liberty

La información de resolución de problemas describe soluciones para problemas comunes.

Para ayudarle a identificar y resolver problemas, el producto tiene un componente de registro unificado. Consulte Registro y rastreo.

Si recibe un mensaje de excepción, la información sobre el mensaje está disponible en Liberty:Mensajes.

La documentación de la API Java™ para cada API de Liberty está disponible en un archivo .zip separado en uno de los subdirectorios javadoc del directorio ${wlp.install.dir}/dev.

For distributed platformsLos detalles de las principales restricciones conocidas que se aplican al utilizar Liberty se proporcionan en los dos temas siguientes:

For IBM i platformsPara obtener detalles de las principales restricciones conocidas que se aplican cuando utiliza Liberty, consulte Problemas conocidos y restricciones de entorno de ejecución.

Compruebe que los JDK tienen un nivel soportado

Si experimenta problemas que no están explicados fácilmente, compruebe que los JDK que está utilizando son compatibles con Java Versión 7 o posterior, y que están en un nivel de servicio actual. Consulte Niveles mínimos de Java soportados.

Resolución de problemas de seguridad

En este apartado se describen algunos de los problemas comunes y las soluciones que puede elegir.

SESN0008E: Un usuario autenticado como anónimo ha intentado acceder a una sesión propiedad del usuario: LdapRegistry/cn=steven,o=myCompany,c=US.
Este error se produce cuando un usuario no autenticado intenta acceder a una sesión creada por un usuario autenticado. La seguridad de sesiones que está habilitada de forma predeterminada impide el acceso no autorizado a las sesiones. Sólo el usuario que ha creado una sesión puede acceder a ella. Para obtener más información, consulte seguridad de sesión.

Este error se puede producir cuando se utiliza un JSP (login.jsp, por ejemplo) para el formulario de inicio de sesión y la señal SSO enviada por el navegador ha caducado. Dado que el símbolo SSO ha caducado, se le solicita al usuario que inicie la sesión de nuevo utilizando la página login.jsp configurada para el formulario de inicio de sesión. De forma predeterminada, la página jsp intenta obtener una sesión. Esta sesión la ha creado originalmente el usuario cuya señal ha caducado. Puesto que la señal ha caducado y el usuario no está autenticado, no se establecen credenciales al acceder a esta sesión, lo que genera este error.

Para evitar este error, reinicie el navegador que inicia una nueva sesión, o configure el archivo login.jsp para que no cree la sesión de forma predeterminada. Si elige actualizar el archivo login.jsp, establezca <%@ page session="false" %>.

CWWKS9104A: Ha fallado la autorización del usuario {0} al invocar {1} en {2}. No se ha otorgado al usuario acceso para ninguno de los roles necesarios : {3}.
Este error se produce cuando no tiene autorización para los roles necesarios para la aplicación. Asegúrese de que el usuario o el grupo al que pertenece esté correlacionado con al menos uno de los roles mencionados en el mensaje de error. Una correlación de usuario a rol definida en el archivo ibm-application-bnd.xmi/xml tiene prioridad sobre una correlación definida en el archivo server.xml. Compruebe los recursos para garantizar que se ha definido la correlación correcta. Consulte Configuración de la autorización para aplicaciones en Liberty.
CWWKS9104A: Ha fallado la autorización del usuario {0}.
Este error puede producirse si especifica application y webApplication para la misma raíz de contexto. Si se produce un conflicto, la última configuración definida se ignorará y causará un error inesperado, como por ejemplo CWWKS9104A.
CWWKZ0013E: No se pueden iniciar dos aplicaciones denominadas {0} seguido de un comportamiento de seguridad inesperado y mensajes de error como CWWKS9104A.
Este error se produce cuando especifica la aplicación en server.xml utilizando el elemento application y en la carpeta dropins. Como resultado, se intenta instalar la aplicación dos veces y la configuración de seguridad en el archivo server.xml puede que entre en vigor o no. Para solucionar este problema debe eliminar la aplicación de la carpeta dropins y copiarla en otro directorio. Si debe dejarla en la carpeta dropins, debe inhabilitar la supervisión de aplicaciones utilizando el código siguiente en el archivo server.xml:
<applicationMonitor dropinsEnabled="false"/>
Un usuario no autenticado ha podido acceder a mi servlet o JSP.
Un usuario con un principal de UNAUTHENTICATED (o el usuario no autenticado SAF en z/OS) se crea cuando falla la autenticación o cuando el servlet o JSP no está protegida. Un usuario no autenticado puede acceder a su servlet o JSP si no define las restricciones de seguridad o si se correlaciona el sujeto especial EVERYONE con el rol necesario para la aplicación. Revise las correlaciones de usuario a rol en los archivos ibm-application-bnd.xmi/xml y server.xml. Ejecute una de las siguientes opciones:
  • Si el servlet o JSP no está protegido, añada restricciones de seguridad al descriptor de despliegue de la aplicación. Consulte Autenticación.
  • Si no desea que cualquier usuario no autenticado acceda a la aplicación, elimine el sujeto especial EVERYONE de la correlación para dicho rol. Consulte Configuración de la autorización para aplicaciones en Liberty.
  • Si un determinado usuario no puede estar autorizado para el servlet o JSP, revise si está correlacionado con ese rol analizando los archivos ibm-application-bnd.xmi/xml y server.xml. Puede correlacionar un rol con un usuario, grupo o sujeto especial. Si el rol está correlacionado con el sujeto especial EVERYONE, se otorga acceso a cualquier usuario. Si el rol está correlacionado con el sujeto especial ALL_AUTHENTICATED, se otorga acceso a cualquier usuario autenticado. Elimine estos sujetos especiales si desea limitar adicionalmente quién puede acceder a su servlet o JSP. Finalmente, compruebe a qué grupo pertenece el usuario. Aunque el usuario puede no tener acceso explícito, el grupo puede estar correlacionado con el rol. En este caso, elimine el usuario del grupo autorizado o elimine el grupo de la correlación de roles. Consulte Configuración de la autorización para aplicaciones en Liberty.
El inicio de sesión único (SSO) no funciona.
Si SSO no funciona, compruebe que los distintos servidores de Liberty que utilizan las mismas claves LTPA, contraseña y atributo ssoCookieName del elemento webAppSecurity tengan el mismo UTC (Universal Time) y compartan el mismo registro de usuarios. Asimismo, si la señal caduca o si la cookie se envía desde un navegador web después de cambiar el registro de usuario de un modo que es incoherente, como por ejemplo modificar el reino o eliminar el usuario al que representa la cookie, el SSO fallará y se solicitará al usuario que vuelva a especificar la información de credencial. Consulte Personalización de la configuración de SSO utilizando cookies LTPA en Liberty.
Depuración de las API públicas de seguridad
WSSecurityHelper y RegistryHelper se cargan aunque la seguridad no esté habilitada, por ejemplo, si no se especifica una característica de seguridad appSecurity-1.0, appSecurity-2.0 o zosSecurity-1.0. Si la seguridad no está habilitada, los métodos WSSecurityHelper.isServerSecurityEnabled() y WSSecurityHelper.isGlobalSecurityEnabled() devuelven el valor false y el método RegistryHelper.getUserRegistry() devuelve un nulo.

Puede que otras clases de la API pública de seguridad no se carguen si la seguridad no está habilitada. Si intenta acceder a estas clases e invoca un método en una de estas clases, puede obtener una excepción java.lang.NoClassDefFoundError.

Para no recibir las excepciones java.lang.NoClassDefFoundError, en primer lugar, debe comprobar si la seguridad está habilitada llamando a la claseWSSecurityHelper.isServerSecurityEnabled() o WSSecurityHelper.isGlobalSecurityEnabled() y llamando luego a otras clases de la API pública de seguridad sólo cuando la seguridad esté habilitada. Consulte API públicas de seguridad en Liberty para obtener ejemplos de esta técnica de codificación.

Nota: Este comportamiento es diferente de WebSphere Application Server tradicional. En WebSphere Application Server tradicional, todas las clases se cargan siempre independientemente de si la seguridad está habilitada o no.
No se pueden autenticar usuarios con caracteres Unicode
Para poder autenticar usuarios cuyos nombres contienen caracteres Unicode, debe establecer el tipo de codificación de caracteres utilizado por el servidor de Liberty en UTF-8 añadiendo la opción de JVM siguiente al mandato de inicio del servidor:
-Dclient.encoding.override=UTF-8
También debe especificar charset y pageEncoding en la página de inicio de sesión. A continuación se muestra un ejemplo de especificación de estos parámetros en una página JSP de sesión:
<%@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)
Este error se puede producir cuando un proveedor de OpenID Connect o OAuth utiliza un almacén de base de datos para el registro de clientes con algunas versiones de JDK 7.

Para evitar este problema, actualice a la versión 7.1 de JDK.

Resolución de problemas de LDAP

En este apartado se describen algunos de los problemas comunes de LDAP y las soluciones que puede elegir.

FFDC1015I: Se ha creado un incidente FFDC : javax.naming.ServiceUnavailableException: myldapserver.mycompany.com:636; socket closed com.ibm.ws.security.registry.ldap.internal.LdapRegistry 298
Este mensaje de messages.log indica que el servidor LDAP configurado no se puede localizar. Compruebe el servidor LDAP para verificar que se está ejecutando y que se puede acceder a su dirección IP desde el servidor Liberty.
javax.naming.CommunicationException: ha fallado el enlace simple: myldapserver.mycompany.com:636 [La excepción raíz es javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.g: ha fallado la creación de la vía de acceso PKIX: java.security.cert.CertPathBuilderException: no se ha podido encontrar la vía de acceso de certificación válida para el destino solicitado]
Si habilita SSL en el servidor LDAP sin copiar el firmante del servidor LDAP en el almacén de confianza al que se hace referencia en el elemento LDAPSSLSettings, una conexión con el servidor LDAP fallará con un error de reconocimiento de SSL. Asegúrese de que copia el firmante del servidor LDAP en el almacén de confianza.
javax.naming.CommunicationException: myldapserver.mycompany.com:389 [La excepción raíz es java.net.BindException: La dirección ya se está utilizando: conectar]
Este mensaje puede aparecer en los registros de FFDC e indica que los sockets utilizables en el servidor local se han agotado, lo que da como resultado un error durante la conexión con el servidor LDAP. Asegúrese de que no se utilice el socket e inténtelo de nuevo.
CWWKS1100A: La autenticación no ha sido satisfactoria para el ID de usuario xxxxx. Se ha especificado un ID de usuario o una contraseña que no son válidos
Esta excepción FFDC puede producirse en el servidor aunque el usuario mencionado en el mensaje sea un usuario válido en el servidor LDAP con una gran carga. Con la configuración LDAP, puede añadir la propiedad reuseConnection=false o inhabilitarla utilizando las herramientas del desarrollador. Para solucionar el problema, establezca esta propiedad en el valor predeterminado true.

Resolución de problemas de SSL

En este apartado se describen algunos problemas de SSL comunes y las soluciones que puede elegir.

CWWKS9105E: No se ha podido determinar el puerto SSL para redirección automática.
Este error se produce cuando intenta acceder a una aplicación que redirige a un puerto SSL y el puerto SSL no está disponible. El puerto podría no estar disponible debido a que falta la configuración SSL o a algún error en la definición de configuración SSL. Compruebe la configuración SSL en el archivo server.xml para asegurarse de que existe y es correcta. Consulte Protección de las comunicaciones con Liberty.
FFDC1015I: Se ha creado un incidente FFDC: "java.lang.IllegalArgumentException: Configuración incompleta desconocida: falta el campo de ID com.ibm.ws.config.internal.cm.ManagedServiceFactoryTracker aSyncReadNupdate. Se ha generado una excepción al intentar la leer la configuración y actualizar ManagedServiceFactory. Excepción = java.lang.IllegalArgumentException: Configuración desconocida, incompleta: falta el campo de ID" en ffdc_12.04.18_16.09.42.0.log
Este error se produce cuando existe un elemento keystore en la configuración sin un campo de ID. Si utiliza una configuración SSL mínima, establezca el ID de campo en defaultKeyStore.
Se producirá una excepción si utiliza un registro de usuarios LDAP con sslEnabled y no se especifica un valor sslRef.
Por ejemplo, supongamos que una configuración tiene sslEnabled establecido en true, pero no existe un valor sslRef, como se muestra en el ejemplo siguiente:
<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" />
Debe especificar un valor sslRef. Si está utilizando una configuración SSL mínima similar a la siguiente:
<ltkeyStore id="defaultKeyStore" location="key.jks"
password="mypassword" />
the sslRef field must be set to defaultSSLConfig.

Si se ha configurado una configuración SSL personalizada, el nombre de dicha configuración se debe colocar en el campo sslRef.

Si utiliza un JDK de WebSphere Application Server, es posible que vea el error siguiente si SSL está habilitado en el servidor de Liberty.
java.net.SocketException: java.lang.ClassNotFoundException: No se encuentra la clase especificada 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) 
Este error se produce porque las fábricas de sockets SSL de WebSphere Application Server no están admitidas en Liberty. Para omitir este problema, siga estos pasos:
  • Cree un archivo de texto como, por ejemplo, my.java.security con las siguientes dos entradas vacías:
    ssl.SocketFactory.provider=
    ssl.ServerSocketFactory.provider=
  • Cree un archivo jvm.options para el servidor de Liberty.
  • Añada la siguiente propiedad al archivo jvm.options, que incluye la vía de acceso completa al archivo de texto que acaba de crear
    -Djava.security.properties=fullPathTo/my.java.security 
  • Si desea que sea más reutilizable, puede poner el archivo my.java.security en el directorio del servidor y podrá utilizar una vía de acceso relativa como la siguiente:
    -Djava.security.properties=./my.java.security 

Para obtener más información, consulte Personalizar el entorno Liberty.

Resolución de problemas con CORBA/IIOP

En este apartado se describen algunos de los problemas comunes de CORBA y las soluciones que puede elegir.

Si utiliza JDK desde WebSphere Application Server, puede que le aparezca el siguiente error si la aplicación utiliza comunicaciones 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) 
        ...

Este error se produce porque los interceptores ORB (Object Request Broker - Intermediario para solicitudes de objetos) de WebSphere Application Server no están soportados en Liberty. Puede resolver este problema editando el archivo orb.properties desde JDK para no utilizar estos interceptores. Este archivo normalmente se encuentra en el directorio de WebSphere <JAVA_HOME>/jre/lib, aunque es posible que se haya reemplazado por una copia en el directorio <USER_HOME> del usuario. En el ejemplo siguiente se muestran las líneas en el archivo orb.properties que se deben descomentar:

# 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

Resolución de problemas de registro y rastreo

En esta sección se describen algunos problemas comunes con el registro y el rastreo.

java.util.logging -- interfaz de programación de registro Java.
Liberty no soporta la utilización del archivo logging.properties para configurar java.util.logging. Utilice el código Java como, por ejemplo, en una aplicación desplegada o la característica de usuario para crear y añadir manejadores, filtros o formateadores de java.util.logging.
Puesto que el servidor Liberty gestiona los niveles del registrador java.util.logging de acuerdo con el atributo traceSpecification del elemento de configuración de registro, evite utilizar el método Logger.setLevel.

Resolución de problemas de JAX-WS

En este apartado se describen algunos de los problemas comunes de JAX-WS y las soluciones que puede elegir.

Se ha producido la excepción org.apache.cxf.bus.extension.ExtensionException al desplegar la aplicación de servicios web en Liberty.
Si la aplicación tiene configuraciones y bibliotecas CXF ya incluidas y desea desplegar la aplicación en Liberty, asegúrese de que la característica de servidor jaxws-2.2 se haya inhabilitado eliminando la característica del archivo server.xml.
Se ha producido la excepción java.lang.NoClassDefFoundError al ejecutar la vía de acceso rápida IBM® con la JVM de Oracle.
Para utilizar IBM fastpath Java Architecture for XML Binding (JAXB), puede configurar la propiedad personalizada com.ibm.xml.xlxp.jaxb.opti.level para controlar si están habilitados los métodos de optimización para la desordenación (deserialización) y ordenación (serialización) de JAXB. Si se genera la excepción java.lang.NoClassDefFoundError al ejecutar la vía de acceso rápida de IBM JAXB con la JVM de Oracle, puede cambiar el valor de la propiedad com.ibm.xml.xlxp.jaxb.opti.level a 0 para desactivar la optimización. Por ejemplo, puede utilizar la propiedad -Dcom.ibm.xml.xlxp.jaxb.opti.level=0 de la línea de mandatos o añadir la línea siguiente al archivo jvm.options:
# Desactivar la optimización JAXB
-Dcom.ibm.xml.xlxp.jaxb.opti.level=0
Consulte más información de la propiedad com.ibm.xml.xlxp.jaxb.opti.level en la página Java virtual machine custom properties (Propiedades personalizadas de la máquina virtual Java).
Se ha producido la excepción java.lang.NoClassDefFoundError : com.ibm.CORBA.iiop.ORB al ejecutar el cliente ligero tradicional de WebSphere Application Server con la JVM de Oracle.
Este error se produce cuando se intenta ejecutar el cliente ligero WebSphere Application Server tradicional con la JVM Oracle y la característica jaxws-2.2 ya está habilitada en Liberty. Para resolver este problema, puede utilizar la propiedad -Dcom.ibm.websphere.thinclient=true al ejecutar el cliente ligero WebSphere Application Server tradicional del modo siguiente:
java -Dcom.ibm.websphere.thinclient=true 
     -cp <entradas_classpath_incluido_clienteligero_tWAS_jar> <WebServicesClientEntryClass> <cualquier_otro_parámetro_más>
Consulte la información similar de la propiedad com.ibm.websphere.thinclient en la página PM39777: ADMINISTRATIVE THIN CLIENT USING SOAP CONNECTOR AND SUN JDK DOES NOT WORK.
Se devuelve un archivo vacío al recuperar los archivos binarios de un servicio MTOM en un cliente de MTOM.
Esto ocurre cuando un cliente envía archivos binarios MTOM satisfactoriamente a un servicio MTOM, pero se devuelve un archivo vacío cuando recupera los mismos archivos binarios del servicio MTOM.
Como método alternativo, puede crear un nuevo DataHandler e inicializar el DataHandler rellenando el contenido del archivo binario. Por ejemplo, utilice un objeto FileDataStore para leer de la entrada/salida y devolver el DataHandler recién creado de nuevo y a continuación pasar el DataHandler a otros servicios 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;
...
Se ha producido el error javax.xml.ws.soap.SOAPFaultException: Unmarshalling al utilizar XMLGregorianCalendar en formato xsd:gMonth con la JVM de Oracle.
Este error se produce si utiliza la clase XMLGregorianCalendar para almacenar las constantes de formato gMonth como parte de la solicitud SOAP del lado de cliente y la característica jaxws-2.2 está habilitada en Liberty con la JVM de Oracle. La causa raíz es que la JVM de Oracle admite el nuevo formato estándar --MM para el tipo xsd:gMonth mientras que la última implementación de referencia (RI, Reference Implementation) de JAXB solo admite el formato de --MM--.
Para resolver este problema, puede cambiar la JVM de Oracle por la JVM de IBM para las aplicaciones del lado del cliente y del lado del servidor.
Se ha producido una excepción java.io.FileNotFoundException al resolver los archivos WSDL especificados mediante el atributo wsdlLocation.
Este error se produce cuando especifica el archivo WSDL en el código wsdlLocation = "file:/WEB-INF/wsdl/a.wsdl" y el archivo WSDL está empaquetado en la aplicación. Si desea hacer referencia al archivo WSDL empaquetado en la aplicación, debe utilizar las URI relativas para el atributo wsdlLocation definido en la anotación @WebService, @WebServiceProvider, @WebServiceClient o @WebServieRef.
La URI relativa del atributo wsdlLocation debe ser uno de los valores siguientes:
  • wsdlLocation = "/WEB-INF/wsdl/a.wsdl"
  • wsdlLocation = "WEB-INF/wsdl/a.wsdl"
Se generan muchos mensajes "Creando servicio" en el archivo messages.log.
Este caso se produce cuando llama a getPort o a los métodos relacionados de las clases de apéndice de cliente generadas. Liberty se ha configurado con la configuración de registro predeterminada y todos los mensajes de información se escriben en el archivo messages.log. Existen muchas apariciones de mensajes que podrían ser similares al siguiente:
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
Para suprimir estos mensajes de información, puede cambiar la configuración de registro en el archivo server.xml del modo siguiente:
<logging traceSpecification="org.apache.cxf.*=warning=enabled"/>
SOAPFaultException: la prueba SOAPAction especificada no coincide con una operación producida cuando una aplicación cliente enviaba una acción SOAP.
Nota: prueba es el valor del atributo soapAction en la cabecera HTTP de solicitud.
Cada operación de un servicio web SOAP puede estar asociada a una serie de acción SOAP, como en el enlace WSDL o mediante una anotación. El cliente de servicio web envía la serie de acción SOAP como una cabecera con la solicitud para que coincida con la operación del proveedor de servicios web. El mensaje de error se visualiza en cualquiera de los escenarios siguientes:
  • Cuando la acción SOAP enviada por el cliente no coincide con la acción SOAP de la operación.
  • Cuando utiliza WebSphere Application Server tradicional como el cliente JAX-WS y Liberty como el servicio JAX-WS y la soapAction definida en el archivo WSDL es igual a un valor vacío "".
Para resolver este problema:
  • Asegúrese de especificar la misma acción SOAP para el cliente de servicio web y el proveedor de servicios.
  • Proporcione un valor válido para el atributo soapAction que se haya definido en el archivo WSDL o no utilice soapAction en el archivo WSDL.
Se genera javax.xml.ws.WebServiceException al utilizar el método Service.create() para crear servicio.
Este error se produce si utiliza el método Service.create() para crear un servicio a pesar de que no se proporciona el documento WSDL. Si desea utilizar Service.create() para crear un servicio y el método getPort() para obtener el número de puerto, debe utilizar el método addPort() para proporcionar la información de enlace.
Se proporciona un código de ejemplo de muestra como sigue sobre cómo utilizar el método addPort():
QName serviceName = new QName("http://test.com/wssvt/acme/InsBusiness/", "MTOM11Service");
QName portName = new QName("http://test.com/wssvt/acme/InsBusiness/", "MTOM11Port");

// Configurar los artefactos JAX-WS necesarios
Service svc = Service.create(serviceName);
// Añadir el puerto en la instancia de servicio
svc.addPort(portName, SOAPBinding.SOAP11HTTP_MTOM_BINDING, mtom11URL); 

port = svc.getPort(portName, MTOMInterface.class);
Se devuelve la respuesta NULL cuando el atributo name de la anotación @WebResult es distinto del elemento name del documento WSDL.
Se produce este problema cuando utiliza una clase SEI para definir el atributo name para la anotación @WebResult y la clase SEI proporciona la ubicación WSDL como se indica a continuación:
@WebService(wsdlLocation="WEB-INF/wsdl/WebServiceIfc.wsdl")
public interface WebServiceRuntimeIfc {
        @WebMethod
        @WebResult(name="nononoreturn") 
        public String echo (String parm);
}
Sin embargo, la declaración del elemento XML en el documento WSDL proporcionado es como se detalla a continuación:
<xs:element name="echoResponse">
	<xs:complexType>
		<xs:sequence>
			<xs:element name="return" type="xs:string" minOccurs="0"/>
		</xs:sequence>
	</xs:complexType>
</xs:element>
A continuación el cliente de servicio web obtiene una respuesta NULL cuando se llame al método echo().
Para resolver este problema, asegúrese de que el atributo name de la anotación @WebResult coincide con el valor del elemento name en el documento WSDL.
La aplicación cliente JAX-WS no ha podido obtener los cambios en el documento WSDL desde el lado del servidor.
El problema sucede cuando el cliente de servicio web y el proveedor de servicios se encuentran en dos aplicaciones distintas en Liberty y el cliente tiene que recuperar el documento WSDL del proveedor de servicios dinámicamente. Puesto que Liberty almacena en la caché la definición WSDL cuando se accede al documento WSDL por primera vez, que es diferente del comportamiento en WebSphere Application Server tradicional. Mediante el almacenamiento en memoria caché de la definición WSDL en Liberty, las aplicaciones pueden impedir conectarse y analizar el documento WSDL con frecuencia.
Para resolver este problema, debe reiniciar la aplicación cliente, de forma que las definiciones WSDL actualizadas se puedan volver a cargar.
Aviso JAXB durante la importación de WSDL
El mensaje de aviso siguiente se puede encontrar mientras se importa un archivo WSDL.
[AVISO] elemento o atributos de
extensibilidad desconocido "wsdl" (en espacio de nombres "http://www.w3.org/2000/xmlns/" (http://www.w3.org/2000/xmlns/%27) )

Resolución de problemas de WS-Security

En este apartado se describen algunas soluciones comunes que puede utilizar para solucionar los problemas de WS-Security.
  1. Compruebe el archivo server.xml para asegurarse de que se han configurado correctamente las características de JAX-WS (jaxws-2.2) y de seguridad (appSecurity-2.0).
  2. Para proteger la aplicación de servicio web con WS-Security, la aplicación JAX-WS debe contener un archivo WSDL que tenga incluida una política WS-Security. Debe haber una PolicyReference a la política WS-Security incluida en las secciones wsdl:binding o wsdl:operation, o en las dos.
  3. Si utiliza un manejador de devolución de llamada para recuperar las contraseñas con el fin de generar UsernameTokens o para recuperar las contraseñas de las claves privadas de los archivos de almacén de claves, se debe empaquetar y desplegar el manejador de devolución de llamada de contraseña como una característica de usuario de Liberty.

Habilitación del rastreo de WS-Security

Si la causa del problema no se puede determinar mediante la información del mensaje de error, puede utilizar el recurso de registro y rastreo de Liberty para recopilar el rastreo del componente WS-Security. Consulte Liberty: Rastreo y registro.

Puede utilizar la serie de rastreo siguiente para recopilar el rastreo con el fin de depurar las anomalías de WS-Security:
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

En este apartado se describen algunos problemas de WS-Security comunes y las soluciones que puede elegir.

org.apache.cxf.ws.policy.PolicyException: no puede cumplirse ninguna de las alternativas de política.
Este error suele producirse cuando la característica de WS-Security wsSecurity-1.1 no está definida en el archivo server.xml. Para impedir este error, debe definir la característica wsSecurity-1.1 en el archivo server.xml como se indica a continuación:
<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: no está disponible ningún manejador de devolución de llamada ni ninguna contraseña.
Este error se produce cuando el módulo ejecutable de WS-Security no puede recuperar una contraseña que se necesita para generar una UsernameToken o para acceder a una clave privada del almacén de claves. Para impedir este error, compruebe la configuración siguiente:
  1. Asegúrese de que la característica de manejador de devolución de llamada de contraseña wsseccbh-1.0 está definida como una característica de usuario en el archivo 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. Asegúrese de que la propiedad de manejador de devolución de llamada ws-security.callback-handler está definida en los elementos <wsSecurityClient> o <wsSecurityProvider> del archivo server.xml:
    ws-security.callback-handler="<nombre de clase completo del manejador de devolución de llamada>"
    
    ejemplo:
    ws-security.callback-handler="com.ibm.ws.wssecurity.example.cbh.CommonPasswordCallback"
  3. Asegúrese de que el manejador de devolución de llamada de contraseña devuelve la contraseña correcta para el nombre de usuario o el alias de clave especificados en el archivo server.xml. La contraseña debe ser texto simple y no debe estar codificada ni cifrada.
org.apache.ws.security.WSSecurityException: la firma no cubre los elementos necesarios (soap:Body).
Este error se produce cuando una aplicación de proveedor de servicios web espera que el cuerpo SOAP del mensaje de solicitud esté firmado, pero el mensaje SOAP recibido no tiene firmado el cuerpo SOAP. Para evitar este error, asegúrese de que el cliente de servicio web está configurado con la política WS-Security correcta que cumple la política del proveedor de servicios web.
org.apache.ws.security.WSSecurityException: la firma o el descifrado no eran válidos.
Este error se produce cuando el módulo ejecutable de WS-Security no puede validar la firma o descifrar una parte de un mensaje cifrado en el mensaje SOAP recibido. Para impedir este error, verifique que se utilizan las claves correctas al configurar WS-Security en los elementos <wsSecurityClient> y <wsSecurityProvider> del archivo server.xml. Si un cliente de servicio web utiliza la clave pública de Bob para cifrar una parte de un mensaje, el proveedor de servicios web debe tener acceso a la clave privada de Bob para descifrar el mensaje. De forma similar, si un cliente de servicio web firma la parte de un mensaje utilizando la clave privada de Alice, el proveedor de servicios web debe utilizar la clave pública de Alice para validar la firma.
org.apache.cxf.ws.policy.PolicyException: No se pueden cumplir estas alternativas de política.
Este error se produce cuando el módulo ejecutable de WS-Security no puede procesar el mensaje SOAP entrante mediante la política WS-Security configurada para procesar esta solicitud. Para impedir este error, busque los mensajes que siguen esta excepción para determinar las aserciones de política WS-Security que provocan esta excepción. Por ejemplo, el archivo de registro cronológico podría contener estos mensajes:
Provocado por: org.apache.cxf.ws.policy.PolicyException: Estas alternativas de política no pueden cumplirse: 
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}AsymmetricBinding: El algoritmo de cifrado no coincide con el requisito
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}InitiatorEncryptionToken
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}RecipientEncryptionToken
en org.apache.cxf.ws.policy.AssertionInfoMap.checkEffectivePolicy(AssertionInfoMap.java:167)
en org.apache.cxf.ws.policy.PolicyVerificationInInterceptor.handle(PolicyVerificationInInterceptor.java:101)
En este caso, el error se ha producido porque el algoritmo de cifrado que el cliente de servicios web utiliza no coincide con el algoritmo de cifrado especificado por la aserción AlgorithmSuite. Las suite de algoritmos especificadas en la política WS-Security del cliente y del proveedor de servicios web deben especificar el mismo algoritmo de cifrado.
javax.xml.ws.soap.SOAPFaultException: el mensaje ha caducado (WSSecurityEngine: indicación de fecha y hora no válida, la semántica de seguridad del mensaje ha caducado).
Este mensaje se produce cuando ha caducado la indicación de fecha y hora del mensaje o cuando se ha creado el mensaje con una indicación de fecha y hora futuras.
For distributed platformsFor IBM i platforms

Aplicación de fixpacks y arreglos temporales para una instalación de archivado

Si ha instalado el entorno de ejecución de Liberty desde un archivo de archivado, en lugar de mediante Installation Manager, debe tomar medidas especiales cuando aplique las actualizaciones de servicio. Para obtener más información, consulte los apartados Aplicación de un fixpack en una instalación de archivado Java Liberty y Aplicación de un arreglo temporal a una instalación de archivado de Liberty.

Resolución de problemas de rendimiento

En este apartado se describen algunos de los problemas comunes de rendimiento y las soluciones que puede elegir.

Uso elevado de CPU por parte del supervisor de aplicaciones.

Este error se puede producir si su supervisor de aplicaciones tiene demasiados archivos en el directorio apps/ y está realizando sondeos con demasiada frecuencia.

Para evitar este problema, hay bastantes cosas que puede cambiar.

  1. Aumente el valor del atributo pollingRate en el elemento applicationMonitor.
  2. Actualice server.xml para que incluya un elemento applicationMonitor con un valor updateTrigger que no sea polled.
    server.xml                                                                      
    <applicationMonitor updateTrigger="mbean" /> 
  3. Reduzca el número de archivos del directorio apps/.

Para obtener más información sobre el elemento applicationMonitor, consulte Control de las actualizaciones dinámicas.

Resolución de problemas de colectivos

Esta sección describe un problema con colectivos y la solución que debe aplicar.

java.lang.IllegalArgumentException: CWWKX0219E: El MBean 'WebSphere:feature=collectiveController,type=CollectiveRepository,name=CollectiveRepository' no tiene una operación con el nombre 'retrieveMemberRootCertificate'
Un servidor con la característica collectiveMember-1.0, un miembro, no se puede registrar con un servidor con la característica collectiveController-1.0, un controlador, que está en un nivel inferior de Liberty. Por ejemplo, un miembro en este nivel beta de Liberty no se puede registrar a sí mismo con un controlador en V8.5.5.2 de Liberty.

Con el registro predeterminado, este problema se notifica como Captura de datos en primer error (FFDC) en los registros FFDC del miembro.

Para arreglar el problema, debe mover el controlador al mismo nivel o uno superior de Liberty como miembro.

Resolución de problemas de SAML

Esta sección describe un problema con SAML y la solución que debe aplicar.

java.lang.ArrayIndexOutOfBoundsException: índice de matriz fuera de rango: 0
Esta excepción puede producirse cuando intenta varios inicios de sesión mediante una solicitud iniciada de proveedor de servicios (SP) no solicitado sin eliminar la señal de proveedor de identidad (IdP).
Para evitarlo, añada <httpSession invalidateOnUnauthorizedSessionRequestException="true" /> en el archivo server.xml no solicitado correspondiente.
java.lang.IllegalStateException: CWWKS0010E: Al obtener el principal del interlocutor, se ha encontrado que el asunto de interlocutor tenía más de un principal de tipo WSPrincipal. Sólo puede existir un WSPrincipal en el asunto. Los nombres de los WSPrincipal son: {0}
Esta excepción se puede producir si anteriormente un usuario de SAML ha iniciado sesión directamente en el registro de usuarios local. Para evitar este problema, un usuario de SAML no debe iniciar sesión directamente en un registro de usuarios local.

Resolución de problemas de descubrimiento de API REST

Si se selecciona "Pruébelo" en IBM REST API Discovery Explorer de forma remota y se produce un error con un código de respuesta igual a 0, asegúrese de que el nombre de host completo o la dirección IP se devuelve a IBM REST API Discovery Explorer en el Curl y el URL de solicitud asociado con la operación GET, PUT, POST o DELETE. Si el nombre de host completo o la dirección IP no se encuentra en el URL de solicitud y Curl, realice las acciones siguientes:

  1. Añada el elemento de variable en server.xml y especifique el nombre de host completo. A continuación se proporciona el ejemplo de adición del elemento de variable que especifica el nombre de host completo en el archivo server.xml:
     <httpEndpoint host="*" httpPort="9080" httpsPort="9443" id="defaultHttpEndpoint"/>          
    <variable name="defaultHostName" value="developer.rtp.raleigh.ibm.com"/>
  2. For distributed platforms Especifique el nombre de sistema completo para el sistema operativo como el nombre de host completo.
  3. Compruebe que se devuelva el nombre de host completo en el Curl y el URL de solicitud asociado con las operaciones GET, PUT, POST o DELETE de IBM REST API Discovery Explorer. Para obtener más información, consulte Establecimiento del nombre de host predeterminado de un servidor Liberty y lea sobre la configuración de la red en la documentación del producto IBM InfoSphere Information Server, Versión 11.3.1.

Icono que indica el tipo de tema Tema de referencia

Nombre de archivo: rwlp_trouble.html