ensure context classloader is the one of your application. You can set it on Thread instances
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> 2015-08-26 4:51 GMT+02:00 dorwin <[email protected]>: > Hi, Romain > > Thank you for the previous answer. I was able to create a service locator > and use it to get around some of the JNDI issues. However, we still have > some code out of our control that creates its own thread. When it does this > it looks like the JNDI context it gets has a lot of entries in > java:/comp/Resources, but nothing else. > I found this out by stopping a debugger after a NameNotFoundException and > evaluating > > Thread.currentThread().getContextClassloader("xxxx.JNDILister").newInstance().listAll("java:") > > Is there anything I can do to get access to jndi in this unmanaged thread? > (I'm assuming the thread is the reason the JNDI tree is empty) > > I'm using an ear file. This ear file contains a startup singleton ejb that > class loads a bunch of mbeans and registers them. Each of these mbeans does > some jndi lookups. This one in particular, though, spawns a thread. Classes > from many of the modules in the ear will later lookup the mbeans as > services. > > > > > -- > View this message in context: > http://tomee-openejb.979440.n4.nabble.com/JNDI-woes-tp4675799p4675967.html > Sent from the TomEE Users mailing list archive at Nabble.com. >
