2012-09-20 20 views
6

Estoy intentando rastrear la causa de un mensaje molesto en glassfish que está contaminando nuestros archivos de registro.Glassfish 3.1.2.2: IIOP1002: Propagación principal: No se puede encontrar la información principal en el asunto

Para simplificar nuestra configuración, tenemos 2 servidores glassfish ejecutando 3.1.2.2.

El servidor A tiene un servicio web desplegado en él, utilizando seguridad basada en certificados definida utilizando roles en el servicio web y las asignaciones en sun-ejb-jar.xml y sun-application.xml.

El servidor B tiene implementado un EJB remoto, sin configuración de seguridad.

Al llamar al EJB remoto en el servidor B, desde el servicio web en el servidor A utilizando código como:

Properties props = new Properties(); 
props.setProperty("java.naming.factory.initial", "com.sun.enterprise.naming.SerialInitContextFactory"); 
props.setProperty("java.naming.factory.url.pkgs", "com.sun.enterprise.naming"); 
props.setProperty("java.naming.factory.state", "com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl"); 
props.setProperty("org.omg.CORBA.ORBInitialHost", server.getServer()); 
props.setProperty("org.omg.CORBA.ORBInitialPort", Integer.toString(server.getEjb3Port())); 
InitialContext ic = new InitialContext(props); 

return ((MyIF)ic.lookup(MyIF.class.getName())).doWork(); 

El registro en el servidor A tiene la siguiente conectado a ella, pero la llamada EJB funciona como se esperaba .

[#|2012-09-20T08:43:42.141+0100|SEVERE|glassfish3.1.2|javax.enterprise.system.core.security.com.sun.enterprise.iiop.security|_ThreadID=26;_ThreadName=Thread-2;|IIOP1002: Principal propagation: Cannot find principal information in subject|#] 

¿Alguien ha tenido alguna experiencia con este error y sabe cómo resolver este problema?

El Oracle Documentation en el mensaje no es muy útil.

IIOP1002 propagación principal: No se puede encontrar la información principal en sujeto

Causa: La información principal no se encuentra en el tema

Acción: Por favor, compruebe los ajustes de configuración para la propagación de identidad

+0

¿Pudo resolver esto? –

+1

@defaultlocale, desafortunadamente no, se puso en un segundo plano y se olvidó. ¡Claro, eso hace que leer registros sea doloroso! –

Respuesta

0

Tuvimos un problema similar relacionado con la propagación de identidad, pero obtuvimos spam de registro en el servidor donde se desplegaron los EJB remotos. Ese sería el Servidor B en su configuración. Muestra entrada de registro:

[#|2013-06-05T10:36:50.111+0000|SEVERE|glassfish3.1.2|javax.enterprise.resource.corba.com.sun.enterprise.common.iiop.security|_ThreadID=24;_ThreadName=Thread-2;|iiop.importname_exception 
java.io.IOException: Invalid Name 
    at com.sun.enterprise.iiop.security.GSSUtils.importName(GSSUtils.java:158) 
    at com.sun.enterprise.iiop.security.GSSUtilsService.importName(GSSUtilsService.java:63) 
    at com.sun.enterprise.common.iiop.security.GSSUPName.<init>(GSSUPName.java:97) 
    at com.sun.enterprise.iiop.security.SecServerRequestInterceptor.createIdCred(SecServerRequestInterceptor.java:349) 
    at com.sun.enterprise.iiop.security.SecServerRequestInterceptor.receive_request(SecServerRequestInterceptor.java:547) 
    at com.sun.corba.ee.impl.interceptors.InterceptorInvoker.invokeServerInterceptorIntermediatePoint(InterceptorInvoker.java:612) 
    at com.sun.corba.ee.impl.interceptors.PIHandlerImpl.invokeServerPIIntermediatePoint(PIHandlerImpl.java:612) 
    at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.getServantWithPI(CorbaServerRequestDispatcherImpl.java:333) 
    at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:196) 
    at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1624) 
    at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1486) 
    at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:990) 
    at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:214)  at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:742) 
    at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:539) 
    at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2324) 
    at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497) 
    at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)|#] 

Nos lo resolvió mediante la desactivación de propagación para los EJB remotos en el servidor donde se despliegan los EJB remoto. Desafortunadamente, parece que teníamos que hacer eso para cada EJB remoto. Al menos los registros son más legibles ahora. La desactivación se realiza en glassfish-ejb-jar.xml para el archivo ejb-jar que contiene los ejbs remotos.

<?xml version="1.0" encoding="UTF-8"?> 
<!DOCTYPE glassfish-ejb-jar PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 EJB 3.1//EN" "http://glassfish.org/dtds/glassfish-ejb-jar_3_1-1.dtd"> 
<glassfish-ejb-jar> 
    <enterprise-beans> 
     <ejb> 
      <ejb-name>RemoteEjb1</ejb-name> 
      <ior-security-config> 
       <sas-context> 
        <caller-propagation>NONE</caller-propagation> 
       </sas-context> 
      </ior-security-config> 
     </ejb> 
     <ejb> 
      <ejb-name>RemoteEjb2</ejb-name> 
      <ior-security-config> 
       <sas-context> 
        <caller-propagation>NONE</caller-propagation> 
       </sas-context> 
      </ior-security-config> 
     </ejb> 
    </enterprise-beans> 
</glassfish-ejb-jar> 
Cuestiones relacionadas