Another Internet Matt

Why I WANT to use Apache Jackrabbit

There are times when I come across a new technology and just start to get giddy because it seems so cool. I want to use it right then and there. But then the rational part of my brain kicks in and makes me start to evaluate the situation and determine if this new spiffy technology is even right for my current project. Sometimes it’s a fit, sometimes it’s not.

For my latest project, a new CMS, I have decided to try out Apache Jackrabbit. The title of this post mentions why I WANT to use Jackrabbit. I’ve just started the new CMS, so I haven’t found all the warts and gotcha points of Jackrabbit, but I will try to tell you what excites me about Jackrabbit.

Versioning
Jackrabbit has built-in versioning history. This is great. If I want to keep a history of changes, this is ready for me to use.

Clustering
The CMS I am building is for a high traffic site with a load balanced configuration. Jackrabbit is suppose to be able to cluster. The way I plan to do this is have a staging server as the master. Once all changes have been made, the staging server will push the changes out to the live web servers. I am pretty sure this is possible and if so, this should work nicely.

Momentum
For ages relational databases have been the standard. But more recently, people are finding that those types of databases might not be the best solution for all situations. That is why JCR 170 was created as a content repository spec for java. JCR 170 is meant to store all types of content (text and binary) not just simple text. So you can use it to store files, snippets and even images. JCR 170 has been adopted by projects like Alfresco and Magnolia. I feel that the momentum is gaining in this direction and soon most larger projects will start to take the content repository approach.

So there you have it. I’ve just begun my Jackrabbit life. I’m crossing my fingers but I feel confident that Jackrabbit will be a major help to me in my CMS project.