[RT] JCR observation: adding "cargo" data to events?

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

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

Re: [RT] JCR observation: adding "cargo" data to events?

[Jukka Zitting <ju...@gmail.com>]

Hi,

On 8/16/07, Felix Meschberger <fm...@gmail.com> wrote:
> Am Donnerstag, den 16.08.2007, 15:01 +0300 schrieb Jukka Zitting:
> > For now I'd just put the extra methods directly on the SessionImpl and
> > EventImpl classes. We can formalize them in a jackrabbit-api (or
> > jackrabbit-jsr283) extension interface if they seem useful to a big
> > enough audience.
>
> The problem of not having it in the API someplace, the audience might
> not grow enough :-) Reason: Generally I will not have access to the impl
> classes but just to the api classes ...
>
> Therefore, if consensus would be reached, that this might be usefull, I
> would suggest to add it to the API - and be it in the form of some kind
> of "tentative" API.

Yeah, I'm fine with adding stuff to the API as long as the consensus
is broad enough. I'm just concerned that we don't start putting things
to the API just because they seem like a good idea, and then find out
that the interface needs to be modified in some way or that nobody's
really using it in the end.

>From that perspective it's a better idea to have such extensions first
just as extra methods in the implementation classes and promote them
to API interfaces once we have at least two or three independent users
reporting that they are happy with the additions.

The only problem would be model 2 and 3 deployments where the
implementation classes aren't available to the client. I guess we
could also put such tentative interfaces to snapshot versions of
jackrabbit-api as long as we are ready to take them out before the
next release in case we don't yet have a broad enough consensus.

BR,

Jukka Zitting

Re: [RT] JCR observation: adding "cargo" data to events?

[Felix Meschberger <fm...@gmail.com>]

Hi,

Am Donnerstag, den 16.08.2007, 15:01 +0300 schrieb Jukka Zitting:
> For now I'd just put the extra methods directly on the SessionImpl and
> EventImpl classes. We can formalize them in a jackrabbit-api (or
> jackrabbit-jsr283) extension interface if they seem useful to a big
> enough audience.

The problem of not having it in the API someplace, the audience might
not grow enough :-) Reason: Generally I will not have access to the impl
classes but just to the api classes ...

Therefore, if consensus would be reached, that this might be usefull, I
would suggest to add it to the API - and be it in the form of some kind
of "tentative" API.


Regards
Felix

Re: [RT] JCR observation: adding "cargo" data to events?

[Jukka Zitting <ju...@gmail.com>]

Hi,

On 8/16/07, Bertrand Delacretaz <bd...@apache.org> wrote:
> On 8/16/07, Jukka Zitting <ju...@gmail.com> wrote:
> > ....Have you considered how something like that could
> > be implemented already now as a Jackrabbit-specific extension?...
>
> One idea (that might also be better than my former proposal for
> JSR283) would be to add an additional setEventCargo(Object) method to
> the JCR Session, instead of having to modify all the save() (and
> move() as Thomas indicates) methods.

Sounds good.

> We could implement this in Jackrabbit by creating two cargo-specific
> interfaces, one for the Session and one for the Event, and having the
> Jackrabbit Session and Event implement these in addition to the
> official JCR interfaces.
>
> Is that in line with how Jackrabbit-specific stuff is done now, or do
> you have another suggestion?

For now I'd just put the extra methods directly on the SessionImpl and
EventImpl classes. We can formalize them in a jackrabbit-api (or
jackrabbit-jsr283) extension interface if they seem useful to a big
enough audience.

BR,

Jukka Zitting

Re: [RT] JCR observation: adding "cargo" data to events?

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

On 8/16/07, Jukka Zitting <ju...@gmail.com> wrote:
> ....Have you considered how something like that could
> be implemented already now as a Jackrabbit-specific extension?...

One idea (that might also be better than my former proposal for
JSR283) would be to add an additional setEventCargo(Object) method to
the JCR Session, instead of having to modify all the save() (and
move() as Thomas indicates) methods.

All operations that generate Events would then attach this cargo to
them, and the application can call setEventCargo when needed to
indicate what it's doing.

We could implement this in Jackrabbit by creating two cargo-specific
interfaces, one for the Session and one for the Event, and having the
Jackrabbit Session and Event implement these in addition to the
official JCR interfaces.

Is that in line with how Jackrabbit-specific stuff is done now, or do
you have another suggestion?

-Bertrand

Re: [RT] JCR observation: adding "cargo" data to events?

[Jukka Zitting <ju...@gmail.com>]

Hi,

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

Sounds interesting. Have you considered how something like that could
be implemented already now as a Jackrabbit-specific extension?

It would be nice if we had a patch that implements this in current
Jackrabbit so we could see how useful it is in practice before
including it in the spec.

BR,

Jukka Zitting

Re: [RT] JCR observation: adding "cargo" data to events?

[Thomas Mueller <th...@gmail.com>]

Hi,

Clustering: The Object needs to be Serializable. You need to define
what happens if the class does not exist in the 'receiving' end.

Maybe you want to think about operations that don't require save(),
for example Workspace.move(..).

Thomas

Re: [RT] JCR observation: adding "cargo" data to events?

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

On 8/16/07, David Nuescheler <da...@day.com> wrote:

> ...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....

Ok, I'll send this as a public review comment tomorrow, to leave time
for others to comment here.

Thanks for the feedback,
-Bertrand

Re: [RT] JCR observation: adding "cargo" data to events?

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

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 <fm...@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 ;-)
>
>

Re: [RT] JCR observation: adding "cargo" data to events?

[Felix Meschberger <fm...@gmail.com>]

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