eXo JCR 1.14: New Features for eXo Platform 3.5

For almost everything it can do – and it can do a lot, from websites to community extranets to enterprise social intranets and much more – eXo Platform relies on its built-in Java Content Repository (JCR). With eXo Platform 3.5, working with content and data will be both easier and more ready for prime-time enterprise deployments.

At eXo, I lead a team of developers in building eXo JCR, our open source implementation of the JSR-170 spec, which is used in eXo Platform. We’ve just released eXo JCR 1.14.0-GA, which will add many new features and enhancements to the upcoming eXo Platform 3.5. This version is quite a big step forward since JCR 1.12: between JCR 1.12 and 1.14, we worked on no less than 50 improvements and 100 new features!! In this post, I will describe the new features and improvements that we added since my last blog post.

New Features

Managed Transactions & JCA Support

In eXo JCR 1.12 and earlier, our Java Transaction API (JTA) support was limited and experimental. Because we wanted to be able to support managed transactions and JCA 1.5 in eXo Platform 3.5 and beyond, we completely overhauled our JTA support for eXo JCR 1.14.

  • Managed Transactions Support: If you use managed data sources, you simply need to configure your eXo JCR instance to allow it to distinguish the managed data sources from the others. eXo JCR will then know whether or not it needs to delegate the commit and rollback calls to the Application Server.
  • Java EE Connector Architecture (JCA) Support: If you intend to use eXo JCR in your custom application to store your data, and you would like to delegate the management of the JCR session life-cycle to your application server, you can now use the JCA Resource Adapter for eXo JCR.

Asynchronous Indexing

Lucene is used any time we execute a JCR query, which means it’s a critical part of eXo JCR. That’s also why, in previous versions, full indexing used to be blocking. Now you can make it non blocking in order to access to your application immediately, even if a full indexing is running. However, as long as the indexing is running, you won’t be able to execute a JCR query; only pure API calls will be allowed. Another interesting aspect of this feature is the fact that you can rebuild the Lucene indexes of a given workspace at runtime, using JMX.

External Backup Tools Allowed

eXo JCR now provides a secure way for you to use external backup tools to back up the data of your JCR instance. It was possible to use third-party backup tools with previous versions, but you had to ensure that no transactions were running (which is not trivial). The latest version of eXo JCR leverages JMX, which lets you suspend and resume all the current transactions on your JCR instance. So if you want to use your own tools, simply suspend the current transactions, launch your tools to back up your data, then resume the transactions.

Other Interesting New Features

  • If you wanted to keep big objects or non-serializable objects in a replicated eXo cache instance, you can configure your eXo cache to enable an invalidation mechanism. This will automatically invalidate your data anytime it detects a changed value in your cluster.
  • A new syntax allows you to define a default value in your configuration files. For example, ${my.value:10} will be understood by the kernel as, try to find the value of the variable called “my.value”, and if no value is found use “10”.
  • You can use your own Lucene lock factory and/or Lucene directory if the default ones don’t fulfill your requirements.
  • We added a mime type detection mechanism that allows eXo JCR to properly extract the meta-data and the full text content of a document, even if the extension is missing in the name of the file.


Multi-Database Schema Support

Frequently a single database instance must be shared by several other applications. But some of our customers have also asked for a way to host several JCR instances in the same database instance. To fulfill this need, we had to review our queries and scope them to the current schema in a different way; it’s now possible to have one JCR instance per DB schema instead of per DB instance.


In this new version, we worked a lot on improving the monitoring capabilities. We did this by exposing many new MBeans in the JMX console, and by simply giving more understandable names to all the threads of eXo JCR. You now have a better overview of what’s going on in your eXo JCR instance.

Pattern-based Methods

In many applications based on eXo JCR, we realized that people obtain their data property by property; this is not necessarily a good practice, especially when there are many properties to fetch. To provide a much more scalable solution, we worked on improving the methods Node.getNodes(NamePattern) and Node.getProperties(NamePattern). So now, instead of potentially making the eXo JCR execute as many queries as you have properties in your node (assuming that the cache is empty), we can obtain all data properties using a single query.

Other Interesting Improvements

  • Access Control List (ACL) management has been updated to drastically reduce the total amount of database accesses needed to get the ACL of a given node.
  • We added a new method in our internal interface called ExtendedNode.getNodesLazily. This can be used as an alternative of Node.getNodes in the parts of your application where you can have a lot of sub nodes, and where consistency is not necessarily an issue.


You can download eXo JCR 1.14.0-GA from here and get the documentation from jboss.org here.


Be part of the discussion, share your comments