24 Using the Content Server JCR Adapter

This chapter describes how to use the Java Content Repository (JCR) adapter for Oracle WebCenter Content Server.

This chapter includes the following sections:

24.1 About the Java Content Repository Adapter

The Java Content Repository API is a specification for accessing content repositories in a standardized manner. This specification was developed under the Java Community Process as JSR-170 and includes the Content Repository for Java API and the Java Content Repository (JCR).

The standard APIs associated with the JSR-170 specification are functional and exposed in the JCR adapter for Content Server. The JCR 1.0 API is required and must be predeployed and integrated as part of the underlying framework.

Oracle adapters are fully standards based and compliant with both the J2EE Connector Architecture and the Web Services Architecture. The JCR adapter can be deployed on any JSR-170-compliant application to enable communication with Content Server through the standards-based JCR specification.

24.1.1 JCR Data Model

The JCR standard uses a hierarchical data model based on extensible node types and content properties. This data model is used by the repository's underlying storage subsystems. For more information, see the JCR and JSR-170 standards.

  • The nt:folder node type represents a structured collection of nodes. It is closely related to the directory or folder concept found in many file systems and is the node type that is normally used when mapping file system directories to a content repository.

  • The nt:resource child node is normally used instead of a plain binary property when more resource metadata is required.

  • The nt:file node type represents a file with some content.

  • The nt:unstructured node type permits all kinds of properties and child nodes to be added to a node. It is normally used when nothing is known about the content that will be stored within a node.

24.1.2 JCR Adapter Data Model for Content Server

This is the data model for the Content Server JCR adapter:

A Folder [nt:folder]
+- jcr:content [nt:resource]
   +- jcr:created DATE
      <returns dCreateDate for the folder>
   +- ojcr:owner STRING
      <returns dCollectionOwner for the folder>
   +- ojcr:creator STRING
      <returns dCollectionCreator if it is available,
      otherwise it returns dCollectionOwner>
   +- ojcr:lastModifier STRING
      <returns dCollectionModifier if it is available,
       otherwise it returns dCollectionOwner
   +- ojcr:lastModified STRING
      <returns dLastModifiedDate>
   +- ojcr:displayName STRING
      <returns dCollectionName for the folder>
   +- idc:defaultMetadata [nt:unstructured]
      <metadata that should by default be applied to content checked
      into this folder. see idc:metadata under nt:file/jcr:content for
      example fields>
  +- idc:folderMetadata [nt:unstructured]
     +- idc:dCollectionName STRING
     +- idc:dCreateDate DATE
     +- idc:dCollectionPath STRING
     +- idc:dLastModifiedDate DATE
     +- idc:dCollectionOwner STRING
     +- idc:dCollectionGUID STRING
     +- idc:dParentCollectionID INTEGER
     +- idc:dCollectionQueries INTEGER
     +- idc:dCollectionEnabled INTEGER
     +- idc:dCollectionInherit INTEGER
     +- idc:dChildManipulation INTEGER
     +- idc:dCollectionID INTEGER
     +- idc:dCollectionCreator STRING
     +- idc:dCollectionModifier STRING
  +- idc:folderPermissions [nt:unstructured]
     +- idc:userCanRead INTEGER
     +- idc:userCanWrite INTEGER
     +- idc:userCanDelete INTEGER

A Document.txt [nt:file]
+- jcr:content [nt:resource]
   +- jcr:data=...
   +- jcr:created DATE 
      <returns dDocCreatedDate from the RevClasses table>
   +- ojcr:creator STRING
      <returns dDocCreator from the RevClasses table>
   +- ojcr:lastModifier STRING
      <returns dDocLastModifier from the RevClasses table>
   +- ojcr:lastModified STRING
      <returns dDocLastModifiedDate >
   +- ojcr:author STRING
      <returns dDocAuthor for the document>
   +- ojcr:comment STRING
      <if xComments exists as a metadata field, that is returned>
   +- ojcr:displayName STRING
      <returns the filename>
   +- ojcr:language STRING
      <if xIdcLanguage exists as a metadata field, that is returned>
   +- idc:metadata [nt:unstructured]
      <returns values for everything in the RevClasses table, 
      please see the definition of that table to see exactly what is defined
      +- idc:dID INTEGER
      +- idc:dDocName STRING
      +- idc:dDocTitle STRING
      +- idc:dDocAuthor STRING
      +- idc:dRevClassID INTEGER
      +- idc:dRevisionID INTEGER
      +- idc:dRevLabel STRING
      +- idc:dIsCheckedOut INTEGER
      +- idc:dSecurityGroup STRING
      +- idc:dCreateDate DATE
      +- idc:dInDate DATE
      +- idc:dOutDate DATE
      +- idc:dStatus STRING
      +- idc:dReleaseState STRING
      +- idc:dWebExtension STRING
      +- idc:dProcessingState STRING
      +- idc:dMessage STRING
      +- idc:dDocAccount STRING
      +- idc:dReleaseDate DATE
      +- idc:dRendition1 STRING
      +- idc:dRendition2 STRING
      +- idc:dIndexerState STRING
      +- idc:dPublishType STRING
      +- idc:dPublishState STRING
      +- idc:dWorkflowState STRING
      +- idc:dRevRank INTEGER
         <all custom metadata properties for a revision
          like idc:xComments STRING>

