Return-Path: Delivered-To: apmail-jackrabbit-users-archive@minotaur.apache.org Received: (qmail 65702 invoked from network); 4 Jan 2010 20:35:56 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 4 Jan 2010 20:35:56 -0000 Received: (qmail 95127 invoked by uid 500); 4 Jan 2010 20:35:56 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 95075 invoked by uid 500); 4 Jan 2010 20:35:55 -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 95064 invoked by uid 99); 4 Jan 2010 20:35:55 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Jan 2010 20:35:55 +0000 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: local policy) Received: from [12.107.188.150] (HELO mx1.compuware.com) (12.107.188.150) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Jan 2010 20:35:49 +0000 Received: from nasa-dtw-ex009.nasa.cpwr.corp (unknown [10.10.0.230]) by mx1.compuware.com (Postfix) with ESMTP id 69F7072D362 for ; Mon, 4 Jan 2010 20:35:24 +0000 (GMT) Importance: normal Priority: normal Received: from nasa-dtw-ex005.nasa.cpwr.corp ([10.10.1.109]) by nasa-dtw-ex009.nasa.cpwr.corp with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Jan 2010 15:35:24 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Subject: RE: remote JCR Date: Mon, 4 Jan 2010 15:35:24 -0500 Message-ID: <399DA4AB3471814AA1A85085EC6B4E33046BE2F3@nasa-dtw-ex005.nasa.cpwr.corp> In-Reply-To: <1262358562.2545.26.camel@fitz-hume> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: remote JCR Thread-Index: AcqK9HvIv+vshf0lQ+meaN+3tGjrwgCiKLsQ References: <1262358562.2545.26.camel@fitz-hume> From: "Hyaduck, John" To: X-OriginalArrivalTime: 04 Jan 2010 20:35:24.0742 (UTC) FILETIME=[71754660:01CA8D7D] We have been testing JCROM over http to WebDAV (jcr2spi, spi2dav) and = the lower level functions (locking, etc.) seem to work alright. The = JCR API gets translated to SPI html commands that WebDAV then processes. = Anyone else experimenting with this? =20 The contents of this e-mail are intended for the named addressee only. = It contains information that may be confidential. Unless you are the = named addressee or an authorized designee, you may not copy or use it, = or disclose it to anyone else. If you received it in error please notify = us immediately and then destroy it. From: Mat Lowery [mailto:mlowery@pentaho.com]=20 Sent: Friday, January 01, 2010 10:09 AM To: users@jackrabbit.apache.org Subject: remote JCR I'm trying to wrap my head around Deployment Model 3: Repository Server. Can anyone confirm that my understanding is accurate? My understanding is that there are two ways to access a repository remotely: RMI and WebDAV. If you want to use the JCR API, you use RMI. Otherwise you use WebDAV. But by using WebDAV, you lose access to the low level node operations that you would otherwise have access to in the JCR API. Let's assume that I need access to the low level node operations. So I opt for RMI. However, there is a statement on http://jackrabbit.apache.org/repository-server-howto.html that says: "Warning: The current JCR-RMI library is designed for simplicity, not performance. You will probably experience major performance issues if you try running any non-trivial applications on top of JCR-RMI." Does performance suffer because each and every node operation (e.g. addNode and setProperty) involves a communication with the server? In this case, it seems that the best option is to expose my own service (backed by a local Jackrabbit) for remote access. In this way, there is far less communication with the remote service (i.e. my service) since my objects would be far less granular than nodes. This is probably obvious to most but it took me a while to figure it out what my options were. Can anyone comment? Thank you.