After debugging, it seems the sun internal classes of JNDI uses the Thread.contextclassloader for finding "jndi.properties".
The MBean that makes the jndi.lookup has a UnifiedClassLoader whose description is url=file:/opt/jboss-3.0.4_tomcat-4.1.12/server/jboss1/tmp/deploy/server/jboss1/deploy/spi-service.xml/101.spi-service.xml
Note that the test is directly done is the MBean's constructor. and the MBean has no jboss specific interface (i.e not ServiceMBean...).
the spi-service.xml is <?xml version="1.0" encoding="UTF-8"?>
However the mbean.class.getClassLoader() is relative to SpiLoader.jar. If i add jndi.properties in the SpiLoader.jar (instead of Spi.jar), classloader.getResources("jndi.properties") returns the url.
Why doesn't the threadcontextclassloader.getResources("jndi.properties") find the resource ?
Because there is a jndi.properties in server/jboss1/conf
and this has already been loaded by the naming service.
If you create a sar it will look locally in the
sar before searching the UnifiedLoaderRepository.
Is there a reason why you cannot add the config to
jndi.properties in conf, other than you can't hot deploy
the jars because they need to be in server/jboss1/lib?