This is an odd one, and unfortunately, I don't have a smaller test case to demonstrate the issue. We have a project where we are using primarily autowiring of our beans; we have a top-level project consisting of our UI layer, making calls into another project which contains all the services. We recently had to switch to an LDAP authentication ... and when we did so, it became apparent that some (most?) of our beans are not being properly autowired. By stepping back & away from LDAP, I was able to show that something in our security config file was causing the issue.

By carefully going through the config, I was able to limit it to the use of the ldap-authentication-provider tag.

Our config looks something like this (I've removed some things for brevity, and of course for the security of my client); with this config, you can clearly follow the logs at DEBUG level and see autowiring of some components is not happening:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:security="http://www.springframework.org/schema/security"
xmlns:util="http://www.springframework.org/schema/util"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schem...-beans-3.0.xsd
http://www.springframework.org/schema/security
http://www.springframework.org/schem...rity-3.0.3.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util-3.0.xsd">

<security:http auto-config="true" use-expressions="true" access-denied-page="/403.jsp">
<security:intercept-url pattern="/403.jsp" access="permitAll()"/>
<security:intercept-url pattern="/404.jsp" access="permitAll()"/>
.
.
.
</security:http>

<security:ldap-server id="corpLdap" url="ldap://aServer:389/dc=corp,dc=corporate,dc=com" manager-dn="${ldap.pnet.bindDn}"
manager-password="${ldap.pnet.bindPassword}"/>
<security:ldap-server id="franLdap" url="ldap://aServer2:389/dc=Fran,dc=corporate,dc=com" manager-dn="${ldap.pnet.bindDn}"
manager-password="${ldap.pnet.bindPassword}"/>

<security:authentication-manager>
<security:ldap-authentication-provider
server-ref="corpLdap"
user-context-mapper-ref="myUserDetailsContextMapper"
user-search-base="CN=Users"
user-search-filter="(sAMAccountName={0})"
group-search-base="CN=Users"
group-search-filter="(member={0})"
group-role-attribute="CN"
role-prefix="">
</security:ldap-authentication-provider>
<security:ldap-authentication-provider
server-ref="franLdap"
user-context-mapper-ref="myUserDetailsContextMapper"
user-search-base=""
user-search-filter="(sAMAccountName={0})"
group-search-base="CN=Users"
group-search-filter="(member={0})"
group-role-attribute="CN"
role-prefix="">
</security:ldap-authentication-provider>
</security:authentication-manager>
.
.
.


If, instead of using ldap-authentication-provider, I switch to a generic authentication-provider and manually wire the ldap beans, then autowiring works:



<security:authentication-manager>
<security:authentication-provider ref="firstLdapProvider"/>
<security:authentication-provider ref="secondLdapProvider"/>
</security:authentication-manager>

<bean id="firstLdapProvider" class="org.springframework.security.ldap.authentic ation.LdapAuthenticationProvider">
<constructor-arg>
<bean class="org.springframework.security.ldap.authentic ation.BindAuthenticator">
<constructor-arg ref="aServer" />
<property name="userSearch">
<bean id="userSearch1" class="org.springframework.security.ldap.search.Fi lterBasedLdapUserSearch">
<constructor-arg index="0" value="CN=Users"/>
<constructor-arg index="1" value="(sAMAccountName={0})"/>
<constructor-arg index="2" ref="aServer" />
</bean>
</property>
</bean>
</constructor-arg>
<constructor-arg>
<bean class="org.springframework.security.ldap.userdetai ls.DefaultLdapAuthoritiesPopulator">
<constructor-arg ref="aServer" />
<constructor-arg value="CN=Users" />
<property name="groupSearchFilter" value="(member={0})"/>
<property name="groupRoleAttribute" value="CN"/>
<property name="rolePrefix" value=""/>
<property name="searchSubtree" value="true"/>
<property name="convertToUpperCase" value="true"/>
</bean>
</constructor-arg>
<property name="userDetailsContextMapper" ref="myUserDetailsContextMapper"/>
</bean>

(and likewise for the secondLdapProvider ....)


Any ideas on why the first config prevents autowiring from occurring on all the beans that it should? Some beans are autowired ... but not all (we have an inventory service bean, for example, that is clearly autowired correctly ... but other beans I'd like to use are not autowired unless we use the second config).

Bug? Something wrong in my config? I'm open to ideas ... for now, I'm up and running with the alternative (long & explicit) bean definitions. The issue appears to be similar to http://forum.springsource.org/archiv.../t-103148.html, but not quite (that one doesn't appear to be ldap-related).

Thanks!

dr_j