This link might be handy
http://forum.hibernate.org/viewtopic.php?t=961283&highlight=auditing
However if what you want to do is perform auditing, it would be better to define audit fields for your entities (createdBy, createdDate, lastModifiedBy, lastModifiedDate). I typically include these in a root class that all persistable objects extend.
When you perform auditing by the domain objects, your audit records reflect your business/domain objects more closely. You can make sense of what domain object is being changed instead of tracking this at the table level. For example you can find things like "Address was changed by usera at timea, the property field changed along with old and new values". Columns in my audit table can be
audit_id, entityChanged_id, entity_name, property_changed, old_value, new_value.
Contrast the above to having to look at a database audit trail as the one generated by Oracle, you have to mentally map what combination of tables make up your domain entities before you can know who changed what.
There are a few examples in the forum. Search for "Audit Interceptor". However, I have used interceptors but since the Event mechanism was introduced, I think they (events) would produce a cleaner solution.
The
Hibernate In Action book has a section on auditing. BTW buy the book, I think the Hibernate authors deserve it :)[/quote]