Welcome to your first hops into the world of Jackrabbit! This introduction gives you a hands-on experience with Jackrabbit and the JCR API. Once you have finished hopping through this document, you should be all set to continue on your own with the official JCR specification and the documentation on this site.
The easiest way to get started with Jackrabbit is to download the runnable Standalone Server jar. In addition to running it, you can also put it in your classpath to quickly access all the classes and interfaces you need below. Alternatively, if you use the Apache Maven build system (which we recommend), you can set up your first hops project with the following dependenecies.
|You probably have an error in your classpath settings if you get a ClassNotFoundException message when trying to compile or run the examples below.|
So let's get started. As a warm-up we'll create a Jackrabbit content repository and start a login session for accessing it. The full example application that does this is shown below, with line-by-line explanations following shortly after.
You can also download the source file as FirstHop.java. If you have your classpath set up, you can compile the application with javac FirstHop.java and run it with java FirstHop to get the following output.
In addition to producing the above status line the application copies a default repository configuration file to repository.xml and creates an initial Jackrabbit content repository in the repository subdirectory. You can use the system properties org.apache.jackrabbit.repository.conf and org.apache.jackrabbit.repository.home to set alternative configuration file and repository directory locations.
Read on for a detailed breakdown of the FirstHop application:
The JCR API interfaces are located in the javax.jcr package found in the jcr-2.0.jar library. The promise of the JCR API is that if you only use these interfaces in your content application, it should remain mostly independent of the underlying content repository implementation.
The Repository interface represents a given content repository instance and the Session interface represents a single login session for accessing the repository. A session is needed to access any content within a repository.
Note that a Session instance is not guaranteed to be thread-safe so you should start multiple sessions if you need to access repository content simultaneously from different threads. This is especially important for things like web applications.
The best practice for deploying Jackrabbit is to use JNDI or some other configuration mechanism in a container environment to keep the application code free of direct Jackrabbit dependencies. In our simple standalone application we take a shortcut and use a utility class from the jackrabbit-commons module.
The FirstHop example is a simple standalone application that fits nicely in the main() method and lets the JVM take care of the possible exceptions. More substantial content applications could also be written as web application or EJB components with different setup and error handling patterns.
The getRepository() method internally uses the JCR RepositoryFactory mechanism to provide a Repository instance. The actual Repository class is implementation specific and Jackrabbit will return an instance of TransientRepository. This implementation contains a utility feature that will take care of the initial configuration and repository construction when the first session is started. Thus there is no need for manual configuration for now unless you want direct control over the repository setup.
The TransientRepository implementation will automatically initialize the content repository when the first session is started and shut it down when the last session is closed. Thus there is no need for explicit repository shutdown as long as all sessions are properly closed. Note that a Jackrabbit repository directory contains a lock file that prevents it from being accessed simultaneously by multiple processes. You will see repository startup exceptions caused by the lock file if you fail to properly close all sessions or otherwise shut down the repository before leaving the process that accesses a repository. Normally you can just manually remove the lock file in such cases but such cases always present a chance of repository corruption especially if you use a non-transactional persistence manager.
The Repository.login(Credentials) method starts a repository session using the default workspace and guest credentials. Jackrabbit will default to the anonymous user when guest credentials are passed on login.
Since we use the TransientRepository class as the Repository implementation, this step will also cause the repository to be initialized.
It is a good practice to properly release all acquired resources, and the JCR sessions are no exception. The try-finally idiom is a good way to ensure that a resource really gets released, as the release method gets called even if the intervening code throws an exception or otherwise jumps outside the scope (for example using a return, break, or continue statement).
The Session.logout() method in the finally branch closes the session and since this is the only session we have started, the TransientRepository is automatically shut down.
The username or identifier of the user associated with a session is available using the Session.getUserID() method. Jackrabbit returns "anonymous" by default.
Each content repository implementation publishes a number of string descriptors that describe the various implementation properties, like the implementation level and the supported optional JCR features. See the Repository interface for a list of the standard repository descriptors. The REP_NAME_DESC descriptor contains the name of the repository implementation, in this case "Jackrabbit".
The main function of a content repository is allow applications to store and retrieve content. The content in a JCR content repository consists of structured or unstructured data modeled as a hierarchy of nodes with properties that contain the actual data.
The following example application first stores some content to the initially empty content repository, then retrieves the stored content and outputs it, and finally removes the stored content.
Like in the first hop, this example source is also available as SecondHop.java. You can also compile and run this class just like you did in the first hop example. Running this example should produce the following output:
The basic structure of this example application is the same as in the First Hop example, so let's just walk through the differences:
These are two new classes we need for this example. The SimpleCredentials class is a simple implementation of the Credentials interface used for passing explicit user credentials to the Repository.login(Credentials) method.
The Node interface is used to manage the content nodes in a repository. There is a related interface called Property for managing content properties, but in this example we use the Property interface only indirectly.
As discussed in the First Hop example, the Repository.login(Credentials) method with guest credentials returns an anonymous read-only session in the Jackrabbit default configuration. To be able to store and remove content we need to create a session with write access, and to do that we need to pass some credentials to the
The default Jackrabbit setup has a built in 'admin' user with full write access. Thus we only need to construct and use a SimpleCredentials instance with username "admin" and the default password "admin".
The SimpleCredentials constructor follows the JAAS convention of representing the username as a normal String, but the password as a character array, so we need to use the String.toCharArray() method to satisfy the constructor.
Each JCR session is associated with a workspace that contains a single node tree. A simple way to access the root node is to call the Session.getRootNode() method. Having a reference to the root node allows us to easily store and retrieve content in the current workspace.
New content nodes can be added using the Node.addNode(String relPath) method. The method takes the name (or relative path) of the node to be added and creates the named node in the transient storage associated with the current session. Until the transient storage is persisted, the added node is only visible within the current session and not within any other session that is concurrently accessing the content repository.
This code snippet creates two new nodes, called "hello" and "world", with "hello" being a child of the root node and "world" a child of the "hello" node.
To add some content to the structure created using the "hello" and "world" nodes, we use the Node.setProperty(String name, String value) method to add a string property called "message" to the "world" node. The value of the property is the string "Hello, World!".
Like the added nodes, also the property is first created in the transient storage associated with the current session. If the named property already exists, then this method will change the value of that property.
Even though the rest of our example would work just fine using only the transient storage of the single session, we'd like to persist the changes we've made so far. This way other sessions could also access the example content we just created. If you like, you could even split the example application into three pieces for respectively storing, retrieving, and removing the example content. Such a split would not work unless we persisted the changes we make.
The Session.save() method persists all pending changes in the transient storage. The changes are written to the persistent repository storage and they become visible to all sessions accessing the same workspace. Without this call all changes will be lost forever when the session is closed.
Since we are still using the same session, we could use the existing hello and world node references to access the stored content, but let's pretend that we've started another session and want to retrieve the content that was previously stored.
The Node.getNode(String relPath) method returns a reference to the node at the given path relative to this node. The path syntax follows common file system conventions: a forward slash separates node names, a single dot represents the current node, and a double dot the parent node. Thus the path "hello/world" identifies the "world" child node of the "hello" child node of the current node - in this case the root node. The end result is that the method returns a node instance that represents the same content node as the world instance created a few lines earlier.
Each content node and property is uniquely identified by its absolute path within the workspace. The absolute path starts with a forward slash and contains all the names of the ancestor nodes in order before the name of the current node or property.
The path of a node or property can be retrieved using the Item.getPath() method. The Item inteface is a superinterface of Node and Property, and contains all the functionality shared by nodes and properties.
The node variable references the "world" node, so this statement will output the line "/hello/world".
Properties can be accessed using the Node.getProperty(String relPath) method that returns an instance of the Property interface that represents the property at the given path relative to the current node. In this case the "message" property is the one we created a few lines earlier.
A JCR property can contain either a single or multiple values of a given type. There are property types for storing strings, numbers, dates, binary streams, node references, etc. We just want the single string value, so we use the Property.getString() method. The result of this statement is the line "Hello, World!" being outputted.
Nodes and properties can be removed using the Item.remove() method. The method removes the entire content subtree, so we only need to remove the topmost "hello" node to get rid of all the content we added before.
Removals are first stored in the session-local transient storage, just like added and changed content. Like before, the transient changes need to be explicitly saved for the content to be removed from the persistent storage.
TODO: Update to match the style of previous hops.
To add content a bit more efficiently, you may want to try JCR's import facilities, such as Session.importXML. The following XML document by Elliotte Rusty Harold provides an interesting example that demonstrates a repository's namespace capabilities:
The third example application shown below will import the XML file called test.xml from the current directory into a new content repository node called importxml. Once the XML content is imported, the application recursively dumps the contents of the entire workspace using the simple dump() method.
Running the ThirdHop class should produce output like the following:
This hop has a lot of similarities with the Second Hop example: we create a new session with write access by loggin in, next we insert data into the repository, this time by importing an xml file and finally we output the entire repository content.
By now you should be familiar with loggin into a repository (Repository.login), creating a new node (Node.addNode) under the repository root (Session.getRootNode) and saving the session so that our changes are persisted (Session.save).
Let us look at the new methods used in this example, how to import xml content:
This deserializes an XML document and adds the resulting item subgraph as a child of the node at the provided path.
The flag ImportUUIDBehavior governs how the identifiers of incoming nodes are handled. There are four options:
- ImportUUIDBehavior.IMPORT_UUID_CREATE_NEW: Incoming nodes are added in the same way that new node is added with Node.addNode. That is, they are either assigned newly created identifiers upon addition or upon save. In either case, identifier collisions will not occur.
- ImportUUIDBehavior.IMPORT_UUID_COLLISION_REMOVE_EXISTING: If an incoming node has the same identifier as a node already existing in the workspace then the already existing node (and its subgraph) is removed from wherever it may be in the workspace before the incoming node is added. Note that this can result in nodes "disappearing" from locations in the workspace that are remote from the location to which the incoming subgraph is being written. Both the removal and the new addition will be dispatched on save.
- ImportUUIDBehavior.IMPORT_UUID_COLLISION_REPLACE_EXISTING: If an incoming node has the same identifier as a node already existing in the workspace, then the already-existing node is replaced by the incoming node in the same position as the existing node. Note that this may result in the incoming subgraph being disaggregated and "spread around" to different locations in the workspace. In the most extreme case this behavior may result in no node at all being added as child of parentAbsPath. This will occur if the topmost element of the incoming XML has the same identifier as an existing node elsewhere in the workspace. The change will be dispatched on save.
- ImportUUIDBehavior.IMPORT_UUID_COLLISION_THROW: If an incoming node has the same identifier as a node already existing in the workspace then an ItemExistsException is thrown.
Another interesting method is
This can be used as an example of how to do a recursive traversal of all the repository, and check the properties of each node.
Notice how we have to pay special attention to the multi-value properties, beacuse that impacts the way we use them:
if this yelds true, then we are dealing with an array of values:
or else, we can use the provided api shortcuts, to get the desired value:
which is equivalent to
A very good entry point for utilities related code examples is JcrUtils.