Bug 1060275

I think that the problem is that during startup the new version of the jboss-as-naming package is registering an InitialContextFactoryBuilder class that ignores the Context.INITIAL_CONTEXT_FACTORY property given by the user. In our case we use com.sun.jndi.ldap.LdapCtxFactory, and expect to get back an instance of com.sun.jndi.ldap.LdapCtx, but instead of that we get a org.jboss.as.naming.InitialContext, and then we fail when invoking LDAP specific methods like getRequestControls.

The version of the failing package is +7.3.1-1.Final_redhat_1.1.ep6.el6.

There is a similar issue reported for WildFly:

https://issues.jboss.org/browse/WFLY-2319

I think that we need the fix for this issue backported to EAP 6.2.1.

This is the commit which I think fixes the issue:

https://github.com/wildfly/wildfly/commit/706b602c0db6062a285d2aad73a76652c90be98d

(In reply to Juan Hernández from comment #1)
> I think that the problem is that during startup the new version of the
> jboss-as-naming package is registering an InitialContextFactoryBuilder class
> that ignores the Context.INITIAL_CONTEXT_FACTORY property given by the user.
> In our case we use com.sun.jndi.ldap.LdapCtxFactory, and expect to get back
> an instance of com.sun.jndi.ldap.LdapCtx, but instead of that we get a
> org.jboss.as.naming.InitialContext, and then we fail when invoking LDAP
> specific methods like getRequestControls.
> 
> The version of the failing package is +7.3.1-1.Final_redhat_1.1.ep6.el6.
> 
> There is a similar issue reported for WildFly:
> 
> https://issues.jboss.org/browse/WFLY-2319
> 
> I think that we need the fix for this issue backported to EAP 6.2.1.

(In reply to Juan Hernández from comment #2)
> This is the commit which I think fixes the issue:
> 
> https://github.com/wildfly/wildfly/commit/
> 706b602c0db6062a285d2aad73a76652c90be98d

That commit already is in EAP.

That is right, this commit is included in EAP already, and isn't the solution, it is probably problem. What we get now creating the initial context is always an instance of org.jboss.as.naming.InitialContext, which extends javax.naming.directory.InitialDirContext, not javax.naming.ldap.LdapInitialDirContext, thus it doesn't have the LDAP specific methods like getRequestControls.

It can be reproduced running the following JSP:

<%@ page contentType="text/plain" %>

<%@ page import="java.util.*" %>
<%@ page import="javax.naming.*" %>
<%@ page import="javax.naming.directory.*" %>
<%@ page import="javax.naming.ldap.*" %>

<%
    Hashtable<String, String> env = new Hashtable();
    Control[] controls = new Control[0];
    LdapContext ctx = new InitialLdapContext(env, controls);
    out.println(ctx.getRequestControls());
%>

The result is the following exception:

javax.naming.NotContextException: Not an instance of LdapContext
	javax.naming.ldap.InitialLdapContext.getDefaultLdapInitCtx(InitialLdapContext.java:171)
	javax.naming.ldap.InitialLdapContext.getRequestControls(InitialLdapContext.java:205)
	org.apache.jsp.test_jsp._jspService(test_jsp.java:69)
	org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:69)
	javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
	org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:365)
	org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:309)
	org.apache.jasper.servlet.JspServlet.service(JspServlet.java:242)
	javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

Did tou try that code outside of EAP? If you did that and it works please attach a project that builds a war and I can use to replicate the issue, otherwise please point me to the specific code that originated this issue.

Created attachment 858496 [details]
Test web application that reproduces the problem

Created attachment 858497 [details]
Source for the test web application that reproduces the problem

I have attached an test application that reproduces the problem. It is a simple web application with a servlet that connects to a LDAP server and tries to use one of the LDAP specific methods of the context. It fails with the following exception when running under EAP with jboss-as-naming-7.3.1-1.Final_redhat_1.1.ep6.el6:

2014-02-03 11:48:56,191 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/test].[Test]] (ajp-/127.0.0.1:8702-1) JBWEB000236: Servlet.service() for servlet Test threw exception: javax.naming.NotContextException: Not an instance of LdapContext
        at javax.naming.ldap.InitialLdapContext.getDefaultLdapInitCtx(InitialLdapContext.java:171) [rt.jar:1.7.0_51]
        at javax.naming.ldap.InitialLdapContext.getRequestControls(InitialLdapContext.java:205) [rt.jar:1.7.0_51]
        at com.example.TestServlet.doGet(TestServlet.java:29) [classes:]
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) [jboss-servlet-api_3.0_spec.jar:1.0.2.Final-redhat-1]
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec.jar:1.0.2.Final-redhat-1]
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb.jar:7.3.0.Final-redhat-1]
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb.jar:7.3.0.Final-redhat-1]
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) [jbossweb.jar:7.3.0.Final-redhat-1]
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb.jar:7.3.0.Final-redhat-1]
        at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web.jar:7.3.1.Final-redhat-1]
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb.jar:7.3.0.Final-redhat-1]
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb.jar:7.3.0.Final-redhat-1]
        at org.jboss.web.rewrite.RewriteValve.invoke(RewriteValve.java:466) [jbossweb.jar:7.3.0.Final-redhat-1]
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb.jar:7.3.0.Final-redhat-1]
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) [jbossweb.jar:7.3.0.Final-redhat-1]
        at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:488) [jbossweb.jar:7.3.0.Final-redhat-1]
        at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:420) [jbossweb.jar:7.3.0.Final-redhat-1]
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920) [jbossweb.jar:7.3.0.Final-redhat-1]
        at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]

It works fine when deployed and executed in Tomcat 7.0.50, for example.

Note that the servlet tries to connect to LDAP server "fedora.example.com". In order to test you will need to replace that with an LDAP server that you can access and rebuild, or just add an entry in your /etc/hosts file pointing to a correct LDAP server with that name.

Please point me the way for a valid LDAP server, which validates the code attached.

Issue confirmed, looking for a fix...

Verified on EAP 6.3.0.DR1. Regression test org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase in AS TS passes.