How is your JPA accessed? I have done JPA, and Audit logging on top of it, but it was into XML files, and performed in a EJB3 Session Bean. The JPA objects were plain simple, but they were all accessed via a Session Bean Facade. I did it with XML because boss wanted so, but could have been database as well.
7.7.2011 19:49, Bengt Rodehav kirjoitti: > I actually use the same approach as Hades for createdBy, updatedBy, > createdWhen and updatedWhen. In addition to this basic audit logging I also > want to log all historical versions together with information about who > updated the object. > > I've read a little bit about Envers. I didn't want to bring it up since this > is an OpenJPA mailing list. It does look interesting but I think it requires > Hibernate which I do not intend to go back to. (I'm actually moving away > from Hibernate). Also, I'm a bit hesitant to store "copies" of my rows in > special audit tables since it also means database migration of those tables. > I think serializing the audit log entries and putting them in one column is > a better approach from a maintenance perspective. > > But it would be nice if OpenJPA would provide a callback or some mechanism > (even if it's not standard JPA) that would allow further updates/inserts in > a callback. > > Are there any such plans? > > /Bengt > > 2011/7/7 Andrew Thompson <at2...@columbia.edu> > >> You might take a look at how hades >> ( >> http://hades.synyx.org/static/2.x/site/org.synyx.hades/reference/html/auditing.html) >> does something close to what you're describing. Or >> http://www.jboss.org/envers >> >> -Andy >> >> On Thu, 2011-07-07 at 15:35 +0100, David Goodenough wrote: >>> On Thursday 07 Jul 2011, Bengt Rodehav wrote: >>>> I'm using OpenJPA for persistence and would like to audit log any >> changes >>>> made to my entities. I serialize the objects to JSON (with Gson) and >> store >>>> them in a separate table in the database. Since the audit log needs to >> have >>>> the correct id's, the audit logging must take place after the entity >> has >>>> been persisted. >>>> >>>> I was hoping I could use the @PostPersist and @PostUpdate life cycle >>>> callbacks for this. I do seem to have the right information available >> and >>>> the serialization works fine but I don't know how I can persist my >> audit >>>> log entries at this point. From what I've read, I'm not allowed to use >> the >>>> entity manager in a "Post" lifecycle callback which of course makes >> this >>>> hard. >>>> >>>> What do you recommend? Is there a good place in JPA/OpenJPA where I >>>> automatically can trigger the storing of an audit log entry as >> described >>>> above. Of course I can move this logic up from the persistence layer to >> a >>>> place where I can first have the entity manager persist my entity and >> then >>>> explicitly call another service to do the audit log. However, this is a >>>> pretty general mechanism that I would like to have automatic support >> for in >>>> my framework which is why I would like to have it pushed down into the >>>> persistence layer. >>>> >>>> Any ideas? >>>> >>>> /Bengt >>> You could of course cheat. >>> >>> While you can not access the entiry manager, there is nothing to stop you >>> using JDBC. It would probably not be a good idea to access a table that >>> JPA is using, but if this audit trail is write only for this app and only >>> read elsewhere that would solve the problem. >>> >>> David >> >> > -- Q: What's the difference betweeen USL and the Graf Zeppelin? A: The Graf Zeppelin represented cutting edge technology for its time.
signature.asc
Description: OpenPGP digital signature
