Plugin broken in Headless Client but works in Smart Client

[jgarfield]

We're developing an Active Directory/LDAP plugin using spring/spring-ldap/spring-security for testing credentials.

It works fine in Smart Client, however when we try and use the plugin in a Headless Client context (e.g. REST authentication for Servoy Mobile) it fails.

The failure being logged is

Code: Select all

com.sun.jndi.ldap.LdapCtx cannot be cast to org.springframework.ldap.core.DirContextOperations

Relevant Stack Trace

Code: Select all

org.springframework.ldap.core.LdapEntryIdentificationContextMapper.mapFromContext(LdapEntryIdentificationContextMapper.java:30),
org.springframework.ldap.core.LdapEntryIdentificationContextMapper.mapFromContext(LdapEntryIdentificationContextMapper.java:27),
org.springframework.ldap.core.ContextMapperCallbackHandler.getObjectFromNameClassPair(ContextMapperCallbackHandler.java:69),
org.springframework.ldap.core.CollectingNameClassPairCallbackHandler.handleNameClassPair(CollectingNameClassPairCallbackHandler.java:50),
org.springframework.ldap.core.LdapTemplate.search(LdapTemplate.java:367),
org.springframework.ldap.core.LdapTemplate.search(LdapTemplate.java:309),
org.springframework.ldap.core.LdapTemplate.search(LdapTemplate.java:642),
org.springframework.ldap.core.LdapTemplate.search(LdapTemplate.java:578),
org.springframework.ldap.core.LdapTemplate.authenticate(LdapTemplate.java:1441),
org.springframework.ldap.core.LdapTemplate.authenticate(LdapTemplate.java:1426),
org.springframework.ldap.core.LdapTemplate.authenticate(LdapTemplate.java:1369)

Some basic internet research claims this is generally due to a ClassLoader issue, and I'm inclined to agree.

That being said I'm unsure of how to go about resolving this issue, not being entirely comfortable on the subject of ClassLoaders interactions in the Headless Client environment.

Source: https://bitbucket.org/adblocks/authenticator

Bonus: Apache Licence, so free LDAP/AD for everyone if this works

[jcompagner]

maybe in a tomcat environment the context is already a bit different and somehow it is a bit different instantiated.

and somehow it hits on a ldap implementation of java it self.

But it could be a problem with classloading, in the smart client all the plugin jars are really included in the main classloader of the servoy main application itself
But on the application server those are loaded into a separate classloader that the system or main classloader doesn't directly see itself.

you could try to add most of those jars to the main classloader (by altering the servoy_server.bat file and add your jar to that other list of jars) to see if that helps.

[jgarfield]

So, adding the plugin dependency jars to the servoy_server.bat (if you are for some reason serving directly from the bat) or to wrapper.conf (for service setups) works.

This doesn't really strike me as something we should need to be doing just to deploy a plugin though.

What I find most interesting is this is a 'server-side' plugin to begin with (i.e. the exposed plugin is just an RMI interface to the actual service), and we've deployed other plugins like this in the past without experiencing this issue.

Is there any way to get this same functionality by either changing how the plugin jar is produced, or by some form or ClassLoader redirection in the plugin code?

Edit: I'm playing around with trying to get the classes to load via Class-Path in the manifest file, but having no luck so far in that it seems like the jarsigner may be removing the Class-Path attribute...

[jcompagner]

no this will all not work i think. not in the current setup

Your plugin depends (or at least maybe a support jar) that it is on the system (or the same as the full app) classpath (so that it can override something)

In a application server this does not happen because the plugins (and beans) are loaded by 1 classloader. Maybe somehow some register method needs to be called or a right classloader has to be set when doing an init but this needs to be investigated then.

[Providence1]

Do we know what the status of this issue is? I'm dying to use this plugin. Here is the error that I'm getting on the server:

2015-03-04 11:33 pool-4-thread-665 WARN org.springframework.security.core.SpringSecurityMessageSource ResourceBundle [org.springframework.security.messages] not found for MessageSource: Can't find bundle for base name org.springframework.security.messages, locale en_US

Thanks!

[jcompagner]

it just seems that it can't load a resource bundle (i18n messages most of the time)

no idea why that happens, i guess you can try to do it in a WAR deploy and make sure that all the support libs are copied over to the WEB-INF/lib (instead of /plugins/xxx )

you just have to set it up differently

[Harjo]

Hi James,

is there any plugin jar? or jnlp somewhere, where I could test/try this plugin?
What about putting it up on ServoyForge?

[jgarfield]

Harjo--

I've attached The authenticator.jar file and you can download the dependencies at the associated repoistory
https://bitbucket.org/adblocks/authenti ... /downloads

We're up for posting it on ServoyForge but the last time I tried to do that it didn't seem like they supported git, so I didn't get very far.

[Harjo]

oke thanks,

do you, maybe have a jnlp for me?

[deezzub]

We're up for posting it on ServoyForge but the last time I tried to do that it didn't seem like they supported git, so I didn't get very far.

Defect #834: ServoyForge should also provide Git as version control system.