spring-projects / spring-data-ldap Goto Github PK

Oliver Drotbohm opened DATALDAP-18 and commented

Referenced from: commits f566508, 1b759eb, f8921c5

Backported to: 1.0 GA (Ingalls)

Mark Paluch opened DATALDAP-3 and commented

No further details from DATALDAP-3

Oliver Drotbohm opened DATALDAP-43 and commented

Referenced from: commits 984acd0, bde85f7, 9cc35bd, a71956d, b09bbc4, 369a78a

Mark Paluch opened DATALDAP-17 and commented

Also, add Github PR template

Issue Links:

• DATACMNS-974 Update project documentation with the CLA tool integration

Referenced from: commits 35e74ec, 07a2bb7

Backported to: 1.0 GA (Ingalls)

Oliver Drotbohm opened DATALDAP-32 and commented

No further details from DATALDAP-32

Oliver Drotbohm opened DATALDAP-36 and commented

No further details from DATALDAP-36

Mark Paluch opened DATALDAP-6 and commented

Issue Links:

• DATACMNS-952 Switch to less expensive lookup of Spring Data web support configuration

Referenced from: commits 8647253

Oliver Drotbohm opened DATALDAP-37 and commented

Issue Links:

• DATACMNS-1059 QuerydslPredicateExecutor.findOne should return Optional<T>
  ("depends on")

Guan Wang opened DATALDAP-26 and commented

It appears spring.ldap has limited support on client side transaction. I am wondering if Spring Data LDAP has the same support using the spring.data way, such as @Transactional?

Thanks a lot!

No further details from DATALDAP-26

Oliver Drotbohm opened DATALDAP-9 and commented

Issue Links:

• DATACMNS-891 Switch constructor injection of the repository interface for repository factory beans
  ("depends on")

Referenced from: commits 4a65f19, f598d14

Backported to: 1.0 RC1 (Ingalls)

Oliver Drotbohm opened DATALDAP-46 and commented

No further details from DATALDAP-46

Oliver Drotbohm opened DATALDAP-33 and commented

No further details from DATALDAP-33

Mark Paluch opened DATALDAP-8 and commented

Referenced from: commits dbd4bf2

Mark Paluch opened DATALDAP-7 and commented

Referenced from: commits 5096ae3, d594183

John Blum opened DATALDAP-31 and commented

Assert compatibility of Spring Data LDAP on Java 9.

Setup Travis CI build using JDK 9.

No further details from DATALDAP-31

Oliver Drotbohm opened DATALDAP-20 and commented

No further details from DATALDAP-20

Oliver Drotbohm opened DATALDAP-10 and commented

No further details from DATALDAP-10

Oliver Drotbohm opened DATALDAP-42 and commented

No further details from DATALDAP-42

Mark Paluch opened DATALDAP-27 and commented

nexus.codehaus.org is no longer available and the repos is relocated to https://oss.sonatype.org/content/repositories/codehaus-snapshots

No further details from DATALDAP-27

Mark Paluch opened DATALDAP-4 and commented

No further details from DATALDAP-4

Mark Paluch opened DATALDAP-21 and commented

Issue Links:

• DATACMNS-867 Upgrade to Java 8 and adapt APIs
  ("depends on")

Mark Paluch opened DATALDAP-2 and commented

Referenced from: commits 1e35b62

Mark Paluch opened DATALDAP-12 and commented

Issue Links:

• DATAMONGO-1567 Upgrade to a newer JDK version on TravisCI

Referenced from: commits c025d0f, eb8a845

Backported to: 1.0 RC1 (Ingalls)

Oliver Drotbohm opened DATALDAP-19 and commented

No further details from DATALDAP-19

John Blum opened DATALDAP-28 and commented

In the Spring Data Commons RepositoryConfigurationExtensionSupport class, the getRepositoryFactoryClassName() method was renamed to getRepositoryFactoryBeanClassName() causing compilation failures in SD LDAP

Reference URL: https://jira.spring.io/browse/DATACMNS-1018

• Fix link to spring-ldap documentation in reference documentation #46

Mark Paluch opened DATALDAP-5 and commented

Referenced from: commits 0133ec9, a5810ff

Oliver Drotbohm opened DATALDAP-15 and commented

Backported to: 1.0 RC1 (Ingalls)

Mark Paluch opened DATALDAP-1 and commented

Create a Spring Data LDAP-specific namespace and namespace handler instead of reusing the Spring LDAP namespace

Referenced from: commits abf44c2, ba9f653, 39b6b4d, 8303194

Houcheng opened DATALDAP-30 and commented

We required a paging repository to query the LDAP database in paged

Issue Links:

• DATALDAP-138 Handle large find all requests
  ("is duplicated by")

Referenced from: pull request #3

• Adapt API in RepositoryFactoryBeanSupport implementation #26
• Upgrade to Spring LDAP 2.2.0 GA #31
• Upgrade to a newer JDK version on TravisCI #32
• Add build profile for next Spring LDAP version #35
• Upgrade to Spring LDAP 2.3 RC1 #36

Mark Paluch opened DATALDAP-11 and commented

Referenced from: commits dfc24df, d764567

Backported to: 1.0 RC1 (Ingalls)

Jens Schauder opened DATALDAP-38 and commented

The LDAP example fails when run with JDK9 without the --permit-illegal-access flag.

