Git Product home page Git Product logo

spring-data-commons's Introduction

Spring Data Commons icon?job=spring data commons%2F&subject=Build Gitter Revved up by Develocity

Spring Data Commons is part of the umbrella Spring Data project that provides shared infrastructure across the Spring Data projects. It contains technology neutral repository interfaces as well as a metadata model for persisting Java classes.

Our primary goals are:

  • Powerful Repository and custom object-mapping abstractions

  • Support for cross-store persistence

  • Dynamic query generation from query method names

  • Implementation domain base classes providing basic properties

  • Support for transparent auditing (created, last changed)

  • Possibility to integrate custom repository code

  • Easy Spring integration with custom namespace

Code of Conduct

This project is governed by the Spring Code of Conduct. By participating, you are expected to uphold this code of conduct. Please report unacceptable behavior to [email protected].

Getting Started

Maven configuration

Add the Maven dependency:

<dependency>
  <groupId>org.springframework.data</groupId>
  <artifactId>spring-data-commons</artifactId>
  <version>${version}</version>
</dependency>

If you’d rather like the latest snapshots of the upcoming major version, use our Maven snapshot repository and declare the appropriate dependency version.

<dependency>
  <groupId>org.springframework.data</groupId>
  <artifactId>spring-data-commons</artifactId>
  <version>${version}-SNAPSHOT</version>
</dependency>

<repository>
  <id>spring-libs-snapshot</id>
  <name>Spring Snapshot Repository</name>
  <url>https://repo.spring.io/libs-snapshot</url>
</repository>

Getting Help

Having trouble with Spring Data? We’d love to help!

Reporting Issues

