I have created a custom SSLSocketFactory class and set it as below
ldapEnv.put(Context.SECURITY_PROTOCOL, \"ssl\");
ldapEnv.put(FACTORY_SOCKET, socketFactory
Seems this issue could be due to JNDI's dependence on setting the correct thread context classloader (which admin might not be doing), this is required because JNDI classes are loaded by a class loader at the base of the loader heirarchy and that classloader will not find the classes loaded by application/container class loader. So JNDI provides a hook to load such classes via the thread context class loader.
See if this works,
// Save the current thread context class loader
ClassLoader currentCL = Thread.currentThread().getContextClassLoader();
// Set the context class loader to the one we know for sure loaded classes inside configstore-core.jar
Thread.currentThread().setContextClassLoader(OmParticipant.class.getClassLoader());
// Invoke the jndi related code that will internally try to load our socket factory impl
...
//restore the original class loader
Thread.currentThread().setContextClassLoader(currentCL );
It's been a very long time since I posted this question. Since this post doesn't have any answers and also seems to be getting some views, I thought I could share what I did then to resolve it finally (I had already posted this in comments section of the question years ago).
I was able to resolve this issue by including that jar file in boot loader class path using -Xbootclasspath/a:
option. But I didn't like this solution anyway.