David Jencks wrote:
I have no idea what the solution might be, but this also didn't work
with the sun orb.
That makes me feel better then. The solution is to call
loadPOA.destroy(true, false); rather than the deactivate code it's
current using. Just tested this out, and it deployed and redeployed
just fine.
Rick
See GERONIMO-2063
thanks
david jencks
On Oct 20, 2006, at 9:03 AM, Rick McGuire wrote:
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
|
