Glassfish 3.1.2.2: IIOP1002: Principal propagation: Ich kann keine Principal Information in Betreff finden

Question

Ich versuche die Ursache für eine nervige Nachricht in Glassfish aufzuspüren, die unsere Protokolldateien verschmutzt.

Um unsere Einrichtung zu vereinfachen, haben wir 2 Glassfish-Server mit 3.1.2.2.

Auf Server A ist ein Webdienst implementiert, der zertifikatsbasierte Sicherheit verwendet, die mithilfe von Rollen im Webdienst und den Zuordnungen in sun-ejb-jar.xml und sun-application.xml definiert wird.

Auf Server B ist ein Remote-EJB installiert, auf dem keine Sicherheit konfiguriert ist.

Wenn der Remote-EJB auf Server B Aufruf von dem Web-Dienst auf Server A Code wie:

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(); 

Das Protokoll auf Server A erhält den es angemeldet, wobei jedoch der EJB-Aufruf funktioniert wie erwartet .

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

Hat jemand Erfahrung mit diesem Fehler gehabt und weiß, wie man dieses Problem löst?

Die Oracle Documentation auf die Nachricht ist nicht sehr hilfreich.

IIOP1002 Hauptausbreitungs: Haupt Informationen nicht

in Thema gefunden

Ursache: Die Hauptinformation nicht in dem Thema gefunden wird

Aktion: die Konfigurationseinstellungen für die Identitäts Ausbreitung Bitte überprüfen

Answer 1

Wir hatten ein ähnliches Problem im Zusammenhang mit der Identitätsweitergabe, aber wir haben Spam auf dem Server, auf dem die Remote-EJBs bereitgestellt wurden. Das wäre Server B in Ihrem Setup. Beispielprotokolleintrag:

[#|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)|#] 

Wir lösten es durch Vermehrung für den Remote-EJBs auf dem Server zu deaktivieren, wenn der Remote-EJBs eingesetzt werden. Leider mussten wir das für jeden einzelnen entfernten EJB tun. Zumindest die Protokolle sind jetzt besser lesbar. Die Deaktivierung erfolgt in glassfish-ejb-jar.xml für die ejb-jar-Datei, die die entfernten ejbs enthält.

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