Problem with custom save(T) implementation -Spring Data Commons version 1.3.1.RELEASE

[visola]

Few months ago I worked in a project using Spring Data (Commons 1.2.1.RELEASE + JPA 1.0.3.RELEASE) and everything went fine.

Last week I started a new project with the same code (refactoring old code) and moved on to the the latest version of both (Commons 1.3.1.RELEASE + JPA 1.1.0.RELEASE) and some of my unit tests started to fail.

After debugging for some time I found that the problem was that my custom implementation of save wasn't being used, instead, the default (from SimpleJPARepository) was being used. After some digging, I got into CrudRepository and the change in signature of save:
- https://github.com/SpringSource/spri...epository.java
- https://jira.springsource.org/browse/DATACMNS-151

I changed my custom implementation to match the new signature but nothing changes. So I cloned the git repository, changed back and rebuild it to make sure that this was the problem and confirmed it.

I didn't know if I should post it here, create a JIRA for it or what so here I am.

I wanted to confirm if anyone else is having this problem and if there's any workaround or if I should create a JIRA for it.

[Oliver Gierke]

If the signature of your custom implementation matches the one in CrudRepository you should get the method invoked. If that's not the case definitely go ahead and open a ticket, possibly with a test case to reproduce the issue.

[visola]

Thank you for the fast reply. I'll right a simple test case trying to reproduce it and if it's broken, I'll open a ticket.

[Oliver Gierke]

You might wanna have a look at RepositoryFactorySupportUnitTests and invokesCustomMethodIfItRedeclaresACRUDOne() in particular as this test seems to test what you're shooting for. Maybe you can alter it to fit your scenario more closely and bring it to fail…

[visola]

I just tried that and I couldn't get it to fail.

I'll try a more complex example to see what exactly is going on and will let you know.

Thank you for the help.

[visola]

I created two examples, one is broken and one contains the workaround I'll be using. They are both attached and both the same project. As simple as I can think of to reproduce the problem. Just unzip and run mvn test.

I'm still not sure if this is a bug or a configuration problem from my side because I wasn't able to reproduce it using the mock objects in the unit test you mentioned.

Please let me know if you can figure out what is wrong or if I should open a JIRA bug.