JCR | Jukka Zitting

Archive for the ‘JCR’ Category

Articles

Apache Jackrabbit 1.6.0 released

In Jackrabbit,JCR on 2009-08-11 by Jukka Zitting

The Apache Jackrabbit project has just released Jackrabbit version 1.6.0. This release will most likely be the latest JCR 1.0 -based Jackrabbit 1.x minor release before the upcoming Jackrabbit 2.0 and the upgrade to JCR version 2.0. The purpose goal of this release is to push out as many of the recent Jackrabbit trunk improvements as possible so that the number of new things in Jackrabbit 2.0 remains manageable.

The most notable changes and new features in this release are:

The RepositoryCopier tool makes it easy to backup and migrate repositories (JCR-442). There is also improved support for selectively copying content and version histories between repositories (JCR-1972).
A new WebDAV-based JCR remoting layer has been added to complement the existing JCR-RMI layer (JCR-1877, JCR-1958).
Query performance has been further optimized (JCR-1820, JCR-1855 and JCR-2025).
Added support for Ingres and MaxDB/SapDB databases (JCR-1960, JCR-1527).
Session.refresh() can now be used to synchronize a cluster node with changes from the other nodes in the cluster (JCR-1753).
Unreferenced version histories are now automatically removed once all the contained versions have been removed (JCR-134).
Standalone components like the JCR-RMI layer and the OCM framework have been moved to a separate JCR Commons subproject of Jackrabbit, and are not included in this release. Updates to those components will be distributed as separate releases.
Development preview: There are even more JSR 283 features in Jackrabbit 1.6 than were included in the 1.5 version. These new features are accessible through special “jsr283” interfaces in the Jackrabbit API. Note that none of these features are ready for production use, and will be replaced with final JCR 2.0 versions in Jackrabbit 2.0.

This release is the result of contributions from quite a few people. Thanks to everyone involved, this is open source in action!

Leave a Comment

Articles

JCR 2.0 implementation progress

In Jackrabbit,JCR on 2009-07-18 by Jukka Zitting

The JCR 2.0 API specified by JSR 283 has been in Proposed Final Draft (PFD) stage since March, and Apache Jackrabbit developers have been busy implementing all the specified new features and adding compliance test cases for them.

Both the Reference Implementation (RI) and the Technology Compatibility Kit (TCK) of JSR 283 will be based on Jackrabbit code, and we expect the final version of the specification to be released shortly after Jackrabbit trunk becomes feature-complete and the API coverage of the TCK reaches 100%. The following two graphs illustrate our progress on both these fronts.

First a track of all the JCR 2.0 implementation tasks we’ve filed under the JCR-1104 collection issue. The amount of work per each sub-task is not uniform, so this graph only shows the general trend and does not suggest any specific completion date.

jcr-20-implementation

The second graph tracks the TCK API coverage. We started with the JCR 1.0 TCK, so the first 300-400 method signatures were already covered with few changes to existing test code. Based on Julian’s API coverage reports in JSR-2085, this graph tracks progress in covering the 100+ new method signatures introduced in JCR 2.0. Again, the graph is meant to show just a general trend and should not be used to extrapolate future progress.

JCR 2.0 TCK API coverage

Wan’t to see JCR 2.0 in action? The latest Jackrabbit 2.0 alpha releases are available for download!

Leave a Comment

Articles

Comparing Midgard and JCR

In JCR,Midgard on 2009-02-10 by Jukka Zitting

Midgard Midgard is the open source content management framework that we originally created with Henri Bergius more than ten years ago. In the past few years I have been more involved with Java content repositories like Apache Jackrabbit, but I’m still following what goes on in Midgard and Henri’s recent comparison of Midgard and JCR prompted me to write up some of my thoughts on these two technologies. My experiences with Midgard and other content management systems that I’ve implemented go a long way explaining why I find the content repository concept so powerful.

In Midgard everything is content that is stored and managed inside a central content repository. The Midgard repository is an organized collection of MgdSchema objects stored in a specifically structured MySQL database. The repository contains site templates, user preferences, content hierarchies and much more. All these content objects are accessed and managed through the Midgard core API and the language bindings that have been built on top of the API.

As Henri mentions, the Midgard repository clearly resembles to the JCR content repository model. The similarity is strong enough that I find it very interesting to look deeper at where the repository models differ and see which features I like better. Here’s a quick overview:

