Hi,
I have a problem using LDAP under Glassfish v3 (open source). Apparently, when our LDAP client tries to search for the user information an exception is thrown.
However, the exact same code works well under Tomcat.
To illustrate the fact that this is not a problem in the LDAP client (or at least, doesn't seem to be), I created a simple war with a JSP file that calls the same method the LDAP client calls. The JSP (which consist only of JRE code) runs well under Tomcat, but fails in Glassfish. The exception that is thrown is:
javax.naming.InvalidNameException: ldap:: [LDAP: error code 34 - Invalid DN]; remaining name 'ldap://16.55.249.190:63379/ou%3Dscranton%2Cdc%3Ddunder%2Cdc%3DMifflin'
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2979)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2794)
at com.sun.jndi.ldap.LdapCtx.c_lookup(LdapCtx.java:1011)
at com.sun.jndi.toolkit.ctx.ComponentContext.c_resolveIntermediate_nns(ComponentContext.java:152)
at com.sun.jndi.toolkit.ctx.AtomicContext.c_resolveIntermediate_nns(AtomicContext.java:342)
at com.sun.jndi.toolkit.ctx.ComponentContext.p_resolveIntermediate(ComponentContext.java:423)
at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:360)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:338)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:321)
at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:248)
at org.apache.jsp.test_jsp._jspService(test_jsp.java from :83)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:406)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:483)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:373)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1523)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:85)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:185)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:332)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:233)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:165)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
at java.lang.Thread.run(Thread.java:619)
(the war is attached)
I did some digging and found out why Glassfish is behaving differently than Tomcat.
As you can see in the stack trace, the JSP calls the method:
[b]InitialDirContext.search(String name, String filter, SearchControls cons)[/b]
which calls: [b]InitialDirContext.getURLOrDefaultInitDirCtx(String name)[/b]
which calls: [b]InitialContext.getURLOrDefaultInitCtx(String name)[/b]
which calls: [b]NamingManager.hasInitialContextFactoryBuilder[/b]
Here lies the difference:
[u]Under Tomcat[/u] [b]NamingManager.hasInitialContextFactoryBuilder[/b] returns false. Consequently, the following code is run:
String scheme = getURLScheme(name);
if (scheme != null) {
Context ctx = NamingManager.getURLContext(scheme, myProps);
if (ctx != null) {
return ctx;
}
}
A new context is created as an object of the class: [b]ldapURLContext[/b]. From here on the code works well and the user is successfully authenticated (in our LDAP client)
[u]Under Glassfish[/u], however, [b]NamingManager.hasInitialContextFactoryBuilder[/b] returns true (because it has an initial context factory builder – GlassFishNamingBuilder). Consequently, [b]IniticalContext.getDefaultInitCtx()[/b] is called, which returns an object of the class [b]LdapCtx[/b]. Then (as you can see in the stack trace), instead of [b]ldapURLContext[/b] an object of the class [b]PartialCompositeDirContext[/b] is used to process the request. For some reason, this flow fails with the exception above.
Why does this happen? Is this a bug in Glassfish, or is there a problem with the method call? Is there a workaround?
Thanks,
Ifat
[Message sent by forum member 'ifatgv']
http://forums.java.net/jive/thread.jspa?messageID=470047