OSGi Spring com.sun.jndi.ldap.LdapCtxFactory ClassNotFound?

[Andy Brook [Plugin People]]

I'm trying to adopt spring-ldap for LDAP lookup to save time and reduce bloat code I have to maintain, all good reasons. OSGi appears to be complicating things (surprise!)

Reusing the 1.3.0.RELEASE via provided scope in pom.xml doesn't appear to work (even though I can see it listed in felix as a bundle) due to 'Caused by: java.lang.ClassNotFoundException: org.springframework.ldap.core.ContextSource', currently I have a compile dependency on it, which is working for class resolution.

In simple coded usage I'm not able to create a new LdapContextSource(); the creation fails because of: java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory

Eh? I would have thought JRE classes would all be available to the OSGi container? So, either spring is defaulting to that value and is trying to do a Class.forName() -- and fails, or is actually getting the JRE injected default value for the initial context factory 'name', but cant load the class -- and fails.

I have tried the try/catch/finally ContextClassLoader switch (without success) using:

- ContainerManager.getClass().getClassLoader()

- ClassLoader.getSystemClassLoader()

I saw this post on stack overflow which seemed to indicate that the felix OSGI container may be able to delegate to JRE specific classes, I wonder if that is applicable here?

I've looked through JIRA/Crowd code but don't see anything helpful. I'm sure this is a problem that has been addressed. Any pointers are appreciated.

Anyone used spring-ldap in a plugins2 deployment? Surely I don't have to bundle com.sun classes in a plugin?

For this case do I have to resort to hand coding?

[Joe Clark · Accepted solution]

Andy and I had a quick chat about this at AtlasCamp - I'm able to reproduce the same problem quite easily. It appears that JIRA is not exposing Spring-LDAP and com.sun.jndi.ldap.* to the OSGi container for some reason. The same code runs perfectly fine in Confluence (go Confluence!)

At this point it seems that the answer is either:

a) Go down the painstaking and error-prone route of trying to bundle only the bits that you need in your plugin (and avoiding classloader clashes)

b) See if we can get JIRA to include Spring-LDAP in the OSGi system bundle.

I'll chase up Option B with the JIRA team when I'm back in Sydney :-)

[Mathias Edblom]

Andy,

I'm having the same type of error when using the new Scheduler API from JIRA 6.3. When making ordinary request to the functionality it works fine, but when initiating from the Scheduler API I'll get:

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

Do you have a tip about this? Cheers //M

[Mathias Edblom]

I managed to solve it by putting in all necessary classes in the plugin classpath. The important ones was in the JRE.

[Andy Brook]

Uh, packacking com.sun classes in your addon isn't a reliable solution as customers may choose their own JRE (OK, its technically possible ;)

[Mathias Edblom]

I know, thats a not a good solution and I'll think I have an other problem as well. But if I don't include the classes everything works fine outside the Scheduler API but when initiating from the new Scheduler API it fails due to the above error. With the depricated PluginScheduler it worked fine...

[Mathias Edblom]

It seems like running from the Schedule API, I can't find the com.sun.* classes thats in the rt.jar within the JRE. How can that be possible? By putting them in, I'm able to access them but I don't wont to, and shouldn't have to. Any idées?

[Andy Brook]

It wont work because com.sun classes are not loaded by the OSGI container so they arent available to components, even if the JRE has them (thats what this thread is about).Bottom line, you can't use spring ldaptemplate (though, you never said you did, but thats how I hit this)

[Mathias Edblom]

Ok, I haven't used the spring library, just ordanary Java LDAP classes. But regardless of that, they all seems to use the com.sun.jndi.ldap.LdapCtxFactory. Is there some LDAP library that doesn't use this classes that you know of? Thanks //M

[Andy Brook]

new InitialDirContext(env) #worksforme ?

addon does _not_ import/export named packages...

[Mathias Edblom]

It doesn't work from the new Scheduler API JIRA 6.3, works good when just using it within the plugin requested from an REST API for instance.

What do you have in your env hashtable?

[Mathias Edblom]

New info, it doesn't work even in the depreceted PluginScheduler in JIRA 6.3, it's the JIRA version that is the difference. Before JIRA 6.3, it worked fine, in JIRA 6.3 the scheduler doesn't work with com.sun classes, neither in the new Scheduler API or the old PluginScheduler.

And again, using the same components from an REST-API it works fine, even in JIRA 6.3

[Andreas Ebert]

Thanks for the hint about JIRA 6.3. I successfully applied the work-around discussed in JRA-29896. Maybe it will also work for you.

[Mathias Edblom]

Yes, I'll manage to do a classloader work around as well, discussed here: https://answers.atlassian.com/questions/322950/i-have-a-problem-with-the-new-scheduler-api-and-ldap/323902

[Andy Brook [Plugin People]]

Hi Joseph,

Re #2, the spring stuff is already available, thr problem is the dynamically loaded JRE implementation which isnt, so B I think won't help.

So I had a chat with Andreas in my 1on1 today, we tried just adding in that com.sun.* package but it didnt seem fix it. In any case, the change would be significant and impact every JIRA plugin, and in addition, it also needs to cater for different JRE native implmentations (eg IBM runtime, <cough>openjdk</cough>), likely this is not going to happen soon. Is someone raising a JIRA for this?

In addition to the options you mention, another (which I think is best in this scenario) is to write a p1 plugin that exposes a programmaticly LdapTemplate (through the p1 model and therefore classloader, avoiding this problem), then import that from p2. Its a pain to deploy two plugins until a point that JIRA fixes that but I dont see any other choice at the moment

[Andy Brook [Plugin People]]

I just got notified that JRA-29896 was closed as a won't fix, but Im not giving up yet.

[Joe Clark]

Sorry, it got triaged by the bug-fix team before I had a chance to talk to anyone in JIRA about it. I'll chase it up tomorrow. :-)

[Andy Brook [Plugin People]]

Just to tie off this issue, the official line is that this is never going to be fixed, if you want to use LDAP then you have to roll your own code, using LdapTemplate from a p2 plugin is not going to be possible, but other spring components that dont require JRE native classes will work fine, probably.

[Andy Brook [Plugin People]]

Not yet. This is something I'll be trying to resolve @Atlascamp

[Benedikt Bjarni Bogason [Tempo]]

Hi Andy,

Any update on this? Have you managed to solve this? Curios, because I am facing similar problem.