Grouper Developers Forum

["Tom Zeller" <>]

On Mon, Jun 2, 2008 at 4:23 AM, GW Brown <> wrote:

I think we need to be very clear on what we are trying to achieve with auditing since it impacts greatly on our approach.

Tom B. has suggested that we use reliable (guaranteed) auditing as a way of recording changes such that these changes can be used to drive potentially less reliable notifications. Effectively, if a notification fails it might be reconstructed / queried for by a 'listener' system. So, in Java, we will have a representation of a change which can be 'serialised' to the audit database. It should then be possible to re-constitute the Java representation of the change from the data in the audit database.

I'm not clear on reliable vs less- or un-reliable auditing. I understand the notion of serializing a (java) change to an audit database, but I don't understand where 'guaranteed' fits in. Clues ?

I am also uncomfortable with the idea of using the file system to store changes largely because the API can easily be run in different JVMs on different machines which would need to mount the same file system and be properly configured.

And being one of those sites with multiple JVMs writing to grouper, I certainly should have realized that our data access protocol is (essentially) JDBC, hence data stored outside the database would need another way to get to it at the cost of additional complexity. Memphis' person registry has a similar setup to grouper and sometimes I wish we had written a service which wrapped (hid) the underlying database connections.

TomZ