24.2 Installing Required APIs and Runtime Libraries

The JCR adapter can be used with any application that supports the JSR-170 specification, but the adapter requires a custom integration. This custom integration requires that an underlying framework consisting of several APIs and runtime libraries be installed.


All of these APIs and runtime libraries are provided with Oracle JDeveloper and WebCenter, with the exception of the JCR adapter and Remote Intradoc Client (RIDC).

24.2.1 Installing ADF Runtime Libraries

Several of the Application Development Framework (ADF) runtime libraries are required and must be installed on your application. These files are available in your Oracle JDeveloper instance. You can perform the installation using the ADF Runtime Installer wizard in JDeveloper, or you can do it manually.

The following ADF runtime libraries must be deployed on your application:

  • adf-share-base.jar

  • adf-share-ca.jar

  • adf-share-support.jar

  • adflogginghandler.jar

If you choose to manually install these libraries on your application, they must be installed in the lib directory. For example, an installation on Tomcat would use the TOMCAT_HOME/common/lib directory, and an installation on Oracle WebLogic Server would use the WL_HOME/ADF/lib directory. (For Oracle WebLogic Server, you must create the ADF and lib directories.)

24.2.2 Deploying Remote Intradoc Client (RIDC)

Remote Intradoc Client must be deployed on your application. RIDC provides a thin communication API for communication with Oracle WebCenter Content Server. This API removes data abstractions to the Oracle WebCenter Content Server instance while still providing a wrapper to handle connection pooling, security, and protocol specifics. RIDC is included with the JCR adapter distribution file and is available from the Oracle Technology Network (OTN).

For more information, see Chapter 23, "Using RIDC to Access Content Server."

24.2.3 Deploying the JCR API

The Java Content Repository (JCR) API must be deployed on your application. The JCR API is available from Oracle JDeveloper or for download from The Apache Software Foundation web site at http://www.apache.org/

The JCR API is also part of the JSR-170 specifications download from the Java Community Process web site at


24.2.4 Installing the JCR Integration Libraries

The following JCR integration libraries are required and must be deployed on your application:

  • jcr-common-runtime.jar

  • ojcr.jar

  • ojdbc5.jar

These files are available in your Oracle JDeveloper instance.

24.2.5 Installing the XML Integration Files

The following XML integration libraries are required and must be deployed on your application:

  • xmlparserv2.jar

  • xquery.jar

These files are available in your Oracle JDeveloper instance.

24.3 Deploying the JCR Adapter

The JCR adapter must be deployed on your application to enable communication with Content Server. The JCR adapter utilizes Remote Intradoc Client (RIDC) as part of the underlying framework and works in conjunction with the general JSR-170 architecture.

Follow the general instructions of your specific JSR-170-compliant application for deploying JCR adapters. The JCR adapter uses an embedded deployment descriptor (rep_descriptor.xml). Upon deployment, many applications will use the deployment descriptor to populate the configuration entries as part of an administration interface or deployment wizard. If your application does not use an administration interface or deployment wizard, you will need to edit the deployment descriptor directly and provide the required values.

24.4 Configuring Communication with Content Server

To enable communication between the JCR adapter and Content Server, you configure these items:

  • Communication method

  • Socket communication (listener port)

  • Secure Socket Communication (SSL)

  • Web communication (web servlet filter)

  • User agent

  • Cache settings

24.4.1 Supplying a Communication Method

You must supply the provider name and communication method with this configuration setting:

CIS_SOCKET_TYPE_CONFIG: This configuration setting defines the communication method with Content Server. The options are socket, socketssl, and web. For example:

  • The socket (listener port) communication method specifies that RIDC should use the Content Server listener port. If socket is used as the communication method, you must provide the required configuration values.

  • The socketssl communication method specifies that secure socket communication (SSL) be used as the communication protocol. If socketssl is used as the communication method, you must provide configuration values for both socket communication and secure socket communication.

  • The web (web server filter) communication method specifies that RIDC should communicate through the web server filter, which requires individual authentication for each request. If web is used as the communication method, you must provide the required configuration value.

24.4.2 Configuring Socket Communication (Listener Port)

You must supply values for these configuration settings if secure socket communication (SSL) is used as the communication protocol:

  • SERVER_HOST_CONFIG: The hostname of the machine on which Content Server is running. The default value is localhost.

  • SERVER_PORT_CONFIG: The port on which Content Server is listening. The default value is 16200.


24.4.3 Configuring Secure Socket Communication (SSL)

