jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: Observation design (Was: svn commit: r1351414 - in /jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak: api/ChangeSet.java api/ContentSession.java core/ContentSessionImpl.java)
Date Wed, 20 Jun 2012 14:44:17 GMT
Hi,

On Wed, Jun 20, 2012 at 3:40 PM, Michael Dürig <mduerig@apache.org> wrote:
> Leaving userdata out works for me. Not sure what the "spec police" will say
> though ;-)

To pass the TCK without user data we'll need to set the observation
supported descriptor to false. I'm OK with that as long as we still
implement most of the JCR observation interfaces and document the less
strict observation contract that we are supporting.

If needed, we could propose to JSR 333 to relax the specified
observation contract or at to introduce more fine-grained descriptors
that allow an implementation like ours to declare at least some
observation functionality as supported.

> I'd however like to keep a container for the events (i.e. trees before and
> after). Currently this is called ChangeSet but I'm fine with a different
> name.

Would it be better to pass these things as arguments to a callback
method instead of as a container object returned by a blocking method
call? I find the blocking method a bit troublesome as it requires a
separate thread for each listener.

As another design alternative, the Validator mechanism we have in
.core.spi.state suggests a very similar Observer pattern (essentially
just a Validator without the option of throwing
CommitFailedExceptions) that could be used by a plugin to directly
generate JCR-level observation events without having to go through the
Tree abstraction in the Oak API. That would allow us to directly
leverage the existing diffing tools and other machinery for
NodeStates.

BR,

Jukka Zitting

Mime
View raw message