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]
