Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1060275 - [RHEV] (6.3) The upgrade of the AS from EAP 6.2.0 to 6.2.1 caused a problem in jboss-as-naming for RHEV
Summary: [RHEV] (6.3) The upgrade of the AS from EAP 6.2.0 to 6.2.1 caused a problem i...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Naming
Version: 6.2.1
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: DR0
: EAP 6.3.0
Assignee: emartins
QA Contact: Josef Cacek
URL:
Whiteboard:
Depends On:
Blocks: 1060867 1061181
TreeView+ depends on / blocked
 
Reported: 2014-01-31 16:11 UTC by Chris Pelland
Modified: 2014-06-28 15:29 UTC (History)
13 users (show)

Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1060867 1061181 (view as bug list)
Environment:
Last Closed: 2014-06-28 15:29:27 UTC
Type: Bug


Attachments (Terms of Use)
Test web application that reproduces the problem (deleted)
2014-02-03 11:02 UTC, Juan Hernández
no flags Details
Source for the test web application that reproduces the problem (deleted)
2014-02-03 11:03 UTC, Juan Hernández
no flags Details


Links
System ID Priority Status Summary Last Updated
JBoss Issue Tracker WFLY-2319 Major Resolved LDAP Search containing URL - InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given 2014-08-10 17:01:00 UTC

Description Chris Pelland 2014-01-31 16:11:27 UTC
It appears that the upgrade of the AS from EAP 6.2.0 to 6.2.1 caused a problem in jboss-as-naming for RHEV related to RHEV's LDAP use.

Requesting from the RHEV team to attached the following to this bug in order to help the EAP team troubleshoot the issue:

o The full stack trace and a pointer to the code which does the LDAP lookup.

Comment 1 Juan Hernández 2014-02-01 17:01:18 UTC
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.

Comment 2 Juan Hernández 2014-02-01 17:08:09 UTC
This is the commit which I think fixes the issue:

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

Comment 3 emartins 2014-02-02 03:58:24 UTC
(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.

Comment 4 Juan Hernández 2014-02-02 14:18:26 UTC
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)

Comment 5 emartins 2014-02-02 20:21:59 UTC
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.

Comment 6 Juan Hernández 2014-02-03 11:02:42 UTC
Created attachment 858496 [details]
Test web application that reproduces the problem

Comment 7 Juan Hernández 2014-02-03 11:03:40 UTC
Created attachment 858497 [details]
Source for the test web application that reproduces the problem

Comment 8 Juan Hernández 2014-02-03 11:10:40 UTC
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.

Comment 9 emartins 2014-02-03 11:14:37 UTC
Please point me the way for a valid LDAP server, which validates the code attached.

Comment 12 emartins 2014-02-03 14:20:06 UTC
Issue confirmed, looking for a fix...

Comment 15 Ondrej Lukas 2014-03-05 08:45:38 UTC
Verified on EAP 6.3.0.DR1. Regression test org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase in AS TS passes.


Note You need to log in before you can comment on or make changes to this bug.