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 ;-)
