Well, I'm using Hibernate for persistance, so I guess the implementation would be somehow different. Nevertheless, I'm looking at this solution.
For my understanding, with this approach you monitor the CRUD transactions (via JPA/Toplink features) and audit each CRUD event individually, correct? Brian Trzupek wrote: > > We just did the very same thing. Here is how we did it.... > > We are using JPA/Toplink for our database layer, so our > implementation is highly dependent on that. > > We then used an approach based on this blog entry: > http://tapestryofthoughts.blogspot.com/2007/05/glassfish-and-audit- > logging.html > > Our modification to his approach was (well his doesn't compile on our > version of Toplink , so we changed that): > 1) We implemented the PrincipalAware interface for our Action classes > so that we can use JAAS for authentication and pass the remote User > identity through to the Audit interface (in the Model) and know who > actually did the change. > 2) We incorporated a 'mode' for audit logging. We have things like > AUDIT (where that is a interface driven event, like approving > resource access AUDIT_APPROVE etc), VIEW (where that is another > interface driven event representing that a user 'saw' something) and > general field level CRUD operations on the core entities we wanted > audited. > 3) Then we implemented some specific rules where given AUDIT events > would trigger full field level audits (essentially serializing the > object) in the case where the rule trigger was an event that would > 'have historical significance'. > > I know it sounds a bit gnarly, but is VERY elegant and extensible. > Give it a whirl and let me know if you need any help. > > Thanks, > Brian- > > On Oct 25, 2007, at 1:35 PM, wild_oscar wrote: > >> >> I want to implement an audit trail in my application. Basically, I >> want to >> record every database change, in the form "previous value, new >> value, who >> changed it, when". >> >> I want to debate with you the best strategy in terms of >> minimization of data >> transfer between the browser and the server and server operations. >> >> The user accesses a page and gets data from the database on a form. He >> changes, say, one textfielnd and submits the form. >> >> We now need to see where changes occurred and record them, and >> therefore >> need the old values and new values. >> >> What do you think of different approaches to this problem? My >> current ideas >> are: >> >> 1) Resubmit the first query to get the "oldvalues" on the second >> submission >> and then compare with the new values. Problem I see is that we'll >> have one >> redundant query on each operation (first query to display values to >> the user >> and second query to get the old values again in the database). In >> large >> applications, between the 1st and 2nd queries data may have changed. >> >> 2) Have a hidden field for each value on the display form with the >> oldValue. >> Main problem I see is the increased workload on the jsp page - for >> each >> input field we need to manually have a hidden "oldValue" field... >> >> 3) Storing the oldObject in session right before the first display >> page. >> Workload increases in Session management, to wisely add and remove >> these >> objects from session. >> >> Can you share your ideas, point different approaches or suggest >> improvements >> on the ones I mentioned? >> >> -- >> View this message in context: http://www.nabble.com/Audit-trail--- >> implementation-strategies-tf4692772.html#a13413247 >> Sent from the Struts - User mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Audit-trail---implementation-strategies-tf4692772.html#a13423517 Sent from the Struts - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
