Using Jakarta Slide

• slide.properties in class path.
• Domain.xml : default is the file in current directory. can be specified in slide.properties file
  

Slide can store the data it manages in a broad array of repositories. Each repository is accessed through a module called a Service or a Store. Each of these services have widely different dependencies, and can need a lot of extra setup steps. It is expected that services will be developed by Slide adopters to address their specific content management needs. For example, one company would want to access its website and NFS file server through Slide, so a NFS Service will be needed, along with a HTTP service.

The scope of the Slide project is not to integrate every existing repository in the universe (although there will be out-of-the-box support for the most widely used ones), but to enable users to easily write services which would enable access to them.

Default services included with Slide are:

• File system (default store)
• JDBC

Sample configuration file : click here.

Slide needs a configuration file to initialize the Domain. This configuration file defines the namespaces which are part of this domain, the services associated with them, and the namespaces data configuration. This file uses the XML language for its syntax.

A domain is an aggregation of one or more namespaces. If we use the UNIX filesystem analogy, a domain represents the root ("/") anchor where filesystems (in this case, namespaces) are mounted.

The domain controls access to its registered namespaces and performs initialization and connection management on behalf of the namespaces.

When Slide is first initialized, the Domain configuration is loaded. Once again, if you are familiar with UNIX, the domain configuration file is the equivalent of the fstab file. The path to the domain configuration file is given through the org.apache.slide.domain property in your slide.properties file (which must be located somewhere in your CLASSPATH).

The domain configuration is written by an administrator and tells how to initialize each Namespace. The namespace initialization includes information like:

• The low-level services the namespace uses (structure store, content store ...).
• The namespace base topology, which includes the location of the base actions and paths in the namespace.

Jakarta Slide core API

Architecture

The Slide architecture is a matrix of modules, ranging from high-level to low-level services, clearly separating functionality around different aspects (content, structure, security, locking and versioning).

Content in Slide is organized in Namespaces, which contain a hierarchical tree of information (analogous to directories and files in a filesystem). Multiple namespaces are aggregated in a Domain. The default implementation of a Slide domain is as a static entity, so only one domain can exist per JVM.

The high-level interfaces (Helpers) are meant to provide a simple, standardized way of manipulating a namespace from a client application. Underneath these interfaces lie pluggable, low-level services (Stores), which take care of actual storing the information.

Overview of the Slide architecture

Stores are low level services that handle the actual storage of content and related data. Stores are totally pluggable, enabling the use of the most appropriate storage method for the type of data to store.

Two different kinds of services exist:

• The Descriptors stores, which are responsible for storing structure, locks, metadata, etc.
• The Content stores, which is only responsible for storing the actual content.

Within Slide, every object can possibly have a different kind of backing low-level service. For example, some objects might be stored in a remote LDAP directory, while others could be stored in an local SQL database. Thus, the content of a namespace can be distributed across several different descriptors and content stores.

It is up to the administrator to choose how objects will be stored using the Slide configuration file, which maps low-level services to individual nodes in the namespace.

Services are attributed to nodes in the namespace. This mapping is automatically inherited by sub-nodes. Here is an example of how one namespace might be mapped into different low-level services:

Namespace mapped to multiple stores

It is obvious that decent transaction capabilities are required in each individual store as well as across all the stores. Slide provides it's own transaction manager based on the Java Transaction API (JTA) to comply with this requirement. Operations that include multiple objects and span various stores can be grouped in transactions and rolled back if one of the operations fails.

Transactions in Slide

Slide also provides a higher level abstraction of the content management system through a set of Java classes, called helpers. These encompass all the functionality a client application will need, clearly separated by aspect. These high-level services allow an application to access content in a uniform fashion, no matter where it might be located, or how it is physically stored.

Tight dependencies exist between the high-level services because of the need to enforce security, locking and other constraints throughout the client API.

The following helpers are provided:

• Structure
  Provides access to the hierarchical namespace tree.
  See the org.apache.slide.structure package for more details...
  
  
• Content
  Manages object content, versioning and meta-data.
  See the org.apache.slide.content package for more details...
  
  