You must supply values for both socket communication (listener port) and these configuration settings if secure socket communication (SSL) is used as the communication protocol:

  • KEYSTORE_LOCATION: The location and name of the keystore file.

  • KEYSTORE_PASSWORD: The password for the keystore file.

  • PRIVATE_KEY_ALIAS: The private key alias for authentication.

  • PRIVATE_KEY_PASSWORD: The private key password.


For information about socket communication values, see Section 24.4.2, "Configuring Socket Communication (Listener Port)."

24.4.4 Configuring Web Communication (Web Server Filter)

You need to supply a value for one of these configuration settings if your application is connecting through the web server filter (web communication):

  • SERVER_WEB_CONTEXT_ROOT_CONFIG: The web server context root for Content Server, in the format /context_root. This setting provides a more seamless integration for Oracle WebCenter and for other application integrations.

    For example: /cs

  • SERVER_WEB_URL_CONFIG: The full URL to the Content Server web server extension. Include the protocol (usually http or https), host name, port, relative web root, and extension root (usually idcplg). If a port other than port 80 is used, the port number needs to be specified.

    For example: http://myserver.example.com:8080/cs/idcplg/


24.4.5 Configuring the User Agent

You can optionally supply a value for this configuration setting to identify JCR requests:

  • CIS_USER_AGENT_CONFIG: A string to append to the RIDC user agent. This value can be set to help identify requests made by the JCR adapter.


24.4.6 Supplying Cache Settings

You can optionally supply values for these cache settings:

  • VCR_CACHE_INVALIDATION_INTERVAL: Polling interval used by the WebCenter Content SPI to check for cache invalidations, in minutes. Defaults to 0 (zero), cache invalidation disabled. The minimum value is 2 minutes.

  • VCR_BINARY_CACHE_MAX_SIZE: Maximum size of documents stored in the VCR binary cache, in bytes. The default value is 102400 (800 KB).


24.5 Finding Information About a Content Item

Content managed by Content Server is primarily tracked by four tables:

These tables track the content's metadata, state, and actions as well as information that is associated with each file.


This table tracks core information about each revision of the content:

  • One row per revision

  • Different revisions with the same content that share the same content ID and RevClass ID

  • System metadata for each revision:

    • Metadata for revisions: content ID, title, author, check-in date, and so on

    • Metadata for categorization and security: type, security group, doc account

  • State information for various actions:

    • Indexing

    • Workflow

    • Document conversion

  • Numeric IDs and text labels to help track and retrieve a revision:

    • A unique dID value for each revision (the primary key in the table)

    • A unique dRevClassID value for the content

    • A revision ID to mark the revision number for each revision


This table tracks information for files that are associated with each content revision:

  • One row per revision

  • Multiple rows per revision, one row for each of these files:

    • Primary

    • Alternate

    • Web-viewable

  • File information: original name, location, language, size, and so on


This table contains extended metadata fields:

  • One row per revision

  • One column per metadata field

  • Definition for each field stored in the DocMetaDefinition table


This table tracks information for each content revision:

  • One row per content item

  • Row locked for content modification

  • Unique dDocName and RevClassId values

  • Current indexed revision

  • Dates and users:

    • Creation date and creator

    • Last modified date and user

    • Owner

24.6 Using a Search Index

Content Server provides various ways to search the repository. Metadata searches can be based on the Revisions, Documents, DocMeta, and RevClasses tables. To efficiently perform text searches, the full-text search feature of Oracle Database can be utilized, and the IdcText table can be created to hold the search index.


This table contains selected columns from the Revisions, Documents, DocMeta, and RevClasses tables as well as columns for other data:

  • It contains a predefined list from the Revisions, RevClasses, and Documents tables.

  • It contains custom metadata that is indicated as searchable from the DocMeta table.

  • The OtsMeta column (CLOB field) contains an SDATA section and additional indexable fields that are not in the other columns. However, SDATA has significant limitations.

  • The OtsContent column contains an indexable document.

  • The ResultSetInterface column can be used for sorting or count estimation, or to drill down.

24.7 Using the File Store Provider

The File Store Provider can be used to distribute files managed by Content Server on the file system, a database, other devices, or any combination of these. The files are stored in SecureFiles in Oracle WebCenter Content Server 11g. For database-backed file storage, the FileStorage and FileCache tables store the information related to each file.


This table stores file information and some additional information:

  • File stored in a BLOB field (SecureFiles in Oracle WebCenter Content Server 11g)

    The database administrator can turn on additional BLOB optimizations. For example, deduplication, compression, and encryption with SecureFiles.

  • Values for dID and dRenditionID that point to a particular file managed by Content Server

  • Tracking information in a small number of fields: last modified date and file size


This table stores pointers for files cached on the file system, for certain types of processing (extraction, conversion, and so on), and for quick access by the web server. This pointer is also used to perform cleanup.