JCR typing is more flexible. The MgdSchema model makes it very easy to extend the repository with custom object types and the parameter feature allows even further runtime extensibility, but all objects are still clearly associated with a defined type. Midgard does not have unstructured nodes or mixin types that you find in JCR.
Midgard is less constrained by the hierarchy. In Midgard hierarchies are just a well supported special case of a more generic object linking mechanism. JCR references or event the shareable nodes in JCR 2.0 are not as powerful as the many-to-many relationships that you can easily handle in Midgard.
JCR is more addressable. As a downside of the above point, Midgard does not support as powerful path-based addressing of content objects as JCR does. The Midgard repository is only partially addressable by paths while in JCR everything has a path. On the other hand all Midgard objects are addressable by their identifiers, whereas only referenceable nodes in JCR can be accessed by identifier.
Midgard queries are more powerful. The JCR 1.0 query model restricts search criteria to only refer to properties of a single node. Repository implementations like Jackrabbit extend the query model somewhat, but the Query Builder feature in Midgard allows more flexible search criteria to be used.

As a summary I think both JCR and the Midgard repository are good examples of the kind of infrastructure that provides a strong base for building modern content management systems. And Midgard’s relationship with the desktop world is an interesting example of how content repository technology isn’t really limited to just traditional content management systems.

1 Comment

Articles

File system on steroids

In ASF,Jackrabbit,JCR,Technology on 2008-04-16 by Jukka Zitting

Last week at ApacheCon EU I made a case for content repositories as a general solution for applications that are currently forced to fragment their storage needs due to the different limitations of traditional storage methods, mostly file systems and databases plus more recently cloud services on the network. See below for the presentation:

It seems like the message was well received, after the presentation I got a lot of positive feedback from people who had previously thought of content repositories as something you’d only use for storing content in a content management system. Instead I see a content repository as a unifying storage layer that can be used for almost anything ranging from traditional content and data to configuration files, user account information, preferences, templates and scripts, source code and binaries, ad-hoc annotations, etc.

Leave a Comment

Articles

eXo JCR 1.8 released

In JCR on 2008-03-07 by Jukka Zitting Tagged: jcr exo benchmark

Congratulations to the eXo team for releasing eXo JCR 1.8!

It’s cool to see the various JCR implementations evolve and grow. The JCR 1.0 standard is less than three years old, and there are already a number of independent implementations, both open source and commercial.

So far we’ve seen little cooperation (apart from JSR 283) or even much direct competition across the implementations, as I guess everyone is just busy grabbing market-share from pre-JCR vendors. But I wouldn’t be surprised if we started seeing more benchmarks and feature comparisons on JCR repositories already during this year. I expect it to be fun!

Leave a Comment

Articles

Volunteering to mentor Graffito

In ASF,Jackrabbit,JCR on 2006-07-16 by Jukka Zitting

Raphaël Luta, mentor of the incubating Apache Graffito project, recently asked for volunteers to help him mentor the Graffito project. Encouraged by my recent ASF membership and the fact that I had been keeping an eye on the project for quite a while, I decided to volunteer.

Before formal appointment as a mentor I’ve introduced myself on the Graffito mailing list and started getting more familiar with the project. I’m especially interested in the Object/Content Mapping (OCM) framework JCR-mapping that is included as a Graffito subproject, but also on the other parts of the project. Having worked on various content management systems for over ten years since our first pre-Midgard site experiments (including a custom SGML vocabulary mapped to early HTML with DSSSL) with the Greywolves, I’m still eager to learn new approaches like Graffito.

Graffito is both a framework for building content applications and a set of existing portlet components. Although the project is related to Apache Jetspeed-2, the portlets should work on any compliant portal engine. The framework components can also be used outside the portlet model. The project aims also for independence from the underlying content storage, using a generic “Graffito Core Model” and itsderivates as the abstract content model and “Content Server” abstraction for the content storage layer.

The current default content server implementation is based on Apache OJB and runs on top of relational databases. The JCR-mapping subproject is planned to be used for a similar task on top of JCR content repositories, especially Apache Jackrabbit. Just like OJB is not a subproject of Graffito, we’ve had initial discussion about possibly moving the JCR-mapping project outside Graffito. Making it a Jackrabbit subproject is an interesting alternative, especially if we want to target for an eventual JCR federation within the ASF, but for now I think it’s best to get the communities together and see what patterns emerge before making final decisions on what to do with thesubproject.

Leave a Comment

« Back to Home