Half the time, Locator.getCompositeInstances() fails due to EJB permissions

Question

Within an embedded Java statement in a BPEL process, I am trying to get a handle on all composites that have the same ECID as the current composite. I think I have got the code I need, but I am running into the strangest problem: with every test instance, the section of the code that I will paste below will either work perfectly, OR raise this exception: *"EJB Exception: ; nested exception is: java.lang.RuntimeException: Caller doesn't have enough permission to call this method"*. When I created a SoapUI testscript to launch a number of test cases sequentially, it even seemed to be perfectly alternating (ok-error-ok-error...). I know what that looks like, but, I do not run on a load balanced cluster - just an admin server and a single soa-infra1 managed server.
I use the following code:
try
oracle.soa.management.facade.Locator locator = oracle.soa.management.facade.LocatorFactory.createLocator();
oracle.soa.management.util.CompositeInstanceFilter filter = new oracle.soa.management.util.CompositeInstanceFilter();
filter.setECID(this.getRootId());
addAuditTrailEntry("About to execute query");
java.util.List<oracle.soa.management.facade.CompositeInstance> instances = locator.getCompositeInstances(filter);
addAuditTrailEntry("Done with query");
catch (java.rmi.RemoteException re)
this.setCompositeInstanceTitle("Error");
addAuditTrailEntry(re.getMessage());
The audit trail tells me that the statement that fails is locator.getCompositeInstances(filter). I have put a call in to "locator.getServiceEngines()" to see if any call to the locator would fail, but that statement never gives me trouble.
Anyone out there has a clue as to what I'm missing here? Is this not the correct way to obtain a valid Locator within embedded Java?
Thanks,
Peter

Answer 1

Update:
1.) It's not a perfect "error-ok-error-ok" pattern. But it does average out to a 50/50 success/failure rate.
2.) In the logs, after turning up the EJB security logging, I see many lines indicating "pushing" and "popping" of prinicpals. And as I expected, sometimes the principal is empty, sometimes it's "weblogic".
3.) When I change the LocatorFactory.createLocator() call to include the standard "external" context factory settings, everything works flawlessly:
java.util.Hashtable props = new java.util.Hashtable();
props.put(javax.naming.Context.PROVIDER_URL, "t3://localhost:8001/soa-infra");
props.put(javax.naming.Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
props.put(javax.naming.Context.SECURITY_PRINCIPAL, "weblogic");
props.put(javax.naming.Context.SECURITY_CREDENTIALS, "welcome1");
props.put("dedicated.connection", "true");
locator = oracle.soa.management.facade.LocatorFactory.createLocator(props);
So apparently, you are not allowed to use the "default" Locator returned by LocatorFactory.createLocator() when inside embedded Java. Am I mistaken, or was that fine in 10.1.3? It feels utterly strange hardcoding these credentials and other values in embedded Java (or even parametrizing them).
Thanks,
Peter
Edited by: Peter_Ebell on Oct 18, 2010 8:42 AM