jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julian Reschke (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCR-2542) spi2dav: EventFilters not respected
Date Thu, 10 Nov 2011 17:06:51 GMT

    [ https://issues.apache.org/jira/browse/JCR-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13147823#comment-13147823

Julian Reschke commented on JCR-2542:

Summary, after reading lots of code, scratching my head, and conferencing with

JCR2SPI tries to minimize the amount of concurrent subscriptions on the SPI
level (which translate to HTTP SUBSCRIBE/POLL/UNSUBSCRIBE operations over

It does this by creating a single subscription, and potentially changing the
subscription information when needed. The incoming events are then distributed
among the local event listeners according to their filters.

This does work for filters that depend on UUIDs or paths, because this is
information that is part of the JCR events being generated, and consequently
can be filtered when received.

It does not work for things missing from the JCR event API, such as nodetype
information or the isLocal flag.

Or rephrasing this in terms of interfaces: the SPI Event interface provides
more information than we can trivially extract from a (serialized) JCR

Approaches to fix this:

1) Do not rely on this SPI feature in JCR2SPI. Downside: observation gets
more expensive than needed for SPI implementations that do support the

1b) Make the fact that the SPI Events do not have the required functionality
discoverable and have two different code paths then.

2) Fix the SPI implementation, here: SPI2DAV and the Jackrabbit server. If we
could generate the required information on the server, extending SPI2DAV would
be trivial. However, this is hard because over in JCR land, the information we
need is not associated with the event, but the listener.

Thought experiment: we could have two listeners on the server, one for noLocal
= true, one for noLocal = false. Inspecting the events reported to both
listeners in theory would allow us to decide the type of the event (although
it will be tricky to match events from both listeners as we don't have a unique
event id).

The same could be done for listening for specific node types, but of course
it would even be harder.

2b) Alternatively, on the server, we could try to extract more information from
events when we know the specific implementation class (or actually define
an extension interface that provides us with what we want).


> spi2dav: EventFilters not respected
> -----------------------------------
>                 Key: JCR-2542
>                 URL: https://issues.apache.org/jira/browse/JCR-2542
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-spi2dav, JCR 2.0, observation
>            Reporter: angela
>            Assignee: Julian Reschke
> i have the impression that the event filter passed to the event subscription in spi2dav
is not (or not properly) respected.
> marcel, is there a specific reason that you always pass the static SubscriptionInfo constant
(no node type filter, noLocal false) to the SubscribeMethod
> in spi2dav/RepositoryServiceImpl#createSubscription ?
> i guess this is the reason for the failure of
>   testNodeType(org.apache.jackrabbit.test.api.observation.AddEventListenerTest)
>   testNoLocalTrue(org.apache.jackrabbit.test.api.observation.AddEventListenerTest)

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message