A JBoss Project
Red Hat

JCR FAQ

What is JCR?

JCR is the acronym for the Content Repository for Java technology API, which is a standard API used to access data regardless of the data storage system used. JCR version 1.0 was created through Java Specification Request 170 (JSR 170). Version 2.0 is currently under work in JSR 283.

What is JCR for?

JCR is often mistaken to be an interface for accessing file systems, relational databases, and XML documents -- essentially a better Hibernate (which is a generic interface for RDBMS), only supporting more data source types.

In fact, as the name simply states, JCR is a Java interface to access content only. By content, we usually mean web content for the most part, but it can also refer to other hierarchically stored data. The content is stored in a repository. The repository can be a file system, a relational database or an XML document. The internal structure of JCR data looks similar to an XML document; that means a document tree with nodes and data -- with a small difference in JCR the data is stored in "property items".

Or better to cite the specification itself: "A content repository is a high-level information management system that is a superset of traditional data repositories."

Why use JCR?

Remember how the data for your web site is stored? The images are probably in a file system, the metadata is in some dedicated files -- maybe in XML -- the text documents and pdfs are stored in different folders with the metadata in another place (a database?) and in a proprietary structure. How do you manage to update these data and how do you manage the access rights? Most likely, you are managing different versions of each document. The larger the web site is the more you need a Content Management Systems (CMS) to tackle all these issues.

These CMS solutions are sold by different vendors and each vendor provides its own API for interfacing the proprietary content repository. The developers have to deal with this and need to learn the vendor-specific API. Should you need to ever switch to a different vendor, everything will need to be updated to a new implementation, a new interface, etc.

JCR provides a unique Java interface for interacting with both text and binary data and dealing with any kind and amount of metadata your documents might have. JCR supplies methods for storing, updating, deleting and retrieving data, independent of whether this data is stored in a RDBMS, a file system or as an XML document. The JCR interface also defines classes and methods for searching, versioning, access control, locking, and observation. Furthermore an export and import functionality is specified so that switching from one vendor to another is seamless.

What does eXo JCR do?

eXo JCR fully complies with the JCR specification. That means flexibility and no vendor lock-in, which will reduce lifecycle cost and long-term risk.