[jira] [Created] (SLING-3525) Launchpad notification thread cannot access JNDI ressources on Websphere

["Jörg Hoh (JIRA)" <ji...@apache.org>]

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)