Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 63947 invoked from network); 1 Mar 2010 15:42:32 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 1 Mar 2010 15:42:32 -0000 Received: (qmail 43403 invoked by uid 500); 1 Mar 2010 15:42:31 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 43367 invoked by uid 500); 1 Mar 2010 15:42:31 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 43360 invoked by uid 99); 1 Mar 2010 15:42:31 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Mar 2010 15:42:31 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of aklimets@day.com designates 207.126.148.89 as permitted sender) Received: from [207.126.148.89] (HELO eu3sys201aog103.obsmtp.com) (207.126.148.89) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 01 Mar 2010 15:42:21 +0000 Received: from source ([209.85.220.216]) by eu3sys201aob103.postini.com ([207.126.154.11]) with SMTP ID DSNKS4vgSdqp1yFQ2iSb2Ckj66lhFqSYw70L@postini.com; Mon, 01 Mar 2010 15:42:01 UTC Received: by fxm8 with SMTP id 8so2481483fxm.31 for ; Mon, 01 Mar 2010 07:42:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.4.145 with SMTP id 17mr5205117far.17.1267458120895; Mon, 01 Mar 2010 07:42:00 -0800 (PST) In-Reply-To: <91f3b2651003010542g462a7cc3s85d5ac86325c333@mail.gmail.com> References: <91f3b2651002280740y14b1ecdas5ed1f035870bbdea@mail.gmail.com> <91f3b2651002282141g183b7575u574978d130fd251e@mail.gmail.com> <91f3b2651003010250i192413f1rf110b14081aa1693@mail.gmail.com> <91f3b2651003010542g462a7cc3s85d5ac86325c333@mail.gmail.com> Date: Mon, 1 Mar 2010 16:42:00 +0100 Message-ID: Subject: Re: [jr3] Delayed Repository Initialization From: Alexander Klimetschek To: dev@jackrabbit.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Mon, Mar 1, 2010 at 14:42, Thomas M=FCller wrot= e: >> Couldn't this be done by a special wrapping Repository implementation? > > That's problematic. Such a wrapper would have quite some overhead. The > JCR API is not easily "wrapable" if you want to do it correctly: you > would have to wrap almost every JCR interface and method, including > Node and Property. Only if you want to support credentials from Session.login() to be used dynamically for repository configuration, eg. as credentials for a JDBC connection. If all you want is to support short URLs in the RepositoryFactory.getRepository() you don't need to override Session... and as I just noticed, you can obviously do this in the RepositoryFactory (if it knows about JR's RepositoryImpl and can do dynamic configuration). So my +1 was a bit off... I don't see much use in this atm. If it is easy to change jr to "allow" for lazy initialization along the way, ok, but I wouldn't see this as having less priority compared to other planned changes in j3. Regards, Alex --=20 Alexander Klimetschek alexander.klimetschek@day.com