I have the following…
Context aContext = = new InitialContext(settings);
aContext.lookup("java:comp/env/DB2_DB");
Also tried…
aContext.lookup("DB2_DB");
web.xml
<resource-ref>
<description>
</description>
<res-ref-name>DB2_DB</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Application</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
<mapped-name>DB2_DB</mapped-name>
</resource-ref>
then in my ibm-web-bnd.xml…
<resource-ref name="DB2_DB" binding-name="jdbc/DB2DB" />
In Websphere I see the binding name in resources>JDBC>Data Sources
But when I run my application I see…
Caused by: javax.naming.NameNotFoundException: Context: Node04Cell/nodes/Node04/servers/server1, name: DB2_DB: First component in name DB2_DB not found. [Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]^M
This is a port project from WAS6-8.5
Best Answer
Well, this question is quite old, and I see that there's no accepted answer yet, so.
Here is what really happens:
java:comp/env/DB2_DB
.ibm-web-bnd.xml
) to "translate" the application bindingDB2_DB
into a real name in the WebSphere JNDI tree (jdbc/DB2DB
).jdbc/DB2DB
and returning it to the caller.You are getting a
NameNotFoundException
on the first lookup - the lookup ofjava:comp/env/DB2_DB
. The problem is not with findingjdbc/DB2DB
; it's with findingDB2_DB
inside your component's environment.Your deployment descriptor looks OK to me, so I'm guessing that the reason for your problem is this:
You are constructing an
InitialContext
instance by providing aHashtable
. TheHashtable
is often useful when you need to provide special parameters for the construction, but you must know when to use it and when to avoid it. Code that runs inside a JavaEE container and needs simple access to the container's JNDI tree rarely, if ever, should provide anyHashtable
to theInitialContext
constructor.I wouldn't be surprised if those
settings
that you're passing intoInitialContext
contain, for example, aPROVIDER_URL
key instructing the lookup to happen on some distant foreign JNDI tree.So, I would start by scrapping that parameter:
And then give it another shot.
If that still fails, use WebSphere's
dumpNamespace
utility to get a clear picture of WebSphere's JNDI tree.