views:

588

answers:

2

In Jackrabbit I have experienced two ways to save my POJOs into repository nodes for storage in the Jackrabbit JCR:

  1. writing my own layer and
  2. using Apache Graffito

Writing my own code has proven time consuming and labor intensive (had to write and run a lot of ugly automated tests) though quite flexible.

Using Graffito has been a disappointment because it seems to be a "dead" project stuck in 2006

What are some better alternatives?

+1  A: 

You might want to have a look at Jackrabbit OCM that is alive and kickin. Of course another way is to manually serialize/deserialize the POJOs. For that there are many different options. Question is whether you need fix schema to query the objects in JCR. If you just want to serialize into XML then XStream is a very painless way to do so. If you need a more fix schema there is also Betwixt from Apache Commons.

tcurdt
Thanks for the pointers to XStream, Betwixt and the Jackrabbit OCM.
Chinnery
+4  A: 

Another alternative is to completely skip an OCM framework and simply use javax.jcr.Node as a very flexible DAO itself. The fundamental reason why OCM frameworks exist is because with RDBMS you need a mapping from objects to the relational model. With JCR, which is already very object-oriented (node ~= object), this underlying reason is gone. What is left is that with DAOs you can restrict what your programmers can access in their code (incl. the help of autocompletion). But this approach does not really leverage the JCR concept, which means schema-free and flexible programming. Using the JCR API directly in your code is the best way to follow that concept.

Imagine you want to add a new property to an existing node/object later in the life of your application - with an OCM framework you have to modify it as well and make sure it still works properly. With direct access to nodes it is simply a single point of change. I know, this is a good way to get problems with typos in eg. property names; but this fear is not really backed by reality, since you will in most cases very quickly notice typos or non-matching names when you test your application.

For having some constraints on what is allowed or what is mandatory (ie. "semi-schema") you can use node types and mixins (you currently cannot change the primary node type, thus only mixins can be changed, but JCR 2.0 will allow you to change it): thus you can handle this completely on the repository level and don't have to care about typing and constraints inside your application code - apart from catching the exceptions ;-)

But, of course, this choice depends on your requirements and personal preferences.

Alexander Klimetschek
Very interesting. I admit I have not really gotten away from the old "OCM style" of thinking. Good food for thought.
Chinnery