Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of bdelacretaz@gmail.com
 designates 209.85.146.177 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth;
        b=S7+L3LS4mwFToK2HH51CEe4Y2WKQfvIufltjMlrXD8bsSCj/u1w4t4KmGX/MkUTVvHSaWKlc9kVWTNTzrr2hfUm5XQPXtixl2IPw16pT6f6CuhR3tGinbFq8gY94ehMJQD7f3VzKKumEmv29pYNVrTPDXOa00sdSXKYDohOgTQI=
Message-ID: <f767f0600708170252u287d6ce1sb41c7876f90beeb0@mail.gmail.com>
Date: Fri, 17 Aug 2007 11:52:38 +0200
From: "Bertrand Delacretaz" <bdelacretaz@apache.org>
Sender: bdelacretaz@gmail.com
To: jsr-283-comments@jcp.org
Subject: JSR 283: EventCargo API suggestion
Cc: dev@jackrabbit.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,

(ccing dev@jackrabbit.apache.org as we have discussed this there, see [1])

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.

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.

I think the following additions to the JCR API would make this much easier:

1) A new Session.setEventCargo(EventCargo) method, causes the supplied
EventCargo to be used for all Events generated by this Session from
now on.

2) A new Event.getCargo() method, returns the EventCargo that was set
in the Session when this Event was generated, or null if none set.

3) The EventCargo class provides set/getUserData() methods to attach
any Serializable to it. Serializable is required to be able to store
the EventCargo to a transaction/clustering journal, and the EventCargo
implementation must be Serializable as well.

The idea is to use setEventCargo to indicate what is currently
happening at the application level (user is editing data, automatic
process is generating additional nodes, etc) to make it easier to
analyze the generated Events.

Thanks for considering this suggestion - apart from my personal
experiences, we've had a several related user requests on the
Jackrabbit mailing lists, where this would help a lot.

-- Bertrand Delacretaz
-- bdelacretaz@apache.org
-- http://www.codeconsult.ch

[1] http://preview.tinyurl.com/35rrg8