From users-return-4881-apmail-jackrabbit-users-archive=jackrabbit.apache.org@jackrabbit.apache.org Sat Sep 08 09:07:29 2007 Return-Path: Delivered-To: apmail-jackrabbit-users-archive@locus.apache.org Received: (qmail 79398 invoked from network); 8 Sep 2007 09:07:28 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 8 Sep 2007 09:07:28 -0000 Received: (qmail 26211 invoked by uid 500); 8 Sep 2007 09:07:22 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 26196 invoked by uid 500); 8 Sep 2007 09:07:21 -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 26187 invoked by uid 99); 8 Sep 2007 09:07:21 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 08 Sep 2007 02:07:21 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of 1111software@gmail.com designates 209.85.198.189 as permitted sender) Received: from [209.85.198.189] (HELO rv-out-0910.google.com) (209.85.198.189) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 08 Sep 2007 09:07:18 +0000 Received: by rv-out-0910.google.com with SMTP id k20so627278rvb for ; Sat, 08 Sep 2007 02:06:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=JsWm/F0ubsNIS7Ftx+n4XC0YmCYFO43EZqJZp3QIJfo=; b=UhG7AKSrxP1xmlMXHpsG75vlxvjsZ9S1r97Wcx8OZGJMiLCtnRbN5m9beYpYrvbSSmRDsNFHTYJQYxskIAOY/JZ9//2CAZZoQ9+yP/u9yrSziO7txv9MCwl4zh2kdZSEhsJu2NSmL1M0Vwobkh/H9qkp3CvWqZ/pf+ThOoHI/cM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=ciGEzsY4pRe9o3cZpEbk+NAn9Yf3iMNsFobJsx33A4ZBMO3y8srsCsQPevUaLMp9ggkbk4lEIoYYf/uOauryq/2O0psGNZi2iAE9XD2eO/MO3lOlfk3WuQJKeAaqX/AWRcAfA6is0v4xzSV/UtMswnA5xXTAt0X2qAfMVQ+dNQU= Received: by 10.140.132.8 with SMTP id f8mr1064699rvd.1189242417473; Sat, 08 Sep 2007 02:06:57 -0700 (PDT) Received: by 10.141.86.21 with HTTP; Sat, 8 Sep 2007 02:06:57 -0700 (PDT) Message-ID: Date: Sat, 8 Sep 2007 11:06:57 +0200 From: "Jacco van Weert" <1111software@gmail.com> To: users@jackrabbit.apache.org Subject: Re: [OT] JCR and legacy systems? In-Reply-To: <20070907161127.7e1e88db@n428.planconnect.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2031_25233309.1189242417456" References: <20070907161127.7e1e88db@n428.planconnect.net> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_2031_25233309.1189242417456 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 9/7/07, Kristian Rink wrote: > > > Folks; > > > But: I don't have no clue how to get started implementing JCR against a > legacy system. So far, we do have rather clear ideas how the data (and, > thus, the repository) structure inside the DMS looks, how this will > have to look like in JCR, and we're also clear about most of the > infrastructure aspects (user authorization). I'd simply start over > implementing the interfaces provided by the JCR API package and hope > for the best... Is this a sane way to do things? Are there pitfalls > I've not yet taken into consideration? Is it a good idea at all? Or > could I do better by, say, slightly modifying parts of jackrabbit to > just, say, build a virtual repository rather than completely > implementing JCR for our environment? Hello Kristian, I did wrote a number of custom JCR implementations for the company I work for. Like Jukka says the problem lies with the "write" access. Creating a read only JCR interface is not that difficult if you only want to have simple NodeIterator/PropertyIterator access. I used my own JDots framework (http://jdots.sourceforge.net) to build the in-memory JCR tree, with JDots it's also more easier to create a write repository. The other problems; - node/propertytype definitions, it is doable to create a write-JCR repository without the JCR nodetypes constrains especially if your legacy provides these constrains themselves. - searching, well I guess that is a real problem because it's quite hard map the JCR standard search mapping to your legacy system. I choose to just define my own search language, more or less adapting the legacy system search. The big advantage of having a JCR interface to you legacy system is to have a seamless transition to a full JCR repository. Greetings, Jacco -- > ------------------------------------- > Jacco van Weert -- 1111software@gmail.com > JCR Controller -- http://www.xs4all.nl/~weertj/jcr ------=_Part_2031_25233309.1189242417456--