[davidwery]

Thanks for the jar Yuan. I've put it in the naming module and now spring-security on LDAP is working fine.

Hope this fix will be integrated soon in the distribution release of JBoss (or is it a problem with spring security itself ?).

David

[davidwery]

I've create a small application to reproduce the problem. You can download it at https://issues.jboss.org/secure/attachment/12348821/springldap-jbossas7.tgz

[oourfali]

Any progress in fixing this problem?

[johnbailey]

I will be digging into this.  The fix of commenting out the ObjectFactoryBuilder is not valid.  It will fix this issue, but cause several more. 

[johnbailey]

I am not able to reproduce this in the latest AS7 build.  Is anyone still having the issue with the latest AS7?

[alllle]

I was having another naming lookup issue whose root cause is this one. In my case, I'm using another version of jbossall-client.jar file to access a remote JNDI (of an earlier version of JBoss).

What happened is that the new JBoss 7 NamingContext has this static init code segment that sets the ObjectFactoryBuilder during the initialization of the naming module. Later on, my code does a lookup, all fine till the code calls the NamingManager.getObjectInstance() method. This method has this code segment:

{code}
ObjectFactoryBuilder builder = getObjectFactoryBuilder();
if (builder != null) {
    // builder must return non-null factory
    factory = builder.createObjectFactory(refInfo, environment);
    return factory.getObjectInstance(refInfo, name, nameCtx,
    environment);
}
{code}

In this case, the builder is the one set by the JBoss AS 7 earlier at the init time of the NamingContext class, which attaches the ObjectFactoryBuilder as well as the InitialContextFactoryBuilder to AS 7 specific implementation and effectively prohbit them to be set to something else later on. And this AS 7 ObjectFactoryBuilder fails to create the object instance for my remote lookup and returns null.

I think simply disable the static block as described earlier is not correct, but apparently the real fix requires some insight of JB7 in order to ensure it does not break the JB7 code.