incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <rick...@gmail.com>
Subject Deactivating POAs
Date Fri, 20 Oct 2006 16:03:54 GMT
We're seeing an interesting problem with Geronimo+Yoko that I'm 
struggling with.  The problem first manifested when deploying an app, 
undeploying, then redeploying.   On the redeploy, it was receiving this 
error:

09:40:52,546 WARN  [TSSBean] Failed CORBA Target Security Service in POA 
org/apache/openejb/POA
09:40:52,546 ERROR [GBeanInstanceState] Error while starting; GBean is 
now in the FAILED state: 
abstractName="openejb/security/2.2-SNAPSHOT/car?ServiceModule=openejb/security/2.2-SNAPSHOT/car,j2eeType=CORBATSS,name=openejb/itests"
org.omg.PortableServer.POAPackage.AdapterAlreadyExists: 
IDL:omg.org/PortableServer/POA/AdapterAlreadyExists:1.0
    at 
org.apache.yoko.orb.OBPortableServer.POA_impl.create_POA(POA_impl.java:657)
    at org.apache.openejb.corba.TSSBean.doStart(TSSBean.java:124)
    at 
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:984)
    at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267)
    at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
    at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124)
    at 
org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:543)


The undeploy code use the following logic to shut things down:

public void doStop() throws Exception {
        if (localPOA != null) {
            try {
                localPOA.the_POAManager().deactivate(true, false);
            } catch (AdapterInactive adapterInactive) {
                // do nothing - this may have already been deactivated.
            }
            localPOA = null;
        }
        log.debug("Stopped CORBA Target Security Service in POA " + 
POAName);
    }


And this is the startup logic: 

    public void doStart() throws Exception {
        ClassLoader savedLoader = 
Thread.currentThread().getContextClassLoader();
        try {
            Thread.currentThread().setContextClassLoader(classLoader);

            ORB orb = server.getORB();
            POA rootPOA = server.getRootPOA();

            Any any = orb.create_any();
            any.insert_Value(new 
ServerPolicy.Config(createCSIv2Config(), classLoader));

            securityPolicy = 
orb.create_policy(ServerPolicyFactory.POLICY_TYPE, any);
            Policy[] policies = new Policy[]{
                    securityPolicy,
                    
rootPOA.create_lifespan_policy(LifespanPolicyValue.TRANSIENT),
                    
rootPOA.create_request_processing_policy(RequestProcessingPolicyValue.USE_ACTIVE_OBJECT_MAP_ONLY),
                    
rootPOA.create_servant_retention_policy(ServantRetentionPolicyValue.RETAIN),
                    
rootPOA.create_id_assignment_policy(IdAssignmentPolicyValue.USER_ID),
                    
rootPOA.create_implicit_activation_policy(ImplicitActivationPolicyValue.NO_IMPLICIT_ACTIVATION),
            };
            localPOA = rootPOA.create_POA(POAName, 
rootPOA.the_POAManager(), policies);

            localPOA.the_POAManager().activate();

            org.omg.CORBA.Object obj = 
server.getORB().resolve_initial_references("NameService");
            initialContext = NamingContextExtHelper.narrow(obj);
        } finally {
            Thread.currentThread().setContextClassLoader(savedLoader);
        }

        log.debug("Started CORBA Target Security Service in POA " + 
POAName);
    }


The exception is being thrown by the create_POA() call in doStart().  
This logic is unchanged from prior releases, and I believe (but not yet 
been able to confirm) that this worked correctly with the Sun ORB.  My 
initial thinking was this required a call to destroy() on the localPOA 
instance to remove this from the activated list, so I added that.  
However, this resulted in a different exception on the restart:

|Caused by: org.apache.geronimo.gbean.InvalidConfigurationException: Configuration openejb/security/2.2-SNAPSHOT/car
failed to start due to the following reasons:|
|  The service ServiceModule=openejb/security/2.2-SNAPSHOT/car,j2eeType=CORBATSS,name=openejb/itests
did not start because the doStart method threw an exception. |
|java.lang.NullPointerException|
|    at org.apache.yoko.orb.OBPortableServer.POAManager_impl._OB_getAcceptors(POAManager_impl.java:834)|
|    at org.apache.yoko.orb.OBPortableServer.POA_impl.init(POA_impl.java:400)|
|    at org.apache.yoko.orb.OBPortableServer.POA_impl.<init>(POA_impl.java:533)|
|    at org.apache.yoko.orb.OBPortableServer.POA_impl.create_POA(POA_impl.java:697)|
|    at org.apache.openejb.corba.TSSBean.doStart(TSSBean.java:124)|
|    at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:984)


So it looks like the destroy() call somehow corrupted the rootPOA so 
things no longer work. 

The first thing I'd like to establish before chasing this down is what 
should be required to remove the POA so it can be recreated later.  Is 
the destroy() a necessary step and is there just a problem with 
destroy() cleaning up too much?

Rick
|


Mime
View raw message