jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bertrand Delacretaz" <bdelacre...@apache.org>
Subject [RT] JCR observation: adding "cargo" data to events?
Date Thu, 16 Aug 2007 09:24:31 GMT

(this might be more a question for the JSR283 people, but I'd like to
have this community's opinion)

I recently implemented a JCR-based audit trail module, and making
application-level sense of the Events that an EventListener receives
required quite some efforts (and lazyness is a virtue, not? ;-)

In a real-life app with both human users and automated processes
generating JCR data, an EventListener is bombarded with Events that
sometimes make little sense at the application level, and sorting them
out to create a meaningful audit trail can be tricky.

See also the recent "How to figure out if there was a rename operation
on Node" thread on users@ (http://tinyurl.com/2qfbt3) for a similar

This event analysis would be much easier if the save operations could
be enhanced with some "cargo" Object, that is opaque for JCR, but
passed on to Events to give more info about what's happening at the
application level.

Here's my suggestion (which would need changes to the JCR spec):

Maybe session.save() and other save() methods could take an optional
Object parameter, that is made available in the observation Event with
a new getCargo() method?

This object can be used, for example, to indicate that the nodes being
saved are autogenerated by some metadata extractor, to mark the Events
as such in an audit trail, separating them from Events that indicate
"human user" actions.

I'm wondering if this might be a valid suggestion for JSR-283, what do
people think?

I haven't seriously evaluated the implications at the implementation
level, this might be tricky to implement in clustered settings
(although the cargo could probably be saved in the journal).

-Bertrand, nostalgic about the "cargo" concept in Clipper code circa 1987 ;-)

View raw message