I've prepared a demonstration for this case:

1) checkout https://github.com/stsypanov/spring-boot-ldap-issue 2) run LimitTest

Test fails with NoSuchBeanDefinitionException and this explanation:

Description:

Parameter 0 of method ldapTemplate in com.luxoft.logeek.AppConfig required a bean of type 'org.springframework.ldap.core.LdapTemplate' that could not be found.
    - Bean method 'ldapTemplate' not loaded because @ConditionalOnClass did not find required class 'org.springframework.data.ldap.repository.LdapRepository'

Here SB suggests to add dependency on 'org.springframework.data.ldap.repository.LdapRepository' which in fact means to add spring-boot-starter-data-ldap.

Looking closer it turns out that LdapTemplate is declared in LdapDataAutoConfiguration:

@Configuration
@ConditionalOnClass({LdapContext.class, LdapRepository.class})
@AutoConfigureAfter({LdapAutoConfiguration.class})
public class LdapDataAutoConfiguration {
    public LdapDataAutoConfiguration() {
    }

    @Bean
    @ConditionalOnMissingBean({LdapOperations.class})
    public LdapTemplate ldapTemplate(ContextSource contextSource) {
        return new LdapTemplate(contextSource);
    }
}

This forces to include spring-boot-starter-data-ldap into project dependencies even when there are no classes/interfaces extending from LdapRepository. So to fix the test I have to either uncomment spring-boot-starter-data-ldap declaration in pom.xml (lines 25-28), or to explicitly define LdapTemplate in context configuration.

Mixing spring-boot-starter-data-ldap and spring-boot-starter-data-jpa in project dependencies slows down application startup as spring-boot-starter-data-ldap somehow interacts with repository interfaces extending JpaRepository (see https://jira.spring.io/projects/DATAJPA/issues/DATAJPA-1370). On on of our projects with several dozens of JPA repositories we achieved even 30 seconds startup time reduction just replacing spring-boot-starter-data-ldap with spring-ldap-core.

Described workaround with explicit LdapTemplate definition seems to be dubious as it does what can be done by SB automatically. Also current declaration of LdapTemplate inside of LdapDataAutoConfiguration seems to be wrong because LdapTemplate is not necessarily a part of Spring Data LDAP and should be available as simple LDAP-related component.

Thus I suggest to move declaration of LdapTemplate into LdapAutoConfiguration and remove LdapDataAutoConfiguration. Anyway we have LdapRepositoriesAutoConfiguration for the case user need Spring Data LDAP.

Comment From: philwebb

I think LdapTemplate auto-configuration should be part of LdapAutoConfiguration and we can then drop LdapDataAutoConfiguration entirely.

I consider this a bug, but I'd rather fix it in 2.1 only since there's a work-around for 2.0.x and I don't want to accidentally break existing apps.

Comment From: vpavic

I believe this is a duplicate of #13136.

Comment From: philwebb

Ahh nice!! Thanks @vpavic, I was looking on the 2.0.x branch and I didn't see it had been fixed already on 2.1.x.

Comment From: stsypanov

Cool, I didn't find those changes in 2.0.5.RELESE so which version should I use?

Comment From: philwebb

@stsypanov You can try the latest milestone (M4) of 2.1. GA for 2.1 should be near the end of Oct.

Comment From: stsypanov

Thanks!

Comment From: soheilqalamkari

please help me how to have two ldapTemplate with spring data ldap repository!!

Comment From: wilkinsona

@soheilqalamkari Please ask questions on Stack Overflow or Gitter. As mentioned in the guidelines for contributing, we prefer to use GitHub issues only for bugs and enhancements.