Deployment order: JDBC before Realm?

[Chris Goodacre]

I am having problem deploying my custom security realm, and it seems to be having
problems with the DataSource the realm uses.

I am not *positive* that I created/deployed the DataSource correctly, but I wanted
to check out this avenue first:

Does Weblogic try to create the security realm before it deploys DataSources?

The document at

http://e-docs.bea.com/wls/docs61////adminguide/appman.html

states that the deployment order is:
1. JDBC Connection Pools
2. JDBC Multi Pools
3. JDCB Data Sources
4. JDBC Tx Data Sources
5. JMS Connection Factories
6. JMS Servers
7. Connector Components
8. EJB Components
9. Web App Components

But it doesn't make any mention of Security realms.

The code that is causing the problems looks like this:
public static final synchronized Object lookup(String pName)
throws LookupException{
try{
if (Lookup._ctx == null) {
java.util.Properties props =
new java.util.Properties();
props.put(InitialContext.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
props.put(InitialContext.PROVIDER_URL,"t3://localhost:7001");
Lookup._ctx = new InitialContext(props);
}
return Lookup._ctx.lookup(pName);
}
catch(NamingException ne){
ne.printStackTrace();
throw new LookupException("Naming errors from the initial context:\n"
+ ne);
}
}

Where pName = "SecurityDataSource" - which indeed is the name of the datasource
I created.

The specific exception I get is:
javax.naming.ServiceUnavailableException. Root exception is java.rmi.NoSuchObjectException:
The object identified by: '9' could not because found. Either it was has not
been exported or it has been collected by the distributed garbage collector.
at weblogic.rmi.internal.OIDManager.getServerReference(OIDManager.java:432)
at weblogic.jndi.WLInitialContextFactoryDelegate.newLocalContext(WLInitialContextFactoryDelegate.java:409)
at weblogic.jndi.WLInitialContextFactoryDelegate.newContext(WLInitialContextFactoryDelegate.java:369)
at weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext(WLInitialContextFactoryDelegate.java:338)
at weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext(WLInitialContextFactoryDelegate.java:211)
at weblogic.jndi.WLInitialContextFactory.getInitialContext(WLInitialContextFactory.java:149)
at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
at javax.naming.InitialContext.init(Unknown Source)
at javax.naming.InitialContext.<init>(Unknown Source)
at com.cna.covere.naming.Lookup.lookup(Lookup.java:29)
at com.cna.covere.dao.DAOManagerFactoryImpl.setDataSourceNames(DAOManagerFactoryImpl.java:165)
at com.cna.covere.dao.DAOManagerFactoryImpl.<init>(DAOManagerFactoryImpl.java:59)
at com.cna.covere.dao.DAOManagerFactoryImpl.getInstance(DAOManagerFactoryImpl.java:70)
at com.cna.covere.dao.AbstractSQLManager.<clinit>(AbstractSQLManager.java:25)
at com.cna.covere.security.CovereRealm.<init>(CovereRealm.java:40)

Any help a/o advice would be greatly appreciated.

-chris

[Simon Spruzen]

The security realm is initialised very early on in WebLogic's startup - just after
the file logger, as failure of the realm means that WebLogic shouldn't boot and
certainly shouldn't create any resources.

Using raw JDBC at this stage is just fine, but attempting to use Connection pools
etc... won't work because the relevent subsystems aren't available - it's a booting
thing - for instance a JDBC Connection pool is guarded by an ACL, so the security
subsystem must be available to test the ACL for creation rights and so forth.

Use raw JDBC and you'll be fine.

simon.