• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

JNDI lookup on a thread other than the main thread error

 
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

I'm getting this error when my application tries to lookup a JNDI on a thread created from my application's main thread.

You may check this stack trace:

2/20/07 6:46:26:406 CST] 00000084 javaURLContex E NMSV0310E: A JNDI operation on a "java:" name cannot be completed because the server runtime is not able to associate the operation's 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. Exception stack trace:
javax.naming.ConfigurationException [Root exception is javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context "java:".]
at com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS(javaURLContextImpl.java:411)
at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:388)
at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:201)
at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:142)
at javax.naming.InitialContext.lookup(InitialContext.java:363)

... more stack trace here

at java.lang.Thread.run(Thread.java:797)
Caused by: javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context "java:".
at com.ibm.ws.naming.ipbase.NameSpace.getParentCtxInternal(NameSpace.java:1767)
at com.ibm.ws.naming.ipbase.NameSpace.lookupInternal(NameSpace.java:1083)
at com.ibm.ws.naming.ipbase.NameSpace.lookup(NameSpace.java:991)
at com.ibm.ws.naming.urlbase.UrlContextImpl.lookup(UrlContextImpl.java:1263)
at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:384)

... 10 more

When I tried searching in the InfoCenter using the error key, I end up with this one:

NMSV0310E: A JNDI operation on a "java:" name cannot be completed because the server runtime is not able to associate the operation''s 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. Exception stack trace: {0}
Problem
A JNDI operation on a "java:" name must be performed on the thread of a server application request
User response
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.

Is this really the case with Websphere (just a confirmation)? The application already runs on Weblogic and Jboss AS, and were migrating it to Websphere.

Is there any other way to get workaround on this?

Any help is appreciated.

Cheers..., ayan
 
Ranch Hand
Posts: 74
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I believe you are creating your own new Thread... correct? If yes,

.....Spinning off a new Thread in container is against J2EE specification.... pl. go rant spec. for more info on this......

Only suggestion I have for you is, don't do the lookup from the thread that you spun off.... rather do your look-ups from EJB/Servlet thread which is in line with server thread.....

Don't really wanted to get into political bite here but.... would like to say one thing i.e. "If you don't care for spec. then you can do what ever you wanted to"......

Btw.... trace is very self descriptive and .... It is working in WebSphere as J2EE compliance recommends.

Cheers,
H. Kanthi
[ February 20, 2007: Message edited by: Hanumanth Kanthi ]
 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In order to avoid this scenario what changed we need to make in Code...
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The issue here is that Quartz (or what ever you might be using in this case) is executing a thread outside the control of the container (which possibly only WebSphere is concerned about - other containers may let you without complaining). The method you hooked up for Quartz to execute when your trigger is fired is now a part of this outside thread and thus you receive the following error:

"A JNDI operation on a "java:" name cannot be completed because the server runtime is not able to associate the operation's 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."

I found that all I needed to do was move the code that fetches the enviroment variables outside of the method and since I was not invoking the method from a web application, the only other place I could put it was in the constructor of the class of my method. This solved my issue and I was able to fetch the environments variables using the following code:





 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Anyone tried to configure the following property on the scheduler factory ?

org.quartz.scheduler.threadsInheritContextClassLoaderOfInitializingThread=true


I've tried without success. Still can't lookup java:comp/env ejb homes.
 
reply
    Bookmark Topic Watch Topic
  • New Topic