Jörg Hoh created SLING-3525:
-------------------------------
Summary: Launchpad notification thread cannot access JNDI
ressources on Websphere
Key: SLING-3525
URL: https://issues.apache.org/jira/browse/SLING-3525
Project: Sling
Issue Type: Improvement
Components: Launchpad
Affects Versions: Launchpad Base 2.5.0
Environment: Websphere 7 on Linux
Reporter: Jörg Hoh
We have an existing JavaEnterprise-based application, which we want to move
into sling running on IBM Websphere appserver. In some of the resulting bundles
we need to access JNDI resources.
We get this exception:
{code}
[29.04.14 03:14:01:790 CEST] FFDC
Exception:javax.naming.ConfigurationException
SourceId:com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS
ProbeId:440 Reporter:java.lang.Class@5ef85ef8
javax.naming.ConfigurationException: 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. [Root exception is
javax.naming.NameNotFoundException: Name comp/env/tm not found in context
"java:".]
at
com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS(javaURLContextImpl.java:428)
at
com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:399)
at
com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:221)
at
com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:161)
at javax.naming.InitialContext.lookup(InitialContext.java:436)
...
at
org.apache.sling.launchpad.webapp.SlingServlet.startSling(SlingServlet.java:384)
at
org.apache.sling.launchpad.webapp.SlingServlet.updated(SlingServlet.java:262)
at
org.apache.sling.launchpad.base.impl.SlingFelix$Notifier.run(SlingFelix.java:172)
at java.lang.Thread.run(Thread.java:761)
Caused by: javax.naming.NameNotFoundException: Name comp/env/tm not found in
context "java:".
at
com.ibm.ws.naming.ipbase.NameSpace.getParentCtxInternal(NameSpace.java:1837)
at
com.ibm.ws.naming.ipbase.NameSpace.lookupInternal(NameSpace.java:1166)
at com.ibm.ws.naming.ipbase.NameSpace.lookup(NameSpace.java:1095)
at
com.ibm.ws.naming.urlbase.UrlContextImpl.lookup(UrlContextImpl.java:1235)
at
com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:395)
... 60 more
{code}
According to the JavaEnterprise spec, you should not create threads on your own
but use the mechanisms of the appserver (mostly because of the massive use of
threadlocals to access JDNI and stuff like that). See
http://stackoverflow.com/questions/533783/why-spawning-threads-in-java-ee-container-is-discouraged
for some discussion of it.
We would like the Launchpad to use a "native Websphere thread" so it can
actually do JNDI lookups, and not to create a new thread "on the fly".
We would like to avoid any change to the way how JNDI resources are looked up
in our application.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
