From users-return-10505-apmail-jackrabbit-users-archive=jackrabbit.apache.org@jackrabbit.apache.org Wed Feb 04 23:43:18 2009 Return-Path: Delivered-To: apmail-jackrabbit-users-archive@minotaur.apache.org Received: (qmail 60359 invoked from network); 4 Feb 2009 23:43:18 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Feb 2009 23:43:18 -0000 Received: (qmail 85173 invoked by uid 500); 4 Feb 2009 23:43:16 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 85163 invoked by uid 500); 4 Feb 2009 23:43:16 -0000 Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@jackrabbit.apache.org Delivered-To: mailing list users@jackrabbit.apache.org Received: (qmail 85152 invoked by uid 99); 4 Feb 2009 23:43:15 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Feb 2009 15:43:15 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of aklimets@day.com designates 207.126.148.183 as permitted sender) Received: from [207.126.148.183] (HELO eu3sys201aog003.obsmtp.com) (207.126.148.183) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 04 Feb 2009 23:43:08 +0000 Received: from source ([209.85.198.226]) by eu3sys201aob003.postini.com ([207.126.154.11]) with SMTP ID DSNKSYon9Y3ClWgZvDtN1JzBfqTpBmu598C1@postini.com; Wed, 04 Feb 2009 23:42:47 UTC Received: by rv-out-0506.google.com with SMTP id b25so2616327rvf.49 for ; Wed, 04 Feb 2009 15:42:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.134.10 with SMTP id h10mr3964213rvd.287.1233790964664; Wed, 04 Feb 2009 15:42:44 -0800 (PST) In-Reply-To: References: Date: Thu, 5 Feb 2009 00:42:44 +0100 Message-ID: Subject: Re: How to use a different implementation of ObservationManager? From: Alexander Klimetschek To: users@jackrabbit.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On Wed, Feb 4, 2009 at 6:32 PM, Vincent Massol 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 implementation. Hope that helps, Alex -- Alexander Klimetschek alexander.klimetschek@day.com