• Security
  Manages access control to objects in a namespace.
  See the org.apache.slide.security package for more details...
  
  
• Lock
  Provides locking functionality.
  See the org.apache.slide.lock package for more details...
  
  
• Macro
  Provides object management functions that deal with operations which span multiple helpers (like for example deleting, copying and moving objects).
  See the org.apache.slide.macro package for more details...
  
  

Instances of these helpers for a specific namespace can be obtained through the NamespaceAccessToken that you receive when accessing the namespace.

Content Interface

Structure Interface

NodeRevisionDescriptors class

NodeRevisionDescriptor class

NodeRevisionNumber class

Definition Node

1. Domain.xml Definition Node

From my understanding, the definition section sets where all the data concerning different parts of Slide will be stored. In the example all sub-stores (lock, content, etc...) are stored using "org.apache.slide.store.txfile.TxXMLFileDescriptorsStore", which essentially stores data in an XML formatted file.

<definition>
    <store name="tx">
       <parameter name="tlock-timeout">120</parameter>
       <nodestore classname="org.apache.slide.store.txfile.TxXMLFileDescriptorsStore">
           <parameter name="rootpath">store/metadata</parameter>
           <parameter name="workpath">work/metadata</parameter>
           <parameter name="defer-saving">true</parameter>
           <parameter name="timeout">120</parameter>
       </nodestore>
       <sequencestore classname="org.apache.slide.store.txfile.FileSequenceStore">
           <parameter name="rootpath">store/sequence</parameter>
       </sequencestore>
       <securitystore>
           <reference store="nodestore"/>
       </securitystore>
       <lockstore>
           <reference store="nodestore"/>
       </lockstore>
       <revisiondescriptorsstore>
           <reference store="nodestore"/>
       </revisiondescriptorsstore>
       <revisiondescriptorstore>
           <reference store="nodestore"/>
       </revisiondescriptorstore>
       <contentstore classname="org.apache.slide.store.txfile.TxFileContentStore">
           <parameter name="rootpath">store/content</parameter>
           <parameter name="workpath">work/content</parameter>
           <parameter name="defer-saving">true</parameter>
           <parameter name="timeout">120</parameter>
       </contentstore>
       <!-- uncomment if you want to use the sample Indexer -->
       <!-- be sure to have Lucene in your classpath             -->
       <!--
                <contentindexer classname="org.apache.slide.index.SampleTxtContainsIndexer">
                <parameter name="indexpath">./index</parameter>
                </contentindexer>
        -->
    </store>
    <scope match="/" store="tx"/>
</definition>

To setup Slide with multiple Store Definitions see MultiStoreConfig

1.1. General Store Information

Stores are low level services that handle the actual storage of content and related data. Stores are totally pluggable, enabling the use of the most appropriate storage method for the type of data to store.

Two different kinds of services exist:

• The Descriptors stores, which are responsible for storing structure, locks, metadata, etc.
• The Content stores, which is only responsible for storing the actual content.

This distinction has been made because it's easy to see that while some repositories are very efficient at managing and indexing small amounts of data (relational databases are a good example of this), others are best for storing big chunks of data (for example filesystems). Within Slide, every object can possibly have a different kind of backing low-level service. For example, some objects might be stored in a remote LDAP directory, while others could be stored in an local SQL database. Thus, the content of a namespace can be distributed across several different descriptors and content stores. It is up to the administrator to choose how objects will be stored using the Slide configuration file, which maps low-level services to individual nodes in the namespace. Services are attributed to nodes in the namespace. This mapping is automatically inherited by sub-nodes. Here is an example of how one namespace might be mapped into different low-level services:

1.2. Parameters

1.2.1. Cache Parameters

<parameter name="cache-mode">cluster</parameter>

Caching mode should be set to "cluster" when you want every change in the file system to be immediately displayed in Slide. Other options for this parameter are not yet known - if you know it please add / elaborate here

For more information see CacheConfiguration.

1.2.2. Locking

<parameter name="tlock-timeout">120</parameter>

