-
1. Re: Remoting JCR API
rhauch Mar 12, 2012 9:22 AM (in response to fcarriedos)We have a WebDAV interface that you could try, but I don't think it has all the features of Jackrabbit's. Give it a try. It may even be possible to try to plug Jackrabbit's WebDAV interface on top of ModeShape, if they did a good job of using writing the WebDAV component to use only the JCR API.
-
2. Re: Remoting JCR API
witte.subshell.com Apr 13, 2012 9:05 AM (in response to rhauch)Remote access via the javax.jcr-API to a ModeShape repository located in an application server would be very nice. I want to develop an adapter for our JCR tool Toromiro (which requires the javax.jcr-API) to connect to such repositories, but REST and WebDAV doesn't seem to be an option for that case.
-
3. Re: Remoting JCR API
rhauch Apr 13, 2012 9:36 AM (in response to witte.subshell.com)I do agree that it's a good idea to have, so I just logged MODE-1459 to explicitly cover this. Feel free to discuss requirements, use cases, etc. on that issue.
-
4. Re: Remoting JCR API
bhntr3 Apr 26, 2012 1:27 PM (in response to rhauch)I started to post this on the issue but thought maybe it was better here.
I have two use cases in an application I'm currently developing that would make this ideal. I think any of the four approaches you suggest would meet my needs. I'm thinking of the JCR as a replacement for a remote data store though, so perhaps #2, which delegates the problem to Infinispan, is the one that makes the most sense to me.
First of all, my current non-JCR architecture has developers independently running Tomcat. Each of their machines connects centrally to a RDBMS and Mongo DB. I'm adding JCR to replace some of the RDBMS functionality for content but I like the developers being able to check out and run the war (using embedded Tomcat) without needing to install Mongo or configure anything. With Modeshape, the repository runs inside the Tomcat container right now, so I'd either have to use clustering with JGroups on a single data store (RDBMS with JPA) or have each developer using their own filesystem persistence. Since the application is collaborative, it's not ideal to have each of the developers' dev environments siloed. I'm not really sure ad hoc clustering with JGroups would work or is ideal. Preferably, I'd put Modeshape 3 + Infinispan (or just Infinispan) on the same server as my Mongo DB and have each Tomcat connect to that single instance. This is also my ideal setup for production as I can put large amounts of RAM on the Mongo/Infinispan machine/machines to speed up their in-memory performance and then cluster them independently of my JEE container. Moreover, current startup time on an empty Modeshape DB is pretty slow which is not ideal when bouncing the server often during development. I can probably tweak that by messing with settings (disabling re-indexing?) but it's still an issue. A remote client would probably be much faster to start up. So, for dev, this would be great.
The second use case is that I have a batch processing architecture for performing ETL off a data warehouse which needs to interface with the JCR to push in content. I'd prefer to re-use some of my lower level JCR access code to improve performance (rather than connecting to high level web services in Tomcat), so ideally I could run this process on a separate machine from Tomcat but connect to the JCR transparently. Currently, I would either have to run this process in the same container as my application with Modeshape exposed through JNDI or I would have to do something with clustering. Ideally, I could spawn short-lived non-JEE processes to do my ETL without launching the full infrastructure of a Modeshape repository and still able to use the JCR API.
Overall, I really like the idea of using Modeshape 3 for the performance benefits, sequencing, Infinispan with easy clustering if I need it and the Infinispan Mongo connector so I can store my content in MongoDB. But I think I'm going to have to stick to Jackrabbit and its remoting until this feature is implemented. There's also the benefit of the repository tools from Day primarily supporting Jackrabbit and the fact that Jackrabbit has inherent support for ACLs at the node level. Those last two aren't dealbreakers for me with Modeshape, but I think this remoting issue is.