JSR 170 (Java Content Repository) and Zope 3 ECM


Sat 25 June 2005 By Stefane Fermigier

I'm at the Z3ECM sprint in EuroPython 2005 and I've spent yesterday trying
to play with the JCR
(Java Content Repository aka JSR-170) trying to understand

  1. how easy it would be to how a Zope content management system into a JCR
    (short answer: not easy - despite of claims of interoperability, JCR is a
    100% Java technology).

  2. if there are useful ideas in the JCR that could be put into the design
    of the repository for Z3ECM (short answer: probably, yes)

Hooking Zope into a JCR


After installing Jackrabbit (an open
source implementation of the JCR made by the Apache project) and testing it
with some Java examples, I've trying calling it from Python using the JPype Java<->Python
bridge.



Installing Jackrabbit is not that hard, it took me about one hour though
since I haven't done any Java development since 1996 and didn't have all the
right tools (including Maven and a dozen of libraries like xalan, xerces,
log4j, etc.) from the Apache Java project installed. Not a big deal
anyway.



Unfortunately, JPype is pretty much a work in progress, that would benefit
from more users and developers. There are, seemingly, limitations that
prevented me from login in the JCR so this experiment didn't succeed and my
knowledge of Java is much to light to keep on the experiment.



If we succeed in hooking Python/Zope into a JCR (which is, overall, just a
question of Java/JNI knowledge and grunt work), I think the most important
question is how the to make Zope and Java transactions systems work well
together (transactions are an optional JSR-170 feature, but I don't see how
a repository without transactions would be useful at all).

Ideas from the JCR specs


A JCR is a repository of nodes stored in whatever you want (flat files, SQL
DB, object DB, XML DB...). Nodes are just collections of properties, so it's
a very data-centric model that doesn't impose a programming model, and would
work very well outside of Java. In practice, Nodes are the documents you're
managing with you application. Nodes can be accessed from a path
(hierarchical navigation, something Zope developers are very familiar
with), or by UUID (unique identifiers). More interesting are:

  1. Querying nodes, which is based on a simplified XPath query language,
    or, optionally, a variant of SQL

  2. XML import/export, which would provide interoperability between
    repositories at list in the sense that you can import data from one
    repository to another (no vendor lock-in)

  3. Versionning
  4. Events



Overall, nothing very different from what we are already doing with the CPS
Repository (from CPSCore), but it's interesting to try to dig a bit further
in the specs and to keep then in our minds when designing the Z3ECM model
for the repository, querying, and versionning.

Related standards


The WebDAV/DeltaV standard for
versionning and its JCP interpretation (JSR-147)
are related to these specifications.


Category: Product & Development