Thanks to all who replied. The brick wall that I ran into was the need to cast to Jackrabbit-specific types. And this doesn't work since all of the stub objects only implement the JCR interfaces. For example, Jackrabbit has an extension to AccessControlEntry that can deny (rather than allow). (I didn't end up using DENY functionality but it's good for illustration purposes.) So to summarize, any framework that proxies the JCR API was not going to work for me.
http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/security/AccessControlEntry.html http://jackrabbit.apache.org/api/1.6/org/apache/jackrabbit/core/security/authorization/JackrabbitAccessControlEntry.html On Mon, 2010-01-04 at 15:38 -0700, ChadDavis wrote: > On Fri, Jan 1, 2010 at 8:09 AM, Mat Lowery <[email protected]> wrote: > > 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. > > > > I've been through this. While I haven't quite gotten my head around > it all, I think I know where to point you. It seems that the current > best way to do model 3, a.k.a. a remote server, is with an SPI layer > over the webdav server. The webdav aspect of this seems entirely de > defacto, at least it escapes me why it's this way. I would have > expected an SPI layer directly over the Jackrabbit core, perhaps I'm > missing something. > > The SPI layer seems intended purely for a clean separation of server > and client layers in server type scenario. > > Here's a link to one of my threads that, while a bit overwhelming in > the scope of topics it touches on, does contain some useful > information. BTW, I'm in the middle of this right now. So, I'd love > to share any insights as you move along.
