Re: JNDI searches
Roedy Green wrote:
On Thu, 08 Apr 2010 09:03:56 -0400, Tim Slattery <Slattery_T@bls.gov>
wrote, quoted or indirectly quoted someone who said :
This seems completely nuts to me. Am I missing a way around this, or
am I doomed to recompile and/or add searches on more and more variants
of the JNDI name?
Hold your nose for this one. It smells of very old C++ code.
Poke around in System.properties to see if you can find something that
will tell you which womb you are using. Then write a method that does
your JNDI given a magic string.
We had a similar problem, and went with a solution similar to what Roedy
suggests - finding out which womb we are in. We had to port our
application to Websphere and Tomcat. For Tomcat, we instantiate
InitialContext by calling the zero argument constructor, while in
WebSphere we need to pass a Properties object with a key-value pair of
Context.INITIAL_CONTEXT_FACTORY==>"com.ibm.websphere.naming.WsnInitialContextFactory"
So, here's what we did. We tried to get the initial context object using
the WebSphere method, but if that failed, we assumed we were in Tomcat
and called the zero argument constructor and attached the prefix.
Here's the relevant piece of code:
java.util.Properties parms = new java.util.Properties();
// Assume WebSphere
parms.setProperty(Context.INITIAL_CONTEXT_FACTORY,
"com.ibm.websphere.naming.WsnInitialContextFactory");
try{
// Get initial context object
initCtx = new InitialContext(parms);
}catch(Exception c){
// Exception, so we are in Tomcat
initCtx = new InitialContext();
initCtx = (Context) initCtx.lookup("java:comp/env");
}
this.datasource = (DataSource) initCtx.lookup(dbDataSource);
If there isn't anything, invent something. Possible tools:
System.properties, SET environment, hide something in the persistence
mechanism, loading a small XML config file, loading some
tweaking/customisation code via Class.forName.
This last one it what I use for my own static macros to load dozens of
custom parameters and custom methods in one fell swoop.