Spring Data uses GitHub as issue tracking system to record bugs and feature requests. If you want to raise an issue, please follow the recommendations below:

  • Before you log a bug, please search the issue tracker to see if someone has already reported the problem.

  • If the issue doesn’t already exist, create a new issue.

  • Please provide as much information as possible with the issue report, we like to know the version of Spring Data that you are using and JVM version.

  • If you need to paste code, or include a stack trace use Markdown ``` escapes before and after your text.

  • If possible try to create a test-case or project that replicates the issue. Attach a link to your code or a compressed file containing your code.

Building from Source

You don’t need to build from source to use Spring Data (binaries in repo.spring.io), but if you want to try out the latest and greatest, Spring Data can be easily built with the maven wrapper. You also need JDK 17 or above.

 $ ./mvnw clean install

If you want to build with the regular mvn command, you will need Maven v3.5.0 or above.

Also see CONTRIBUTING.adoc if you wish to submit pull requests, and in particular please sign the Contributor’s Agreement before your first non-trivial change.

Building reference documentation

Building the documentation builds also the project without running tests.

 $ ./mvnw clean install -Pdistribute

The generated documentation is available from target/site/reference/html/index.html.

License

Spring Data Commons is Open Source software released under the Apache 2.0 license.

spring-data-commons's People

Contributors

arend-von-reinersdorff avatar arlol avatar beamerblvd avatar christophstrobl avatar dreis2211 avatar erichaagdev avatar gregturn avatar heowc avatar izeye avatar jbrisbin avatar jexp avatar jxblum avatar markpollack avatar mawen12 avatar michael-simons avatar mp911de avatar odrotbohm avatar philwebb avatar quaff avatar ractive avatar rwinch avatar schauder avatar sdeleuze avatar sergiitsypanov avatar sis-yoshiday avatar spring-builds avatar spring-operator avatar sxhinzvc avatar thachlp avatar vpavic avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

spring-data-commons's Issues

RepositoryFactorySupport.getRepositoryBaseClass(…) should rather get a RepositoryMetadata instead of plain repository interface [DATACMNS-24]

Oliver Drotbohm opened DATACMNS-24 and commented

Implementations of that class might want to inspect entity information to decide about the base class as well, thus it would be helpful not to have to lookup that information manually


Affects: 1.0 M5

Attachments:

Issue Links:

  • DATAGRAPH-84 Adapt repository refactorings from Spring Data Commons
    ("is depended on by")

PageImpl can not be constructed with empty content [DATACMNS-23]

Stevo Slavić opened DATACMNS-23 and commented

When passing empty list to PageImpl constructor (e.g. in a test, when mocking repository method which returns Page), PageRequest is instantiated with "content.size()" as page size, but 0 size is not allowed argument value in PageRequest.

BTW, 1.0 M5 DATACMNS is not marked as released in JIRA, but it is, as part of or together with DATAJPA 1.0 M2 release


Affects: 1.0 M5

Attachments:

Referenced from: commits 4b51c5f

PreferredConstructorDiscoverer - wrong exception message [DATACMNS-43]

Maciej Drozdzowski opened DATACMNS-43 and commented

The exception is thrown at

org.springframework.data.mapping.PreferredConstructorDiscoverer.<init>(PreferredConstructorDiscoverer.java:81).

The message is "Multiple constructors with arguments found in class [xxx]! Annotate one with @PreferedConstructor explicitly to select it to be used in persistence operations". There is no such annotation, the name is PersistenceConstructor


Affects: 1.1 M1

Attachments:

Issue Links:

  • DATAMONGO-244 Misleading error message in PreferredConstructorDiscoverer
    ("is duplicated by")

Move registration of PersistenceExceptionTranslationPostProcessor into JPA module [DATACMNS-13]

Oliver Drotbohm opened DATACMNS-13 and commented

Currently the abstract base class for implementing repository namespace parsers inevitably registers a PersistenceExceptionTranslationPostProcessor. As there might be repository implementations where the actual API we code against already does exception translation we unnecessary create the need to have a PersistenceExceptionTranslator bean registered in the ApplicationContext.

We should move that registration into the JPA specific namespace parser implementation


Affects: 1.0 M1

Declaring an intermediate base repository does not work correctly [DATACMNS-52]

Gabriel Axel opened DATACMNS-52 and commented

I have cases where I want to group together several query methods, but they don't seem to fit on any entity-typed repository. I realize I could just use an arbitrary entity for the repository type, but it seems architecturally wrong, and I don't want to leave an option for client code to call methods inherited from GenericDao.

Therefore I suggest adding an option to create a repository that has no type and does not inherit any methods. I think the best way to configure such a repository interface is with annotations/XML, and not require inheriting from a marker interface. Such repository mechanism would not require the ability to add custom implementation, since it just groups together JPQL queries instead of placing them at the entity sources, and any "custom implementation" should be placed in other beans


Affects: 1.1 M2

Attachments:

Issue Links:

  • DATAJPA-76 An interface like the JpaRepository with finder methods only
    ("is duplicated by")

Support annotation based declaration of repository interfaces [DATACMNS-37]

Oliver Drotbohm opened DATACMNS-37 and commented

Currently declaring repositories is done by declaring an interface that extends Repository or one of its sub-interfaces. To not force users to extend a particular interface we could support an annotation based model:

@RepositoryProxy(domainClass = User.class, idClass = Long.class)
public interface UserRepository {

  List<User> findByUsername(String username);
}

Affects: 1.0 Final

Attachments:

Issue Links:

  • SPR-8336 Allow AnnotationTypeFilter to consider interfaces as well
    ("is depended on by")
  • DATACMNS-29 Revisit general structure of Repository interfaces and semantics of its usage

Revisit general structure of Repository interfaces and semantics of its usage [DATACMNS-29]

Oliver Drotbohm opened DATACMNS-29 and commented

Currently the repository abstraction in Spring Data commons is built on top of interfaces that are complemented by store specific ones. The common ones carry typing information that is needed to type some of the CRUD methods. We already have separated out sorting and paging functionality into PagingAndSortingRepository to allow implementations that only want to provide plain CRUD.

The store specific ones serve two purposes right now: one the one hand they allow the repositories namespace element to find the interfaces it has to create a store-specific factory bean to back that interface. This is actually only necessary to be safe in scenarios where the user uses multiple datastores and the classpath scanning for JPA potentially finds repositories that should work against Mongo or the other way round. E.g.

public interface UserRepository extends JpaRepository<User, Long> { ... }

public interface PersonRepository extends MongoRepository<Person, ObjectId> { ... }
<jpa:repositories base-package="com.acme.repositories" />
<mongo:repositories base-package="com.acme.repositories" />

In some corners of the store specific implementations we already use interface composition to expose additional API on the repositories. E.g. in the JPA module we have JpaSpecificationExecuter to allow Criteria API based Specification objects as well as QueryDslPredicateExecutor to allow execution of Querydsl Predicate instances.

Challenges

Users usually hesitate to let their repository interface extend a store specific interface as this leaks store specific API to the clients. If we'd allow simply using extending Repository or PagingAndSortingRepository we'd have to refactor the namespace parsers to discover interfaces based on these ones and let the user handle potential store-specific repository overlaps using excludes.

As JpaRepository also makes the CRUD methods of Repository transactional we probably have to provide a neutral TransactionalCrudRepository to the Commons project, as well as one including the paging and sorting methods. This way the number of needed interfaces increases quite a lot.

On the other hand by extending the Repository interface, users expose quite a few CRUD methods through their repository interface even that might not be desirable. We could move the CRUD methods into a CrudRepository interface and have the Repository interface as marker interface only. The typing information (domain and id class) could go into the CRUD one as well although this probably causes some wider scoped internal refactorings as the current codebase currently assumes these information mandatorily being present. Perhaps we could even rather use an annotation then but that would introduce yet another concept to demarcate repository interfaces


Affects: 1.0 M5

Issue Links:

  • DATACMNS-37 Support annotation based declaration of repository interfaces

  • DATACMNS-36 Improve transaction handling for repositories

Invalid entity metadata when domain class implements persistable [DATACMNS-19]

Stevo Slavić opened DATACMNS-19 and commented

Latest snapshot (spring-data-jpa-1.0.0.BUILD-20110227.093237-171.jar) introduced a bug which makes find queries (with Specification API) to fail for domain objects which implement Persistable. I believe issue is either in JpaRepositoryFactory stragery for creating entity information - if domain class implements Persistable, PersistableEntityMetadata fixes domain class to Persistable.class which looses actual domain class. Here is relevant stack trace snippet:

java.lang.IllegalArgumentException: Not an entity: interface org.springframework.data.domain.Persistable
	at org.hibernate.ejb.metamodel.MetamodelImpl.entity(MetamodelImpl.java:160)
	at org.hibernate.ejb.criteria.QueryStructure.from(QueryStructure.java:138)
	at org.hibernate.ejb.criteria.CriteriaQueryImpl.from(CriteriaQueryImpl.java:179)
	at org.springframework.data.jpa.repository.support.SimpleJpaRepository.applySpecificationToCriteria(SimpleJpaRepository.java:450)
	at org.springframework.data.jpa.repository.support.SimpleJpaRepository.getQuery(SimpleJpaRepository.java:385)
	at org.springframework.data.jpa.repository.support.SimpleJpaRepository.findAll(SimpleJpaRepository.java:267)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.springframework.data.repository.support.RepositoryFactorySupport$QueryExecuterMethodInterceptor.executeMethodOn(RepositoryFactorySupport.java:268)
	at org.springframework.data.repository.support.RepositoryFactorySupport$QueryExecuterMethodInterceptor.invoke(RepositoryFactorySupport.java:249)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
	at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
	at org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.invoke(PersistenceExceptionTranslationInterceptor.java:155)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
	at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
	at $Proxy60.findAll(Unknown Source)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
	at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
	at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
	at $Proxy61.findAll(Unknown Source)

Affects: 1.0 M3

Attachments:

Referenced from: commits spring-projects/spring-data-jpa@4d50569

2 votes, 3 watchers

Query parser shall support 'In' keyword [DATACMNS-16]

Oliver Drotbohm opened DATACMNS-16 and commented

The query parser should support the In keyword that binds a Collection, Array or varargs parameter, e.g.:

List<User> findByFirstnameIn(Collection<String> firstnames);

List<User> findByFirstnameIn(String[] firstnames);

List<User> findByFirstnameIn(String... firstnames);

Issue Links:

  • DATAJPA-30 Support In keyword in query parsing
    ("is depended on by")

1 votes, 1 watchers

Introduce value object for domain class and repository metadata [DATACMNS-17]

Oliver Drotbohm opened DATACMNS-17 and commented

Currently the repositories are using the domain class directly and interact with IsNewAware and IdAware. We should introduce an interface for all this entity information and provide a basic value object to encapsulate the domain class and adapt repository- and repository factory base classes to rather use this one


Attachments:

Issue Links:

  • DATAJPA-32 Adapt new metadata API
    ("is depended on by")
  • DATAMONGO-47 Adapt new metadata API
    ("is depended on by")

Improve algorithm to detect persistence constructor [DATACMNS-34]

Oliver Drotbohm opened DATACMNS-34 and commented

The algorithm to detect persistence constructors has some drawbacks currently:

  1. It neglects no-arg constructors that have an @PersistenceContext annotation. This might be useful if the constructors having arguments are taking domain types that derive an internal structure which is persisted. In that case you don't want to expose these low-level inner types in a constructor but rather use a protected empty one and let the converter populate the properties then.
  2. The algorithm working with the constructors taking parameters relies on the order of constructors returned by Class.getDeclaredConstructors() which is not guaranteed to be consistent. In case of multiple constructors and no usage of the @PersistenceConstructor annotation the constructor being used can not be determined unambiguously.

I suggest to alter the algorithm to the following:

  1. Use default constructor if no constructor is specified
  2. Use single defined constructor if only one is specified
  3. Insist on @PersistenceConstructor if multiple constructors were found

Affects: 1.0 Final

Referenced from: commits 138191f, 870d156

Make org.springframework.data.domain.* java.io.Serializable [DATACMNS-30]

Justin Spears opened DATACMNS-30 and commented

Please make the data domain class's implement java.io.Serializable.

I expose my JPARepositoryDAO's as JMS Queue's, via Apache Camel All works well with the exception of Page not being java.io.Serializable, Externalizable is a pain, it would be really great if this java.io.Serializable could be added to the domain class's. Now I have to either patch, implement the same interface and map, or something else. I recognize that there is a bit of an issue with the fields being final and the no args constructor requirement

This is also important in many webapp situations where these might be put in the HttpServletSession, in a clustered environment it won't work


Affects: 1.0 M2

Attachments:

Improve transaction handling for repositories [DATACMNS-36]

Oliver Drotbohm opened DATACMNS-36 and commented

The transaction handling in repositories is currently done using annotations on the repository interface level. This is due to the fact that we need to provide re-configuration means of transaction attributes on the user's repository interface. Assuming we have a transactional repository implementation:

public class SampleRepositoryImplementation implements Repository<...> {
  // ...
  @Transactional
  public T save(T entity) {
    // ...
  }
}

A user shall now be able to redefine that transaction configuration in his repository interface:

public interface UserRepository extends Repository<User, Long> {

  @Transactional(propagation = Propagation.REQUIRES_NEW)
  public User save(User user);
}

Unfortunately AbstractFallbackTransactionAttributeSource hard codes the algorithm of looking up transaction configuration preferring the implementation class' configuration. To work around this we currently use @Transactional e.g. JpaRepository which requires us to redeclare every method which is a bit of a mess. Beyond that user repositories now have to extend JpaRepository instead of plain Repository.

So we should come up with a custom TransactionAttributeSource that adapts the algorithm accordingly. We might start with a copy of the original Spring code and modify the relevant parts


Affects: 1.0 Final

Issue Links:

  • DATACMNS-29 Revisit general structure of Repository interfaces and semantics of its usage

Referenced from: commits d8c5bca

Rename CRUD methods in GenericRepository to start with findBy rather than readBy [DATACMNS-3]

Oliver Drotbohm opened DATACMNS-3 and commented

As discussed with Mark during the review we should call the CRUD methods on GenericRepository interface to start with findBy as readBy is too general


Attachments:

This issue is a sub-task of DATACMNS-1

Issue Links:

  • DATACMNS-1 Introduce support for building repositories from Hades library
    ("is depended on by")

Referenced from: commits spring-projects/spring-data-jpa@e8c5666

Introduce support for building repositories from Hades library [DATACMNS-1]

Oliver Drotbohm opened DATACMNS-1 and commented

As we'd like to integrate functionality from the Hades library (see link below), we should move the very core parts of it into Spring Data Commons as it can be used to build repository abstractions for other datastores then as well.

http://hades.synyx.org


Sub-tasks:

  • DATACMNS-2 Rename GenericRepository to Repository

  • DATACMNS-3 Rename CRUD methods in GenericRepository to start with findBy rather than readBy

  • DATACMNS-4 Move JPA specific methods into JPA module

  • DATACMNS-5 Clarify that ID is used for equals/hashCode inside JavaDoc of AbstractPersistable

  • DATACMNS-6 Make IsNewAware, IdAware and EntityInformation top level types

  • DATACMNS-8 Merge auditing package into domain package

  • DATACMNS-9 Factor out methods containing page/sorting abstraction into separate interface

Issue Links:

  • DATACMNS-2 Rename GenericRepository to Repository
    ("depends on")
  • DATACMNS-3 Rename CRUD methods in GenericRepository to start with findBy rather than readBy
    ("depends on")
  • DATAJPA-1 Move JPA parts of Hades library into Spring JPA

1 votes, 1 watchers

Introduce method name parser that allows building criteria based queries from method names [DATACMNS-10]

Oliver Drotbohm opened DATACMNS-10 and commented

With ...repository.query.parser.PartSource we currently have an API to build String based queries from query method names. This works quite well in the JPA specific implementation of the query parser.

The NoSQL datastores mostly work with a criteria API instead and the PartSource doesn't really work nicely in that case as we have to combine query creation and parameter binding in one step (which is not the case for string based queries).

Beyond that the general parsing algorithm could be extracted from the JPA module and provide base classes to have persistence technology specific subclasses in turn that simply hook into the process and build the query with their specific criteria API


Issue Links:

  • DATAJPA-4 Refactor query method name parsing to use new parsing infrastructure and Criteria API
    ("is depended on by")

Property check for repository methods fails for properties starting with _ [DATACMNS-45]

Oliver Drotbohm opened DATACMNS-45 and commented

If you have a class

class Person {
  private int _age;
  
  public int getAge() {
    return _age;
  }
}

and a repository interface

interface PersonRepository extends Repository<Person, Long> {
  Person findByAge(int age);
}

creating a proxy instance for the interface will fail with an exception claiming that no property age is found. This is due to the fact that TypeDiscoverer is currently only considering fields right now and we should think about if it makes sense to make it really property aware.

A workaround to simply use findBy_Age fails as well as _ is used as custom delimiter to manually define property paths. So we should at least guard the code to correctly resolve _age in case there's no content in front of the _


Affects: 1.1 M1

Attachments:

Referenced from: commits 351e37e

StackOverflowError on self-referencing Objects [DATACMNS-38]

Robert Stiller opened DATACMNS-38 and commented

Hi, i get the following error when starting a testcase:

06:55:19,554 ERROR TestContextManager:324 - Caught exception while allowing TestExecutionListener [org.springframework.test.context.support.DependencyInjectionTestExecutionListener@49198ff2] to prepare test instance [null(example.SiteServiceTest)]
java.lang.IllegalStateException: Failed to load ApplicationContext
	at org.springframework.test.context.TestContext.getApplicationContext(TestContext.java:308)
	at org.springframework.test.context.support.DependencyInjectionTestExecutionListener.injectDependencies(DependencyInjectionTestExecutionListener.java:109)
	at org.springframework.test.context.support.DependencyInjectionTestExecutionListener.prepareTestInstance(DependencyInjectionTestExecutionListener.java:75)
	at org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:321)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.createTest(SpringJUnit4ClassRunner.java:220)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner$1.runReflectiveCall(SpringJUnit4ClassRunner.java:301)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.methodBlock(SpringJUnit4ClassRunner.java:303)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:240)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
	at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
	at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:180)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'siteService': FactoryBean threw exception on object creation; nested exception is java.lang.StackOverflowError
	at org.springframework.beans.factory.support.FactoryBeanRegistrySupport.doGetObjectFromFactoryBean(FactoryBeanRegistrySupport.java:149)
	at org.springframework.beans.factory.support.FactoryBeanRegistrySupport.getObjectFromFactoryBean(FactoryBeanRegistrySupport.java:102)
	at org.springframework.beans.factory.support.AbstractBeanFactory.getObjectForBeanInstance(AbstractBeanFactory.java:1429)
	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:190)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:580)
	at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:895)
	at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:425)
	at org.springframework.test.context.support.AbstractGenericContextLoader.loadContext(AbstractGenericContextLoader.java:84)
	at org.springframework.test.context.support.AbstractGenericContextLoader.loadContext(AbstractGenericContextLoader.java:1)
	at org.springframework.test.context.TestContext.loadApplicationContext(TestContext.java:280)
	at org.springframework.test.context.TestContext.getApplicationContext(TestContext.java:304)
	... 24 more
Caused by: java.lang.StackOverflowError
	at java.util.HashMap$HashIterator.<init>(HashMap.java:795)
	at java.util.HashMap$EntryIterator.<init>(HashMap.java:849)
	at java.util.HashMap$EntryIterator.<init>(HashMap.java:849)
	at java.util.HashMap.newEntryIterator(HashMap.java:863)
	at java.util.HashMap$EntrySet.iterator(HashMap.java:967)
	at java.util.AbstractMap.hashCode(AbstractMap.java:492)
	at org.springframework.util.ObjectUtils.nullSafeHashCode(ObjectUtils.java:286)
	at org.springframework.data.util.TypeDiscoverer.hashCode(TypeDiscoverer.java:230)
	at org.springframework.data.util.ClassTypeInformation.hashCode(ClassTypeInformation.java:79)
	at org.springframework.util.ObjectUtils.nullSafeHashCode(ObjectUtils.java:286)
	at org.springframework.data.util.TypeDiscoverer.hashCode(TypeDiscoverer.java:231)
	at org.springframework.data.util.ClassTypeInformation.hashCode(ClassTypeInformation.java:79)
	at org.springframework.util.ObjectUtils.nullSafeHashCode(ObjectUtils.java:286)
	at org.springframework.data.util.TypeDiscoverer.hashCode(TypeDiscoverer.java:231)
	at org.springframework.data.util.ClassTypeInformation.hashCode(ClassTypeInformation.java:79)
	at org.springframework.util.ObjectUtils.nullSafeHashCode(ObjectUtils.java:286)
	at org.springframework.data.util.TypeDiscoverer.hashCode(TypeDiscoverer.java:231)
	at org.springframework.data.util.ClassTypeInformation.hashCode(ClassTypeInformation.java:79)
	at org.springframework.util.ObjectUtils.nullSafeHashCode(ObjectUtils.java:286)
	at org.springframework.data.util.TypeDiscoverer.hashCode(TypeDiscoverer.java:231)
	at org.springframework.data.util.ClassTypeInformation.hashCode(ClassTypeInformation.java:79)
	at org.springframework.util.ObjectUtils.nullSafeHashCode(ObjectUtils.java:286)
	at org.springframework.data.util.TypeDiscoverer.hashCode(TypeDiscoverer.java:231)
	at org.springframework.data.util.ClassTypeInformation.hashCode(ClassTypeInformation.java:79)
	at org.springframework.util.ObjectUtils.nullSafeHashCode(ObjectUtils.java:286)
	at org.springframework.data.util.TypeDiscoverer.hashCode(TypeDiscoverer.java:231)
	at org.springframework.data.util.ClassTypeInformation.hashCode(ClassTypeInformation.java:79)
	at org.springframework.util.ObjectUtils.nullSafeHashCode(ObjectUtils.java:286)
	at org.springframework.data.util.TypeDiscoverer.hashCode(TypeDiscoverer.java:231)
	at org.springframework.data.util.ClassTypeInformation.hashCode(ClassTypeInformation.java:79)
	at org.springframework.util.ObjectUtils.nullSafeHashCode(ObjectUtils.java:286)
	at org.springframework.data.util.TypeDiscoverer.hashCode(TypeDiscoverer.java:231)
	at org.springframework.data.util.ClassTypeInformation.hashCode(ClassTypeInformation.java:79)

Here is my applicationContext.xml:

<?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:context="http://www.springframework.org/schema/context"
    xmlns:spring-data="http://www.springframework.org/schema/data/mongo"
    xsi:schemaLocation="
        http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/context
        http://www.springframework.org/schema/context/spring-context.xsd
        http://www.springframework.org/schema/data/mongo
        http://www.springframework.org/schema/data/mongo/spring-mongo.xsd">
    
    <spring-data:mongo id="mongo" host="localhost" port="27017"/>
    
    <bean id="mongoTemplate" class="org.springframework.data.document.mongodb.MongoTemplate">
        <constructor-arg ref="mongo"/>
        <constructor-arg value="testdb"/>
        <constructor-arg value="testcollection"/>
        <constructor-arg>
            <spring-data:mapping-converter/>
        </constructor-arg>
    </bean>
    
    <spring-data:repositories base-package="example.service">
        <spring-data:repository id="siteService"/>
    </spring-data:repositories>
    
    <context:annotation-config/>
	
</beans>

The Testcase:

package example.service;

import java.util.List;

import javax.inject.Inject;

import junit.framework.TestCase;

import org.junit.Assert;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;

import example.Site;
import example.query.SiteQuery;

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = "classpath:/applicationContext.xml")
public class SiteServiceTest extends TestCase {
    
    @Inject
    protected SiteService siteService;
    
    public SiteService getSiteService() {
        return siteService;
    }
    
    public void setSiteService(SiteService newSiteService) {
        siteService = newSiteService;
    }
    
    @Test
    public void test() {
        List<Site> sites = null;
        
        sites = siteService.findAll(SiteQuery.getForAlias("/"));
        Assert.assertNull(sites);
    }
}

The classes:

package example.site;

import java.util.*;

import org.springframework.data.document.mongodb.mapping.DBRef;
import org.springframework.data.document.mongodb.mapping.Document;

import com.google.code.morphia.annotations.Entity;

@Document
@Entity
public class Site {
    
    private static final long serialVersionUID = -6751151047717976403L;
    
    @Id
    protected String id;
    protected List<String> aliases = new ArrayList<String>();
    protected Boolean eligibleForSitemap = Boolean.TRUE;
    @DBRef
    protected Site parent;
    
    public List<String> getAliases() {
        return aliases;
    }
    
    public void setAliases(List<String> newAliases) {
        aliases = newAliases;
    }
    
    public Boolean getEligibleForSitemap() {
        return eligibleForSitemap;
    }
    
    public void setEligibleForSitemap(Boolean newEligibleForSitemap) {
        eligibleForSitemap = newEligibleForSitemap;
    }
    
    public Site getParent() {
        return parent;
    }
    
    public void setParent(Site newParent) {
        parent = newParent;
    }
}
package example.query;

import com.mysema.query.types.Predicate;

import example.QSite;

public class SiteQuery {
    
    public static Predicate getForAlias(String alias) {
        return QSite.site.aliases.contains(alias);
    }
}

my Dependencies:

<dependency>
	<groupId>org.springframework.data</groupId>
	<artifactId>spring-data-mongodb</artifactId>
	<version>1.0.0.M2</version>
</dependency>
<dependency>
	<groupId>cglib</groupId>
	<artifactId>cglib</artifactId>
	<version>2.2</version>
</dependency>
<dependency>  
	<groupId>com.mysema.querydsl</groupId>  
	<artifactId>querydsl-mongodb</artifactId>  
	<version>2.1.2</version>  
</dependency>

I've found out, that if I comment the parent out, everything is fine ... so I guess the introspection-process of the spring-data library got a bug


Affects: 1.0 Final

Attachments:

Factor out methods containing page/sorting abstraction into separate interface [DATACMNS-9]

Oliver Drotbohm opened DATACMNS-9 and commented

As we're still in debate whether we will include the pagination and sorting abstraction in the core repository interface we should factor it into a separate interface first. Depending on the feedback we get we can still move it back into the core one again at a later point in time


Attachments:

This issue is a sub-task of DATACMNS-1

Referenced from: commits spring-projects/spring-data-jpa@e8c5666

Missing plugin repository [DATACMNS-27]

Stevo Slavić opened DATACMNS-27 and commented

Project can not be built with Maven 3, it's strict, and requires plugin dependencies to be resolved from plugin repositories.

Also project is configured to compile with source and target being Java 1.5, but @Override is used on two places with 1.6 meaning so compilation fails.

Attached patch [^DATACMNS-Adds-spring-maven-release-repo-as-plugin-repository.patch] fixes both build issues.

Related issue: DATAJPA-26


Affects: 1.0 M5

Attachments:

Referenced from: commits c9eeee5

Handle naming collisions of interfaces when scanning and registering repository bean definitions [DATACMNS-169]

Stevo Slavić opened DATACMNS-169 and commented

So here's what I think we can come up with:

  1. Manually registering a repository is always overriding a previously registered one in case there already is one with the same name.
  2. In automatic configuration we abort the process in case we already find a bean with the calculated id

So this would make the namespace setup quite restrictive esp. when dealing with multiple <repositories /> elements as they might overlap regarding the repositories to be registered but that should be by intention I guess


Reference URL: http://redmine.synyx.org/boards/2/topics/210

Issue Links:

  • DATACMNS-168 Allow customizing the bean name for repository beans

Referenced from: commits spring-projects/spring-data-mongodb@8ac2ff6

1 votes, 4 watchers

log4j dependency

Hi

When I add spring-data-commons to my project it pulls log4j into the classpath. I have to exclude it because I use logback.

It looks like spring-data-commons does not need log4j there is only this pom entry that force log4j into the classpath. Maybe another scope like 'test' would be sufficient.

log4j log4j runtime

Ralph

Rename Repository.findById(…) to findOne(…) [DATACMNS-20]

Oliver Drotbohm opened DATACMNS-20 and commented

All finder methods inside Repository are named findAll… so it's a bit weired that the method to find a single element by id actually refers to the property and is not called findOne instead. Especially as we already have findOne(Specification specification) inside JPA sub-interface for example. So I suggest ro rename the method to findOne(ID id)


Affects: 1.0 M3

Attachments:

Referenced from: commits spring-projects/spring-data-mongodb@01a800b, spring-projects/spring-data-mongodb@f585bef

Default getQueryLookupStrategy(…) to return null and skip query detection in that case [DATACMNS-25]

Oliver Drotbohm opened DATACMNS-25 and commented

Currently subclasses of RepositoryFactorySupport have to provide an implementation of QueryLookupStrategy even if they don't want to provide query method usage at all. So on the one hand we have to make QueryExecuterMethodInterceptor be able to cope with null values for QueryLookupStrategy. The we could provide a default implementation for RepositoryFactorySupport.getQueryLookupStrategy(Key) to return null


Affects: 1.0 M5

Attachments:

Issue Links:

  • DATAGRAPH-84 Adapt repository refactorings from Spring Data Commons
    ("is depended on by")

Make usage of transactions optional for repositories [DATACMNS-12]

Oliver Drotbohm opened DATACMNS-12 and commented

The current RepositoryFactoryBeanSupport implementation creates a TransactionInterceptor using the configured transaction manager to create transactions. As the TransactionInterceptor simply skips creating a transaction if there is no transaction manager defined in the current ApplicationContext this works fine in cases where you use a NoSql store standalone. But as this will pick up any transaction manager defined in the ApplicationContext this will cause issues as soon as somebody starts using another (transaction-capable) persistence store (e.g. JPA).

So I suggest extracting the transaction setup into a TransactionalRepositoryFactoryBeanSupport class that the appropriate persistence technologies can then use. We have to update the namespace to reflect those changes as well


Affects: 1.0 M1

Attachments:

Issue Links:

  • DATAJPA-15 transaction-manager-ref namespace attribute not propagated into bean configuration
    ("is depended on by")

Support Java-based Configuration of Repositories [DATACMNS-47]

Brandon M. opened DATACMNS-47 and commented

Add RepositoryFactoryBuilder that would allow for easily configuring repositories using Spring's Java-based configuration. See forum reference for details


Affects: 1.0 Final

Reference URL: http://forum.springsource.org/showthreadQuery.php?108508-Java-Config-Support-for-Repository-Configuration&p=359537

Issue Links:

  • DATACMNS-103 Setup hybrid Spring 3.0.6 / 3.1 build
    ("depends on")
  • DATAGRAPH-266 Provide JavaConfig support
    ("is depended on by")
  • DATAJPA-69 Repositories scanning using java-config
    ("is depended on by")
  • DATAMONGO-476 JavaConfig support for Mongo repositories
    ("is depended on by")
  • SGF-102 Add support for JavaConfig for repositories
    ("is depended on by")

Referenced from: commits 27a8a8d, 96795f2

17 votes, 24 watchers

Plugin repository missing for maven build [DATACMNS-22]

Stevo Slavić opened DATACMNS-22 and commented

Somewhat related to DATAJPA-26 repository.springframework.maven.release plugin repository ( http://maven.springframework.org/release ) is missing for spring data commons project:

"Unresolveable build extension: Plugin org.springframework.build.aws:org.springframework.build.aws.maven:3.1.0.RELEASE or one of its dependencies could not be resolved..."


Affects: 1.0 M4

Referenced from: commits 33efa23

Add capabilities to let repository queries be validated [DATACMNS-11]

Oliver Drotbohm opened DATACMNS-11 and commented

As we know about the queries backing the query methods it would be cool if there was means to validate them. This functionality could be exposed through a namespace attribute which triggers the validation on ApplicationContext refresh. Another option would be to offer a test case class that one can simply hand the configuration files to to validate queries during integration testing


No further details from DATACMNS-11

Change return type of findAll(…) methods to return Iterable rather than List. [DATACMNS-21]

Oliver Drotbohm opened DATACMNS-21 and commented

Some datastores (e.g. Neo4J) allow delaying the actual data retrieval by returning Iterable instead of Collection types. This can significantly improve performance especially when working with large result sets. As our findAll(…) methods all return List instances we force eager retrieval of the data in any case.

So we could change the return types of findAll(…) methods for Repository and have store specific ones override those methods to return List again in case these stores can only return Collection instances anyway (e.g. JPA, Mongo)


Affects: 1.0 M3

Referenced from: commits spring-projects/spring-data-mongodb@d824ed7

Non-public constructor not regarded as persistence constructor [DATACMNS-26]

Oliver Drotbohm opened DATACMNS-26 and commented

The detection mechanism for the persistence constructor does not seem to detect private constructors. Given the following class:

public class Foo {

  public static final Foo ONE = new Foo(1);
  public static final Foo TWO = new Foo(2);

  private int value;
  
  private Foo(int value); { ... }
}

Same applies to package protected constructors. Of course one would better use an enum for that currently but one might need this construct here to get Mongo's $gt and $lt to work correctly


Referenced from: commits 6bb0923

Add delete by id method to repository interface [DATACMNS-35]

tony kerz opened DATACMNS-35 and commented

Currently one has to provide an instance of the T type for repository to delete, sometimes in a web app, all you have handy is the id as passed encoded in a hyperlink, so there is an extra step to construct or look up an instance of T for a delete operation.

It would be more convenient to have a method as delete(ID id), so unless this is a deliberate design decision, request is to add such a method


Affects: 1.0 Final

Referenced from: commits spring-projects/spring-data-jpa@ad40b37

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.