Chetan, for the long-term this would be an option. But atm I don't see an option to adapt our code to such a changed structure for various project-related reasons.
But nevertheless an idea, we should think about. Jörg 2014-05-13 8:34 GMT+02:00 Chetan Mehrotra (JIRA) <j...@apache.org>: > > [ > 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-discouragedfor > 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) > -- Cheers, Jörg Hoh, http://cqdump.wordpress.com Twitter: @joerghoh
