[
https://issues.apache.org/jira/browse/SLING-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14163283#comment-14163283
]
Tommaso Teofili commented on SLING-3983:
----------------------------------------
here's the thread mentioned by Carsten:
http://markmail.org/message/i2qy6ck22muwe4oc
What I get from there is that 'userData' is always there for local events and
is never there for remote events; in the mentioned edge case local events can
be reported as remote ones and thus without 'userData'.
bq. While I agree that this would be really helpful to add the information, we
must just be perfectly aware of this functional implementation dependency and
make a conscious decision on whether we want to do this.
right, as far as I understand 'userData' is a JCR specific kind of metadata so
in first place should probably add it to both _JcrResourceListener_ and
_OakResourceListener_, if we want it.
Generally speaking I don't see a problem in reporting all the information hold
by JCR events also in the Sling event as event properties (and that would be
the same also for other backends, of course), relying on such properties /
metadata I would say it's an application concern; for example for the
replication use case (SLING-3993) it may be acceptable to live with the
mentioned Oak limitation (which still should be an edge case) as it's only
concerned on local events but of course this doesn't apply generally.
> Make Session UserData available in OSGI Event
> ---------------------------------------------
>
> Key: SLING-3983
> URL: https://issues.apache.org/jira/browse/SLING-3983
> Project: Sling
> Issue Type: New Feature
> Components: JCR
> Affects Versions: JCR Resource 2.3.8
> Reporter: Dominique Pfister
> Priority: Minor
> Attachments: patch.txt
>
>
> In my Sling/Oak server application I'm handling PUT requests from a client
> and create appropriate JCR resources. These PUT requests carry a request ID
> that I'd like to associate with the respective OSGI event I'll be receiving
> some time later. Now I noticed that using the JCR API:
> Session.getWorkspace().getObservationManager().setUserData(String)
> I could store this request ID. This user data gets passed along in Oak's
> CommitInfo (in its Info Map), which Sling's OakResourceListener (in
> org.apache.sling.jcr.resource.internal) receives it in its added(), deleted()
> and changed() methods, but it currently does not package it into the OSGI
> event it sends.
> It would be great if Sling could pass this along with the event, so I do not
> have to create a NodeObserver/JcrEventListener of my own to catch this
> information.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