This determines how many seconds pass before your Slide session times out?

1.2.3. Rootpath

<parameter name="rootpath">store/metadata</parameter>

1.2.4. Cache Timeout

For Slide 2.2 and above you can add this parameter for more caching with a timeout (100 sec in this case)

<parameter name="cache-timeout">100</parameter>
<parameter name="cache-mode">full</parameter>

1.3. Scope

"You need to add the scope to have the store (tx) visible."

<scope match="/" store="tx"/>

"So far, you can choose to configure the <scope> tags either directly underneath each store, or put all the <scope> tags at the bottom of configuring all your stores at this time. Soon there will be a standard and expectation, but for now lasse faire."

Basically this determines how you access your Slide applicatio. In the above example accessing the Slide application would be: http://localhost:8080/tx

1.4. General Store Definition Information (Low Level Services)

This describes low-level services configuration for the store. (For some reason, it was decided that these low level services also be called "stores" - this makes it a bit confusing.)

<contentstore classname="org.apache.slide.store.txfile.TxFileContentStore">

"classname" specifies the class that implements the sub-store in question. This hints at developers being able to create their own custom store, which is was Slide was designed for from the beginning. For more information see the CreateNewSlideStore entry.

The following are sub-store class implementions that are built into Slide -

TxFileContentStore

TxXMLFileDescriptorsStore

JDBCStore

FileSequenceStore

