JSR 283: EventCargo API suggestion

[Bertrand Delacretaz <bd...@apache.org>]

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

Re: JSR 283: EventCargo API suggestion

[David Nuescheler <da...@day.com>]

Hi Bertrand,

thanks for your comment.

I agree that it is sometimes hard to make sense on an application level
of what operation triggered the creation of an event.
One way of trying to make that more meaningful was the introduction
of "method events" in JSR-283.

I think that an EventCargo API makes for a very interesting option that we
will most certainly consider.

Thanks for your input.

regards,
david

On 8/17/07, Bertrand Delacretaz <bd...@apache.org> wrote:
> 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
>