Latest Posts

Archives [+]

JCR? CR!

CMSWatch has commented on JCR and how important it is, that content repositories can be accessed through various languages. I wholeheartedly agree. However, they also write:

But if the API mandates the use of one particular language (such as Java), the Holy Grail of universality immediately takes a hit. Not everyone uses Java, or wants to.

The API itself does not mandate a particular language (if anything, you might have troubles with type conversions). In fact there are a number of projects for integration of JCRs and other languages.

Integration of a JSR-170 compliant repository and a language other than Java can come in 3 flavours (that I am aware of):

  1. Implementation of of the API in another language, i.e. implementation of the spec
  2. Accessing a Java-based JSR-170 implementation through an adapter that maps Java and another language
  3. Accessing a Java-based JSR-170 implementation through REST (i.e. http)

The first route is taken by the open source cms Typo3. In the upcoming version 5 Typo 3 will use its own PHP-based implementation of a JSR-170 compliant content repository. More information about this approach is available here:

The second approach has been chosen by another popular open source cms: Midgard. While Midgard is written PHP it makes makes its content available through the JCR API. JNI is used for the integration.

Further examples of this approach are

  • Getting access to a JCR from .Net (C#) has been described here
  • The Java Content Repository Ice Connector allows access to a JCR from C#, VB, C++, Python, PHP.
  • The PHP-Java-Bridge has been used in the Typo 3 project recently to get access to a Java-based JCR from PHP (before the port mentioned above).

The third way of cross-language access to a JCR is to access the repository via a RESTful API. This is implemented for example in microjax. In microjax the language of choice is Javascript and the data exchange format is JSON.

Are you aware of other endeavours in this area? Please leave a comment.

 

COMMENTS

  • By KoW - 2:53 PM on Jan 02, 2008   Reply
    All fine and dandy, but the "J" is still in the name. This might be a marketing issue, both positive and negative.

    On enterprise level, Java is mostly ok, but for all those "Java suxxors!"-types it is not. Which again might be positive ... :)

    I am rather sure that the inventor of the name "JCR" sometimes whishes to turn back the wheel of time ...
  • By David Nuescheler - 3:03 AM on Jan 03, 2008   Reply
    Hi KoW,<br><br>

    as a matter of fact I wish I could travel back in time (well who wouldn't) and I am convinced that there are things in JCR that we would have gone about differently in hind sight.
    <br><br>

    Putting the letter J into something that in the end is a specification for the Java space is something that I probably still not really want to change I think.<br>
    Even if it is applicable and used in many other languages.<br><br>

    The reason why this is a specification for the Java space is not so much based on the fact that most large CMS vendors support Java or that we like Java as a language, but it really is based on the existence of a working and efficient standards body (the JCP) that has an excellent track record on getting stuff done and implemented. <br>
    This is pretty unique about the Java space.<br><br>
    So it really is a matter of feasibility to bring an expert group together to work on a standard that will be implemented in a reasonable timeframe...<br><br>

    Since I have been asked this question numerous times and I even have a couple of slides about this in my standard JCR slide deck I think this is probably worth an separate post on this blog.<br><br>

    Thanks for bringing it up, it is a very good point...<br><br>

    regards,<br>
    david
  • By KoW - 6:23 AM on Jan 03, 2008   Reply
    Regarding possible usages of JCR in other languages: another interessting possibility is the usage of JCR in dynamic languages on the JVM: e.g. grails (http://grails.org) has some interessting albeit unpublished ideas. <br/>
    Other languages would be Ruby (with JRuby on Rails) and, very interessting, Scala (http://www.scala-lang.org/). <br/>
    The JVM itself seems to have a bright future (oh, and has the "J" in the name, too :)).
  • By David Nuescheler - 1:14 PM on Jan 15, 2008   Reply
    ;)<br>
    <br>
    anyway, some more posts going into a similar direction:<br>
    <a href="http://dev.day.com/microsling/content/blogs/main/jrubyjcr.html">http://dev.day.com/microsling/content/blogs/main/jrubyjcr.html</a><br>
    <a href="http://dev.day.com/microsling/content/blogs/main/scalajcr.html">http://dev.day.com/microsling/content/blogs/main/scalajcr.html</a><br>