We Keep Coding

Root exception is javax.naming.NameNotFoundException: Name jdbc not found in context "java:comp/env"

I am working on a Java Web Application, and is getting deployed in Websphere Application Server,
I have a class Database.java, which is returning the JDBC Connection with DB2 Database,
jndiName = "jdbc/TestDataSource";
Context ctx = new InitialContext();
envContext = (Context) ctx.lookup("java:comp/env");
javax.sql.DataSource ds = (javax.sql.DataSource) envContext.lookup(jndiName);
conn = ds.getConnection();
and in other classes where am performing operations am creating an object of Database.java class and get the connection and did the jdbc operations, so far it was working fine, but in latest development I have to introduce a thread in servlet class, so the other classes which are doing the operations are running in thread in background and returned the control to servlet immediately. But after implementing this application crashed in Websphere Application Server with below mentioned error, but surprisingly its working perfectly fine Tomcat server.
PFB the Web.xml
<resource-ref>
<description>Connection-ConnectionPool</description>
<res-ref-name>jdbc/TestDataSource</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
<mapped-name>jdbc/TestDataSource</mapped-name>
</resource-ref>
Error:
000000e9 SystemOut O Error in NamingException - Database.getConnection(datasource) :- javax.naming.ConfigurationException: A JNDI operation on a "java:" name cannot be completed because the server runtime is not able to associate the operations thread with any J2EE application component. This condition can occur when the JNDI client using the "java:" name is not executed on the thread of a server application request. Make sure that a J2EE application does not execute JNDI operations on "java:" names within static code blocks or in threads created by that J2EE application. Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on "java:" names. [Root exception is javax.naming.NameNotFoundException: Name jdbc not found in context "java:comp/env".]

The exception means that the thread which you created doesn't have the context of the Java EE application and thus it cannot know which Java EE component namespace to get java:comp/env/jdbc/TestDataSource from. Note that you can define this same name to mean different things for different Java EE apps/components. There is an easy way around this, which follows Java EE spec standards. Instead of creating your own threads, use a ManagedExecutorService (also part of Java EE) that automatically propagates your application's context to a managed thread, in which case the app server will be able to resolve the lookup properly.
Here is an example:
ExecutorService executor = InitialContext.doLookup("java:comp/DefaultManagedExecutorService");
executor.submit(new Callable<Object>() {
public Object call() throws Exception {
DataSource ds = InitialContext.doLookup("java:comp/env/jdbc/TestDataSource");
Connection conn = ds.getConnection();
try {
// ... do useful stuff with connection
} finally {
conn.close();
}
return result;
}
});

JNDI Lookup exception

I have created a dynamic web project in WAS 7.0.0.25. I have configured datasource as jdbc/DWLConfig in the WAS. I am trying to lookup this datasource in the servlet from the web project i have created.
if i give java:comp/env/jdbc/DWLConfig, it is giving me NameNotFoundException. But if i give jdbc/DWLConfig, then it is working fine.
Actually, from the servlet, i am calling another project which i dont have access to edit, always looks like java:comp/env/jdbc/DWLConfig. So it is throwing exception for me.
Do i need to add any reference in the web project which i have created.?

The problem might be related to the base JNDI. You will notice why it is not working from the following example:
Context initCtx = new InitialContext();
Context envCtx = (Context) initCtx.lookup("java:comp/env");
// Right
DataSource ds = (DataSource) envCtx.lookup("jdbc/DWLConfig");
// Wrong. because base JNDI already created.
DataSource ds = (DataSource) envCtx.lookup("java:comp/env/jdbc/DWLConfig");

Getting NullPointerException when running simple JMS

Am trying to run a simple JMS app, sadly got NullPointException . following are the links to the files of the app :
1. Producer.java
2. SynchConsumer.java
Tools used : Eclipse & GlassFish
following is the exception
Exception in thread "main" java.lang.NullPointerException
at coreservlets.Producer.main(Producer.java:96)
Any flash put into this shall be appreciated .

If you run your stand-alone application without any container around it, the #Resource injections will not work. Instead you have to do manual JNDI lookups for both the connection factory and the queue/topic:
Example:
final Properties initialContextProperties = new Properties();
final String factory = "jms/ConnectionFactory";
final String queueName = "jms/Queue";
//
final InitialContext ic = new InitialContext(initialContextProperties);
final QueueConnectionFactory qcf = (QueueConnectionFactory) ic
.lookup(factory);
final Queue queue = (Queue) ic.lookup(queueName);
As for the configuration of the InitialContext, look here: Glassfish V3.x and remote standalone client

connectionFactory.createConnection();
connectionFactory, even if static, is never initialized. For this reason it is null and you get the null pointer when you try to access the method inside it.
Two way of fixing.
If the method is static, don't declare the var, just call:
ConnectionFactory.createConnection();
If the method is not static (strange, for a class that is static), you have to do something like:
private ConnctionFactory connectionFactory = new ConnectionFactory();

comp/env/pool not found in context "java:"?

I have a web application trying to access a JNDI declared in WebSphere Application Server.
The JNDI is declared under Object pool managers. However, I'm receiving an error when I access the pool. The error says that comp/env/pool is not found in context "java:".
My code is written as follows:
InitialContext initialContext = new InitialContext();
ObjectPoolManager opm = (ObjectPoolManager)initialContext.lookup("java:comp/env/pool");
Accessing the pool via the code below works:
ObjectPoolManager opm = (ObjectPoolManager)initialContext.lookup("pool");
I'm confused because according to what I've found on the internet, java:comp/env/ is a default prefix for JNDI. So why does it cause an error in my case?
Thank you!

you can only use java:comp/env if you have declared a reference to the Object Pool in your web.xml under the resource-ref section.
See What is resource-ref in web.xml used for? for further explanation.

Java: Multiple Data Resources inside the same servlet

"javax.naming.Context" is commonly used inside Java EE development. It's quite convenient to use it to establish dynamical database connection by calling its lookup function with given names of resources inside context.xml. The sample code is shown as following where "db_name" is the name you used to identify the database resource.
Context ctx = new InitialContext();
DataSource ds = ctx.lookup("java:comp/env/jdbc/db_name");
My concern is what are the differences between lookup resources by using the same context and lookup resources by using different contexts. And which approach makes more sense or suitable? Suppose all database resources are defined inside the same context.xml file. For example:
Context ctx = new InitialContext();
DataSource ds1 = ctx.lookup("java:comp/env/jdbc/db_name_ds1");
DataSource ds2 = ctx.lookup("java:comp/env/jdbc/db_name_ds2");
and
Context ctx_ds1 = new InitialContext();
Context ctx_ds2 = new InitialContext();
DataSource ds1 = ctx_ds1.lookup("java:comp/env/jdbc/db_name_ds1");
DataSource ds2 = ctx_ds2.lookup("java:comp/env/jdbc/db_name_ds2");
Thank you for your sharing.

there is no difference except you created an unnecessary extra java object. however, if the jndi server was remote, you would have created two different network connections and iverhead of managing them - definetly not what one should do.