[DATAJPA-336] Release 1.3.1 breaks auditing Created: 30/Apr/13  Updated: 04/Jun/13  Resolved: 02/May/13

Status: Closed
Project: Spring Data JPA
Component/s: Core
Affects Version/s: 1.3.1
Fix Version/s: 1.3.2, 1.4 M1

Type: Bug Priority: Blocker
Reporter: Martin Försterling Assignee: Oliver Drotbohm
Resolution: Fixed Votes: 0
Labels: jpa
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive DATAJPA-336 - Copy.zip    
Reference URL: http://forum.springsource.org/showthread.php?136653-Spring-Data-Jpa-1-3-1-RELEASE-breaks-audit-config
Last updater: Trevor Marshall

 Description   

Auditing stops working when using Release 1.3.1, and begins working again when reverting to 1.3.0.

Debugging shows that in AuditingEntityListener, private AuditingHandler<T> handler is null. I suppose it should be injected? The setter for that property is never called and has no references.



 Comments   
Comment by Oliver Drotbohm [ 30/Apr/13 ]

I've updated the Spring Data JPA examples project to 1.3.1 and don't see the auditing tests failing. I've also added additional assertions on the AuditingEntityListener but fail to reproduce the behavior you're describing.

Any chance you can come up with a test case reproducing the issue?

Some additional thoughts:

  • Which Hibernate version are you working with?
  • How do your run your Maven build? There seem to exist some glitches in the current Maven Compiler plugin (>= 3.0) that essentially require to build with clean to let the AspectJ plugin kick in correctly. This should actually affect our build only (so it was the first thing that I thought of reading the ticket) but I just want to sort out the most obvious issues. The example build working seems to indicate that the release as such is fine.
Comment by Martin Försterling [ 30/Apr/13 ]

Hibernate version is 4.2.0.Final, AspectJ-Config is via @EnableAspectJAutoProxy(proxyTargetClass = true)

The Maven build cleans before running integration tests.

The bug occurred when starting an integration test from eclipse. I could reproduce it now when running integration tests during maven build. 1.3.1 reliably breaks auditing while 1.3.0 works.

Sadly I am not allowed to upload my code. I hope somebody else can reproduce and upload a sample.

Comment by Matt Newman [ 01/May/13 ]

I'm having the same problem - Hibernate version 4.1.9.Final.

setAuditingHandler is never called, and handler is null in touchForCreate. Will try to create a simple project and get it uploaded.

I have the issue in Maven tests and when running on a server.

Comment by Matt Newman [ 01/May/13 ]

Example project showing error.

(Run on server, open the homepage to see error)

Change spring.data-version in pom.xml to 1.3.0.RELEASE and it works fine.

Comment by Matt Newman [ 01/May/13 ]

See attachment (sorry for the lack of unit tests).

Comment by Oliver Drotbohm [ 02/May/13 ]

Pulling a fresh copy of the release from Maven Central causes you sample project to reproduce the error. We had issues with the promotion to Maven central which seems to have corrupted the deployed JAR.

I'll issue a 1.3.2.RELEASE ASAP and promote this to Maven central. In the meantime you have two options:

1. Make sure you pull the dependency from http://repo.springsource.org/libs-release as this repo has correct version of the JAR
2. Clone the repo, checkout tag 1.3.1.RELEASE and do mvn clean install

Both these workarounds are unfortunate admittedly, but I should be able to have a 1.3.2.RELEASE out by the end of the day.

Comment by Oliver Drotbohm [ 02/May/13 ]

Just published the release to the Sonatype Nexus. Should be in Maven central in a bit. In the meantime, grab 1.3.2.RELEASE from the SpringSource release repo as listed above.

Comment by Matt Newman [ 02/May/13 ]

That's great, thanks for the quick response!

Comment by Martin Försterling [ 02/May/13 ]

Cheers, Oliver.

Comment by Oliver Drotbohm [ 02/May/13 ]

Just verified you're sample project to with 1.3.2.RELEASE downloaded from Maven Central.

Generated at Wed Oct 16 22:02:37 UTC 2019 using Jira 7.13.8#713008-sha1:1606a5c1e7006e1ab135aac81f7a9566b2dbc3a6.