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 [EMAIL PROTECTED] so i can include it in our digest. regards, david On 8/16/07, Felix Meschberger <[EMAIL PROTECTED]> 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 > > ;-) > >
