Notes on Jackrabbit JCR

Occasionally i decide to play with JCR a bit. Every time i do, i have to start from scratch figuring it out.

Currently using 2.2.5.

Which distribution?

You have three choices, none of which are exactly normal:

Standalone

This is the only one that is actually a jar. It contains the class files not only for Jackrabbit, but also for all its dependencies, all merged together. It is also a war file, containing a simple webapp. It is also a runnable jar, which i think starts an embedded copy of Jetty to serve itself. It's a one-stop shop, but it seems a little on the heavy side, and it's untidy not to have the dependencies in their own jars.

Webapp

This is a WAR. It contains Jackarabbit and its dependencies as jars in WEB-INF/lib. It is also a webapp which you can use to access a repository or something - i haven't actually tried this. Compared to the RAR, it has a newer version of Apache Commons Codec (1.4 vs 1.2), it has the Apache Commons Fileupload library (only useful in a webapp), it has the Jackrabbit JCR-RMI, JCR-Server, JCR-Servlet, and JCR-WebDAV libraries, and lacks the JCA library.

JCA Adaptor

This is a RAR - as in a Java Resource Archive, not the kind of thing you download warez in. You can drop it into a J2EE app server and have Jackrabbit repositories made available as resources, just like JDBC datasources. As a functional unit, this strikes me as the most useful. I don't want to run a standalone JCR server, or expose a JCR webapp, but i might well want to use JCR inside an app server. It's also a zip full of jars; it contains Jackrabbit and its dependencies. In fact, the only thing it contains which isn't a jar is the META-INF/ra.xml file which makes it a resource adaptor.

What i ended up doing was unpacking the RAR and using that as my Jackrabbit installation. I can use the jars inside to compile code against, and i can symlink the whole thing into a JBoss server to use it as a resource adaptor (because JBoss will use exploded RARS - right?). I then fiddled with the unpack: i replaced the 1.2 version of commons-codec with 1.4, and added the JCR-RMI and JCR-Server jars (in an 'extra' subdirectory). These will never be a meaningful part of the RAR, but i'm making the RAR do double duty as a jar container.

I also downloaded the JSR 283 spec, which contains the JCR API jar. The API isn't included with Jackrabbit (oddly).

Logging

Jackrabbit loves to log. It uses SLF4J, which is a good thing. It does mean you need to supply and configure an SLF4J backend, which is a bit of a pain. The options are Apache (aka Jakarta) Commons Logging, which is an obsolete disaster, JDK java.util.logging, which is an abortion, log4j, which is good, but is another big thing to configure, the built-in simple logger, which just writes everything to the console, and Logback, which is like a do-over of log4j. I went for Logback. I'd never used it before; i've learnt that it's quirky, and has terrible documentation. Using version 0.9.18 (the current one in Fedora 13), this logback.xml pretty much worked for me:

<?xml version="1.0" encoding="UTF-8" ?>
<configuration>
	<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
		<filter class="ch.qos.logback.classic.filter.ThresholdFilter">
			<level>WARN</level>
		</filter>
		<layout class="ch.qos.logback.classic.PatternLayout">
			<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
		</layout>
	</appender>
	<appender name="FILE" class="ch.qos.logback.core.FileAppender">
		<file>jackrabbit.log</file>
		<layout class="ch.qos.logback.classic.PatternLayout">
			<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
		</layout>
	</appender>
	<root level="debug">
		<appender-ref ref="STDOUT" />
		<appender-ref ref="FILE" />
	</root>
</configuration>