4 Replies Latest reply: Apr 26, 2012 1:27 PM by Brad Hunter RSS

Remoting JCR API

Francisco Carriedo Scher Newbie

Hi there,

 

i am trying to set up an architecture and the operations i am seeking to perform are just creating nodes, setting their properties, setting (and removing) links between them. Nothing special, since this is pretty simple through the JCR API, but not remotely. A remote version of JCR API is exactly one of the interfaces i want to provide (for developers like me), but i didn't find (so far) a way to obtain a javax.jcr.Repository and work with javax.jcr.Node instances through REST or Webdav interface.

 

Precisely what i am trying to obtain is the same interface i got when using Jackrabbit's webdav interface:

 

...

 

String repoURL = "http://...";

javax.jcr.Repository repository = JcrUtils.getRepository(repoURL + "/server");

javax.jcr.Session session = repository.login(new SimpleCredentials("admin", "admin".toCharArray()));

javax.jcr.Node actualNode;

 

// do stuff with nodes

 

session.save();

...

 

So far i tried to do something similar with the REST API, but there are only some methods on the Java side (publish, unpublish, getURL...). Such methods are quite useful for other of the facets of the system i am trying to build up, but i am missing the easy-to-use of the JCR API for the developing tasks on the remote options.

 

 

Am i missing something? Any useful info, pointer, whatever?

 

Thanks in advance for your attention!

  • 1. Re: Remoting JCR API
    Randall Hauch Master

    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
    Torsten Witte Newbie

    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
    Randall Hauch Master

    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
    Brad Hunter Newbie

    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.