jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Nuescheler" <da...@day.com>
Subject Re: [RT] JCR observation: adding "cargo" data to events?
Date Thu, 16 Aug 2007 09:48:32 GMT
hi bertrand,

i agree that this would be interesting, and could get us to a certain extent
out of the method events issue.

if you dont mind and others feel like this would be a valuable addition
you could eventually send this as a public review  comment to
jsr-283-comments@jcp.org so i can include it in our digest.

regards,
david


On 8/16/07, Felix Meschberger <fmeschbe@gmail.com> wrote:
> Hi,
>
> 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
> handle.
>
> To come around the clustering issue, it might be defined, that the cargo
> should be serializable.
>
> Regards
> Felix
>
>
> 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 ;-)
>
>

Mime
View raw message