From my understanding (please correct me if I'm wrong), you have the following choices in regard to low level services related to stores.

1. Define the low level service by associating it with the appropriate concrete class

<securitystore classname="org.apache.slide.store.mem.TransientSecurityStore"/>

1. Define a low level service that can be referenced by other low level services as seen in nodestore

<nodestore classname="org.apache.slide.store.txfile.TxXMLFileDescriptorsStore">
    <parameter name="rootpath">store/metadata</parameter>
    <parameter name="workpath">work/metadata</parameter>
    <parameter name="defer-saving">true</parameter>
    <parameter name="timeout">120</parameter>
</nodestore>
<securitystore>
    <reference store="nodestore"/>
</securitystore>

"The reference means that for the security store the same object is used as is, is configured at the node store." To get a better understanding compare the default nodestore definition (above) and the nodestore definition using JDBC. The default nodestore stores all of its data in XML format text files while the nodestore below stores the data in predefined tables.

1.4.1. callback-store Parameter

<parameter name="callback-store">org.apache.slide.store.simple.WebdavFileStore</parameter>

1.4.2. rootpath Parameter

This is where all the resources in the "files, content, etc..." collection go to

<parameter name="rootpath">c:/tmp</parameter>

1.5. Content Store Low Level Service

<contentstore classname="org.apache.slide.store.txfile.TxFileContentStore">
    <parameter name="rootpath">store/content</parameter>
    <parameter name="workpath">work/content</parameter>
    <parameter name="defer-saving">true</parameter>
    <parameter name="timeout">120</parameter>
</contentstore>

1.6. Node Store Low Level Service

1.6.1. Default File Based Node Store Low Level Service

Using the default node store, will have the namespace's data be stored in XML formatted text files.

<nodestore classname="org.apache.slide.store.txfile.TxXMLFileDescriptorsStore">
    <parameter name="rootpath">store/metadata</parameter>
    <parameter name="workpath">work/metadata</parameter>
    <parameter name="defer-saving">true</parameter>
    <parameter name="timeout">120</parameter>
</nodestore>

1.6.2. JDBC Node Store Low Level Service

Of course, for ease of maintenance most people will probably want to use a database to store most of the data related to a Slide namespace. In the example below, most sub-stores (except content) are using the JDBC configured nodestore.

Note

If you want to try a JDBC nodestore you also have to create all the necessary tables and views that Slide expects. You can use the scripts (configured for most major database servers) found in jakarta-slide-2.1-tomcat-5.0.28/webapps/slide/db-schema/ (for 2.1).

<nodestore classname="org.apache.slide.store.impl.rdbms.JDBCStore">
    <parameter name="adapter">org.apache.slide.store.impl.rdbms.PostgresRDBMSAdapter</parameter>
    <parameter name="driver">org.postgresql.Driver</parameter>
    <parameter name="url">jdbc:postgresql://19.26.54.86:5432/db_name</parameter>
    <parameter name="user">test</parameter>
    <parameter name="password">12345</parameter>
    <parameter name="dbcpPooling">true</parameter>
    <parameter name="maxPooledConnections">10</parameter>
    <parameter name="isolation">SERIALIZABLE</parameter>
    <parameter name="compress">false</parameter>
</nodestore>

<parameter name="driver">org.postgresql.Driver</parameter>

Put the name of the jdbc driver you want to use here.

<parameter name="url">jdbc:postgresql://19.26.54.86:5432/db_name</parameter>

The database url varies by database and jdbc driver. Consult the accompanying jdbc documentation.

<parameter name="user">test</parameter>
<parameter name="password">12345</parameter>

A username / password combination that can access the database.

<parameter name="dbcpPooling">true</parameter>
<parameter name="maxPooledConnections">10</parameter>

This enables DBCPPooling and specifies the number of connections it can have.

<parameter name="compress">false</parameter>

I believe if you set this true, Slide will compress (using zip) incomming data and uncompress outbound data. This is quite useful.

1.7. Sequence Store

1.8. Security Store

1.9. Lock Store

J2EEStore

<definition>
    <store name="j2ee">
        <nodestore classname="org.apache.slide.store.impl.rdbms.J2EEStore">
            <parameter name="datasource">jdbc/mtx</parameter>
            <parameter name="adapter">org.apache.slide.store.impl.rdbms.MySqlRDBMSAdapter</parameter>
            <parameter name="compress">false</parameter>
        </nodestore>
        <securitystore>
            <reference store="nodestore"/>
        </securitystore>
        <lockstore>
            <reference store="nodestore"/>
        </lockstore>
        <revisiondescriptorsstore>
            <reference store="nodestore"/>
        </revisiondescriptorsstore>
        <revisiondescriptorstore>
            <reference store="nodestore"/>
        </revisiondescriptorstore>
        <contentstore>
            <reference store="nodestore"/>
        </contentstore>
    </store>
    <scope match="/" store="j2ee"/>
</definition>

You have to create the tables of the database schema manually. Schemata are available in src/conf/schema if you have the source distribution or in slide/db-schema if you have the Tomcat bundled or binary distribution.

If your store is not configured using a datasource looked up using JNDI you will have to provide more information to Slide like this for example:

	
<definition>
<store name="MySqlStore">
  <nodestore classname="org.apache.slide.store.impl.rdbms.JDBCStore">
    <parameter name="adapter">org.apache.slide.store.impl.rdbms.MySqlRDBMSAdapter</parameter>
    <parameter name="driver">com.mysql.jdbc.Driver</parameter>
    <parameter name="url">jdbc:mysql://localhost/Slide</parameter>
    <parameter name="user">root</parameter>
    <parameter name="dbcpPooling">true</parameter>
    <parameter name="maxPooledConnections">10</parameter>
    <parameter name="isolation">SERIALIZABLE</parameter>
    <parameter name="compress">false</parameter>
  </nodestore>
  <contentstore>
    <reference store="nodestore" />
  </contentstore>
  <securitystore>
    <reference store="nodestore" />
  </securitystore>
  <lockstore>
    <reference store="nodestore" />
  </lockstore>
  <revisiondescriptorsstore>
    <reference store="nodestore" />
  </revisiondescriptorsstore>
  <revisiondescriptorstore>
    <reference store="nodestore" />
  </revisiondescriptorstore>
 </store>
 <scope match="/" store="MySqlStore"/>
</definition>

Locks Needed

1. Table of accesses per method

• All write and read requests have a read access from the accessed uri to the root uri
• All write and read requests have a read access to the users and roles folder
• Even a pure read access might create a new user in the users folder if user auto creation is set
• All writing requests have an additional write access to the history folder if auto versioning is turned on