2012-09-20 8 views
6

Próbuję wyśledzić przyczynę denerwującej wiadomości w Glassfish, która zanieczyszcza nasze pliki dziennika.Glassfish 3.1.2.2: IIOP1002: Główna propagacja: Nie można znaleźć głównych informacji w temacie

Aby uprościć konfigurację, mamy 2 serwery typu glassfish z systemem 3.1.2.2.

Serwer A ma wdrożoną usługę internetową, korzystającą z zabezpieczeń opartych na certyfikatach zdefiniowanych przy użyciu ról w usłudze internetowej i odwzorowań w plikach sun-ejb-jar.xml i sun-application.xml.

Serwer B ma wdrożone zdalne EJB, bez skonfigurowanych zabezpieczeń.

Podczas wywoływania zdalnego EJB na serwerze B, z usług internetowych na serwerze A przy użyciu kodu jak:

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

dziennika na serwerze A dostaje się co następuje logowanie do niego, ale wywołanie EJB działa zgodnie z oczekiwaniami .

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

Czy ktoś miał doświadczenie w tym błędzie i wiedział, jak rozwiązać ten problem?

Wiadomość Oracle Documentation w tej wiadomości nie jest bardzo pomocna.

IIOP1002 Principal propagacji: Nie można znaleźć podstawowe informacje w temat

Przyczyna: Główną informacja nie zostanie znaleziony w temacie

Działanie: Należy sprawdzić ustawienia konfiguracyjne dla rozmnażania tożsamości

+0

Czy byłeś w stanie rozwiązać ten problem? –

+1

@defaultlocale niestety nie, to jest na odwrót i zapomniane. To na pewno sprawia, że ​​czytanie dzienników to ból! –

Odpowiedz

0

Mamy podobny problem związany z propagacją tożsamości, ale mamy spam w dzienniku na serwerze, na którym wdrożono zdalne EJB. To byłby Serwer B w twojej konfiguracji. Próbka wpisu:

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

Rozwiązaliśmy go wyłączając propagacji dla zdalnych EJB na serwerze, gdzie pilot EJB są wdrażane. Niestety wydaje się, że musieliśmy to zrobić dla każdego zdalnego EJB. Przynajmniej dzienniki są teraz bardziej czytelne. Wyłączanie odbywa się w pliku glassfish-ejb-jar.xml dla pliku ejb-jar zawierającego zdalne ejbs.

<?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> 
Powiązane problemy