openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bengt Rodehav <>
Subject Re: Audit log with OpenJPA
Date Fri, 05 Aug 2011 14:28:04 GMT

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.


2011/8/2 Pinaki Poddar <>

> 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:
> Sent from the OpenJPA Users mailing list archive at

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message