javax.naming.NoInitialContextException: Cannot instantiate class: com.sun.jndi.ldap.LdapCtxFactory [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory]

[Bharadwaj Jannu]

Hi, 

I am trying to access Ldap directory in a plugin which creates a new schedule job , for that I added the small logic as

Hashtable<String, String> env = new Hashtable<String, String>();
//env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
env.put("java.naming.factory.initial", "com.sun.jndi.ldap.LdapCtxFactory");

in public void execute(Map<String, Object> jobDataMap) {...} method.

I built it and deployed it successfully but I got an exception when the job is executed.

The exception is:

javax.naming.NoInitialContextException: Cannot instantiate class: com.sun.jndi.ldap.LdapCtxFactory [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory]

.

.

. 

Caused by: java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory

Does this class is not available though it is a sun api class? Please suggest an alternative way to connect to ldap.

Thanks.

[crf · Accepted solution]

com.sun packages are not exported by default because they would be a JVM portability concern.  That's kind of a silly concern these days, since Atlassian will only support the Sun Oracle JDK anyway, but most OSGi platforms seem to follow this rule.  I think setting this environment variable will enable their export, but your plugin would probably also need explicit import instructions to get this to work completely, and needing the person running JIRA to add special environment variables is not a great answer, I think.

JVM_SUPPORT_RECOMMENDED_ARGS=-Datlassian.org.osgi.framework.bootdelegation=sun.*,com.sun.*

Another solution I've used in the past for this sort of problem is to deliberately switch which classloader the thread is using while I interact with whatever code is trying to use the com.sun classes.  It goes something like this:

final Thread thd = Thread.currentThread();
final ClassLoader oldTccl = thd.getContextClassLoader();
try {
    // Temporarily use the main webapp classloader
    thd.setContextClassLoader(ComponentAccessor.class.getClassLoader());
 
    // Use LDAP, Java Mail, or whatever else is running into the
    // com.sun package problem from inside here.  Make sure you
    // don't try to access any of your own plugin's classes as you
    // do that, because changing the TCCL will have made it to where
    // you cannot load them anymore.  Stick with basic data structures
    // like HashMap for collecting any results that the rest of your
    // plugin's code will need to see.
} finally {
    // Make the plugin's classloader the TCCL again
    thd.setContextClassLoader(oldTccl);
}
 
// Safe to access your own plugin's stuff, again.

[Bharadwaj Jannu]

Thank you Chris!!

I tried to access ldap through reflection and worked.

[crf]

My grammar probably wasn't clear, there.  I've edited it to make what I was saying a bit clearer.

What I was trying to say is that LDAP naming classes that you use themselves use reflection to load these classes.  You shouldn't need to use reflection for the LDAP calls to get this to work.