thanks a lot! Fixed.
No Problem Adam,
I observe the envers-upgrowth for some time now and beside fixed some bugs in 1.1.0 on my own - but you already fixed them in the latest revision, so there was no need to write a patch. Even though I didnt get your code complete, I am impressed what your have done so far! :)
ByTheWay: A nice feature would be a kind of TemporalEntityManager, were u can save an entity directly together with the revisionEntity.
tempManager.merge(myFooEntity,new MyRevEntity(somePerson, someChangeReason));
So u dont have to lookup anything in the RevisionListener and u can easy pass some revision-information from the front to the back.
just an idea, maybe crap :)
the idea might be quite good :). That's true that the current way of handling revision entities is not always very convenient.
Maybe just this would be enough:
The method would return the current revision entity, letting you to fill any of the custom fields. The create parameter would specify if a revision entity should be created, even if no audited entities have been modified.
What do you think?
How does this map in hibernate.cfg.xml?
In 1.1, I was able to use the
<event type="post-insert"> <listener class="org.jboss.envers.event.VersionsEventListener" /> </event>
but I can't seem to adapt it.
Instead, I'm getting
Caused by: java.lang.NullPointerException
you should just use:
<event type="post-insert"> <listener class="org.hibernate.envers.event.AuditEventListener" /> </event>
for all the events.
The NPE looks like a bug. Can you post your entities and configuration? Or even better, create a testcase and attach it to a JIRA bug?
sry for the late reply...
Your idea to put the functionality into the AuditReader looks good. :) Do u plan to implement it?
I suppose yes :). Maybe you can create a feature request in JIRA?