jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <aklim...@day.com>
Subject Re: How to use a different implementation of ObservationManager?
Date Wed, 04 Feb 2009 23:42:44 GMT
On Wed, Feb 4, 2009 at 6:32 PM, Vincent Massol <vincent@massol.net> wrote:
> The JCR API encompasses lots of APIs from different domains (Mode, Storage,
> Observation, Query, Authentication, etc) and I'm interested in keeping some
> of our implementations for those. Specifically we already have an
> Observation component that I'd like to be able to reuse since it's more
> generic than the API offered by the JCR (we use it for events other than
>  events generated by the Model).
> I was wondering what was the best way to use introduce a bridge
> implementation that would bridge between the JCR API and our API.
> I haven't found any configuration property in the jackrabbit xml file to
> specify what implementation to use for the ObservationManager interface
> (might this be a good thing to add?).

No, I think the ObservationManager is nothing that should be
extendable, since it is completely defined by the spec and is
integrated deeply into Jackrabbits internal implementation. The events
it throws are tight to the JCR data model and not generic.

The case that it is an interface comes from the clean definition of
the JCR API, which is almost 100% interfaces, it doesn't imply that
everything is/should be pluggable (like the new UserManger and
AccessControl stuff or the PersistenceManager - but these are
Jackrabbit component interfaces, not from the JCR spec).

I would solve your case by having your custom observation manager
register a JCR observation listener for all events and handle those
together with your other events and propagate them in some way. This
way you are also JCR compatible and are not locked into Jackrabbit's

Hope that helps,

Alexander Klimetschek

View raw message