[
https://issues.apache.org/jira/browse/SLING-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13996135#comment-13996135
]
Chetan Mehrotra commented on SLING-3525:
----------------------------------------
Looks like you are trying to access the DataSource from JNDI. Given the various
restrictions posed by WAS around JNDI access it might be safer (and reliable)
to publish the DataSource as a service in OSGi Service Registry and have your
code access it from there.
The DataSource can be registered similar to the way MBeanServer is registered
at the time of startup [1]. or such a logic can be made part of SlingBridge. An
extension point can be provided and we can have a generic configurable
implementation which can extract various object from JNDI and publish them to
OSGi SR
[1]
https://github.com/apache/sling/blob/trunk/launchpad/base/src/main/java/org/apache/sling/launchpad/base/impl/Sling.java#L297
> 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
> Attachments: was_258f258f_14.04.29_03.14.01.7877107172171903438789
> copy.txt
>
>
> 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)