java.lang.IllegalStateException: Failed to load ApplicationContext
Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'ldapContextSource' defined in class path resource [org/springframework/boot/autoconfigure/ldap/embedded/EmbeddedLdapAutoConfiguration.class]: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.springframework.ldap.core.ContextSource]: Factory method 'ldapContextSource' threw exception; nested exception is java.lang.NoClassDefFoundError: Could not initialize class org.springframework.ldap.core.support.LdapContextSource
Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.springframework.ldap.core.ContextSource]: Factory method 'ldapContextSource' threw exception; nested exception is java.lang.NoClassDefFoundError: Could not initialize class org.springframework.ldap.core.support.LdapContextSource
Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.springframework.ldap.core.support.LdapContextSource

Issue Links:

• DATACMNS-1033 Assert Java 9 compatibility

Guan Wang opened DATALDAP-13 and commented

My code stopped working since 2 days ago and I submitted this at Spring Boot:
spring-projects/spring-boot#7670

It seems this issue has been solved. However, I still have issue to make my code working: If I put @EnableLapRepositories on a class with a @Bean for ldapTemplate to enable a LDAP Repository, Spring complains the following:
Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'userRepository': Could not resolve matching constructor (hint: specify index/type/name arguments for simple parameters to avoid type ambiguities)

My guess is that userRepository needs a ldapTemplate bean, which is not available at this moment.

I am not sure if I made a classic "amateur" mistake or this has something to do with the recent upgrade to SPF 5.0

Affects: 1.0 RC1 (Ingalls)

Mark Paluch opened DATALDAP-25 and commented

Affects: 1.0.1 (Ingalls SR1)

Referenced from: pull request #1, and commits 3ad71d0, b9ce3e7, 5984451

Backported to: 1.0.2 (Ingalls SR2)

Oliver Drotbohm opened DATALDAP-16 and commented

Referenced from: commits acb33dd, c66a70e, b37cb53, 9f7b75f, c48df49, a9cd680, d40e391

Brett Maxfield opened DATALDAP-22 and commented

It would be nice to be able to replace parameters in base dn of a custom @Query

For example, you can do this as of 1.0.0 (using default SimpleLdapRepository) :

@Query(value="(mail={0})", searchScope=SearchScope.SUBTREE, base="o=hosting,dc=example,dc=com")
MailAccount findByMail(String mail);

The {0} is replaced with the 0'th parameter on the interface, tokens repalced by the spring QueryBuilder

But something you cannot do (so it's a theoretical example, of scope single) :

@Query(value="(mail={0})", searchScope=SearchScope.ONELEVEL, base="jvd={1},o=hosting,dc=example,dc=com")
MailAccount findByDomain(String mail, String domain);

The intent would be to expands the placeholder(s) in the base= field in the annotation, with the numbered argument, and do a search in the requested scope, using the search filter with the replaced parameters. Alternatively (perhaps in addition) using the named @Param annotation, as used by spring-data-jpa

In this case there is a LDAP structure like :

o=hosting
jvd=domain1
mail=somebody@domain1
jvd=domain2
...

The first query is valid, and it works, as it has a subtree scope, and it so happens the mail=* entries under the jvd=domain structure are also unique when queried from o=hosting scope, but it is only a happy accident. In my application i do a findAll() with an LdapQuery incl., a crafted base, this was pushed up to the business objects implementations, a bit messy.

A per-domain search in this application should search in that subtree only. The standard @DnAttribute paradigm is too inflexible for this, as the domain does not stand by itself in any ldap field, that can be mapped to a bean field (without custom logic to split the mail).

If there were (uid=x) entries, which are only valid if searched within the jvd=domain structure, then this would not be appropriate. The (jvd=x) structures are managed by separate organizations, it is a standard structure for virtual mailbox applications

Affects: 1.0 GA (Ingalls)

Mark Paluch opened DATALDAP-45 and commented

Issue Links:

• DATACMNS-1114 Introduce nullable annotations

Referenced from: commits b3f1bbc

Oliver Drotbohm opened DATALDAP-29 and commented

No further details from DATALDAP-29

Jens Schauder opened DATALDAP-35 and commented

Issue Links:

• DATACMNS-944 Move to better naming scheme of methods in repository interfaces
  ("depends on")

Referenced from: commits 7020afe, 160c078, 4733f7e

Oliver Drotbohm opened DATALDAP-41 and commented

No further details from DATALDAP-41

identigral opened DATALDAP-23 and commented

Please support SpEL in @Entry to avoid hardcoding values of 'base' and 'objectClasses' attributes

Affects: 1.0.1 (Ingalls SR1)

Oliver Drotbohm opened DATALDAP-47 and commented

No further details from DATALDAP-47

Oliver Drotbohm opened DATALDAP-44 and commented

No further details from DATALDAP-44

Oliver Drotbohm opened DATALDAP-14 and commented

Backported to: 1.0 RC1 (Ingalls)

Mark Paluch opened DATALDAP-40 and commented

No further details from DATALDAP-40

Oliver Drotbohm opened DATALDAP-24 and commented

No further details from DATALDAP-24

Mark Paluch opened DATALDAP-39 and commented

No further details from DATALDAP-39

Oliver Drotbohm opened DATALDAP-34 and commented

No further details from DATALDAP-34

• Update project documentation with the CLA tool integration #38
• Upgrade to Spring Data LDAP 2.3.1 #39