We are using hibernate 3.3, so this would be useful for us too.
not really, this branch isn't maintained apart from support cases.
You can try merging the changes back and sending me a patch - if all tests pass, I'll commit and deploy a new version.
I think I can do that... I will be back with this in a few days.
great news. Thanks a lot for your effort. Looking forward to your results.
Here is the patch for updating envers 3.3 branch.
Some things can´t be merged because incompatibility between core 3.3 and core 3.5:
- AuditProcess vs AuditSync.
- ExceptionListener doesn´t expect RuntimeException since JDBCTransaction eats exceptions and it can´t be done on hibernate 3.3.
- LoadQueryInfluencers in class AbstractDelegateSessionImplementor.
- LockOptions in AbstractAuditQuery.
- Different usage of getIdentifier() from EntityName in Tools.getIdentifier(). Uses session.getEntityMode() instead of session.
- Definition of @Type on EmbIdWithCustomType.customEnum for work correctly.
The list of the resolved are issues are (tentative):
HHH-4716: NotAuditedException using the entity name concept of hibernate.
HHH-5288: Envers auditReader.find() returns wrong data for embedded components using fields with default values
HHH-3957: Audited Null Embeddable objects not returned as null
HHH-5191: CollectionMetadataGenerator fails to obtain mappedBy attribute when is defined on superclasses
HHH-4899: Type not supported: org.hibernate.type.TimestampType
HHH-4928: Non-Audited Entity with @ManyToOne in PK causes error in Envers 1.2.2
HHH-4731: Public API to know if an entity class is audited
HHH-4900: Wrong immutable type check in IdMetadataGenerator
HHH-4792: Validate fix for HHH-4791
HHH-4693: MapProxy - problems during marshalling/demarchalling
HHH-4793: Revert disabling of VersionsJoinTableRangeComponentNamingTest and fix underlying issue
HHH-4063: NPE reading metadata from an mapped interface
I hope it will help. Hernán.
envers3.3UpdatePatch.txt.zip 19.0 KB
- AuditProcess vs AuditSync.
I just applied the patch and built Envers and everything is working fine.
Thanks for your work!
Great! We are using this patched version too.
@Adam: Did you have time to take a look to the patch?
How did you manage to build envers with this patch?
I've applied the patch successfully but when I try to build the artifact the resulting jar seems to have a custom extension:
And of course it doesn't work when I reference this artifact in my project's pom...
There are no custom extensions in the patch, only merged code from 3.5 branch as I explained in my post. I've checkouted envers 3.3 branch again, applyed the patch from scratch and it works fine... so I can't tell what´s happening...
I know there's no custom extension in your patch but there's one in Hibernate's parent pom which is referenced in Envers's pom!
How do you build the package (mvn install)?
I used the same procedure as Hernán. Just checked out the 3.3 branch, applied the patch and built it using "mvn install". There were no additional steps needed.
How did you proceed?
I also checked out http://anonsvn.jboss.org/repos/hibernate/core/branches/envers-hibernate-3.3/
and applied your patch which works A1.
But, when installing the main artifact (mvn install) the packaging is overriden by the parent pom plugin
Which sets the artifact handler to use the extension jdocbook-style.
Now, if I use Maven 3.0 Beta 1 everything works as it should, but using Maven 2.2.1 the deployed
artifact gets a .jdocbook-style extension. I am not sure if this is the famous bug talked about
I need to investigate this further.
One thing I noticed is the plugin components.xml uses <extension>jdocbook-style</extension>
and <packaging>jar</packaging>. The handling seems to have changed (for the better...).
Ok there seems to be a problem (bug?) with a plugin that Hibernate use and Maven 2.2.1 / JDK 6 which causes the issue I'm having.
So it works with:
- Maven 2.2.1 / JDK 5
- Maven 3 Beta / JDK 6
But it doesn't work with:
- Maven 2.2.1 / JDK 6
Hope this helps!