Walkthrough

The following steps simulate a typical user session. An end result (i.e a layout of file and directories) is then shown.

The user creates a node through the UI and uploads content – in this example it's a simple text file (chandni.txt) with a string ("chandni o. . ."):

Start Fedora

The modeshape configuration specifies using a file-based backend store.

cd fcrepo4/fcrepo-webapp
mvn jetty:run -Dfcrepo.modeshape.configuration=classpath:config/single-file/repository.json

Add Content

curl -v -XPUT --upload-file chandni.txt http://localhost:8080/rest/chandni/ds0/fcr:content

Fedora will create a directory "fcrepo4-data" in the current working directory. The default directories found in "fcrepo4-data" will be the following:

> ls fcrepo4-data
com.arjuna.ats.arjuna.common.ObjectStoreEnvironmentBean.default.objectStoreDir
com.arjuna.ats.arjuna.objectstore.objectStoreDir
fcrepo.activemq.dir
fcrepo.ispn.repo.CacheDirPath
fcrepo.modeshape.index.location

The serialized Fedora nodes can be found in the "fcrepo.ispn.repo.CacheDirPath/FedoraRepository" directory. The files in that directory would look something like this:

> ls fcrepo4-data/fcrepo.ispn.repo.CacheDirPath/FedoraRepository/
1008466944
1016939520
102151168
-1022408704
1028132864
1036310528
1040946176
...

These generated files contain serialized data about each of the JCR/Fedora nodes. Running the cURL command above, for example, generates binary files. Some things to note about these files and their contents:

• The file names in the case of FileCacheStore are generated by calculating the Java hashcode of the node's UUID string (and shifting it by 22 fixed bit mask). For example, for root node, file -891938816 gets generated, containing the root node children.
• Each of the files contain serialized ModeShape nodes. Although the generated files are binary, the data can be read using a tool that understands both BSON and JBoss serialization, or by using ModeShape API itself (It does not seem possible to read these files using existing bson tools, like mongoDB bsondump).
• The serialization is done by a JBoss serialization library, not JDK's native object serialization machinery. For this reason the generated serialized files look different from an ordinary JDK serialized file. (Please refer to section on node contents for details.)

Using a tool can help in reading the contents of the file. For example, for our root node file (-891938816) , a tool could show the root node data as following:

{ "properties" : { "http://www.jcp.org/jcr/1.0" : { "primaryType" : { "$name" : "mode:root" } , "uuid" : "87a0a8c7505d64/" } } , "children" : [ { "key" : "87a0a8c317f1e7jcr:system" , "name" : "jcr:system" } , 
{ "key" : "87a0a8c7505d646988a17a-ad2f-48f6-aef5-e7d411e184d9" , "name" : "chandni" } ] , "childrenInfo" : { "count" : 2 } }

The actual binary file (in this case -891938816) looks something like this when opened up in a text editor:

Some of these elements are:

1. 87a0a8c7505d64 refers to root node UUID

2. The grayed out text refers to Modeshape classes responsible for data representation and serialization. The serialization is done by the framework JBoss Marshalling, which can be configured to use custom serialization classes that read and write content in the format of their choosing (in this case it's BSON). The serialization format contains the name of datastructures and ModeShape custom marshallers (classes in org.infinispan.schematic.internal.*)

3. The file contains binary data for specifying different internal attributes, so the file might show garbage characters or numbers in strings. /children0<key87a0a8c317f1e7jcr:systemnamejcr:system1Skey387a0a8c7505d64 . Similarly, if object 'chandni' had siblings, the array would appear in the binary as:
4. Name/string (6988a17a-ad2f-48f6-aef5-e7d411e184d9namechandni)

Similarly, for the datastream:

Infinispan Configuration Options

Depending on the configured Infinispan backend, the directory layout and contents of the binary files would be different. The following sections covers other cache store options.

File system Backends

LevelDB

Currently, the default configuration outputs Fedora data to LevelDB (a fast filesystem based key-value store). When Fedora 4 is started, ModeShape (actually Infinispan and LevelDB in the background) will create several directories on the filesystem. Currently, the directories created are:

1. fcrepo.ispn.binary.CacheDirPath (binary data)
2. fcrepo.ispn.CacheDirPath (metadata)
3. fcrepo.ispn.repo.CacheDirPath (repository)
4. fcrepo.modeshape.index.location

The layout of files in directories 1-3 is determined by LevelDB. Some of the important files are:

1. File .log holds entries for recent transactions. The relevant API for representing these entries is modeshape-schematics (see, e.g.,  org.infinispan.schematic.SchematicEntry)
2. File .sst stores these entries when the .log file reaches a size threshold. A new log file is generated.
3. File MANIFEST.x records info about .sst files (among other things). 
4. File CURRENT specifies the current MANIFEST file.

Most of these files are binary and can be read by a LevelDB Java library.