jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@gmail.com>
Subject Re: [RT] JCR observation: adding "cargo" data to events?
Date Thu, 16 Aug 2007 09:32:34 GMT

This would probably really be worth it. I also think of somehow
"tagging" the operations for example to provide more information in case
of item removal, where very little is actually available in the event
leading to guessing or having to keep caches.

On the other hand, save operations may encompass a whole number of
possible unrelated tasks, but this might be something for the user to

To come around the clustering issue, it might be defined, that the cargo
should be serializable.


Am Donnerstag, den 16.08.2007, 11:24 +0200 schrieb Bertrand Delacretaz:
> Hi,
> (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
> problem.
> 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