Pinaki, I've been on vacation again for a week which is why I'm late replying.
I think there must be a way to get hold of the "original" object since that's the object I need to audit log. An unmanaged POJO is fine for my purposes since I just want to serialize it. I will then persist it to a separate audit log table using JPA as I showed before. Just providing the dirty fields is not enough for most people's audit logging requirements (in my opinon...). It seems to me there are two main routes to go here: a) Provide the plumbing necessary for developers to roll their own audit log. Then the following is needed: - Access to the current and previous versions of the POJO (since I want to log the whole previous version) - Information about what fields are dirty (if you only want to log what has been changed) - Support for creating new persistent entities in the life cycle callback. Ideally using the same entity manager. At least it must be possible to use the same transaction otherwise the audit log will not be reliable. b) Provide audit logging capabilities out-of-the-box. I think this is what Envers does. The implementation details are hidden but the developer is given an audit logging API to use. I would of course like to configure the audit logging more than what is possible in Envers. E g I would perhaps like the possibility to serialize my entities instead. Also, more options regarding what fields to log would be nice. These two routes need not be mutually exclusive. Like I said, if OpenJPA supported something like Envers, that would probably be good enough for me. If not, then I just need the necessary plumbing support to roll my own audit logging with OpenJPA. But I need to know that I'm not using implementation details that might change in the next version of OpenJPA. /Bengt 2011/8/2 Pinaki Poddar <ppod...@apache.org> > Hi Bengt, > It is possible (with some effort :) to offer a different POJO y that holds > the original state of a managed POJO x *when* x entered a persistence > context. But y can not be managed by the same context, because x is already > present in that context. So y will be essentially an unmanaged (not even > detached) instance. > > Because of that conceptual dilemma, I went for the option of offering only > the dirty field values. It is also possible to offer all field values. > > ----- > Pinaki Poddar > Chair, Apache OpenJPA Project > -- > View this message in context: > http://openjpa.208410.n2.nabble.com/Audit-log-with-OpenJPA-tp6557932p6645998.html > Sent from the OpenJPA Users mailing list archive at Nabble.com. >
