Session.getNodeByUUID() about 2.5 times faster of Session.getItem(String) and only 25% faster of Node.getNode(String). See the daily tests results for such comparisons, e.g.

http://tests.exoplatform.org/jcr.html

Until it's applicable for a business logic it can be. But take in account the paths are human readable and lets you think in hierarchy. If it's important a location based approach is preferable.

Use Session.itemExists(String absPath), Node.hasNode(String relPath) or Property.hasProperty(String name). It's also is possible to check Node.hasNodes() and Node.hasProprties().

JCR Observation's a way to listen on persistence changes of a Repository. It provides several options to configure the listener for an interesting only changes. To use properly, it's important to understand concept of events filtering for a registered EventListener (8.3.3 Observation Manager). An often confusing part, it's the absPath, it's an associated parent of a location you want to observe events on. I.e. it's a parent of child node(s) or this parent property(ies); if isDeep is true then you'll get events of all the subtree of child nodes also. The same actual for uuid and nodeTypeName parameters of ObservationManager.addEventListener() method.

No, direct access to items via JCR API is more efficient. Search will consume additional resources for index querying and only then return the items.

By default (if query do not contains any ordering statements) result nodes is sorted by document order.

No, it does not supported. There is two ways to ordering results, when path may be used as criteria:

Order by jcr:path

If no order specification is supplied in the query statement, implementations may support document order on the result nodes (see 6.6.4.2 Document Order). And it is sorted by order number.

By default, (if query do not contains any ordering statements) result nodes is sorted by document order.

SELECT * FROM nt:unstructured WHERE jcr:path LIKE 'testRoot/%'

For specified jcr:path ordering there is different proceeding in XPath and SQL:

1. Indexer uses jcr:encoding property of nt:resource node (used as jcr:content child node of nt:file) 2. if no jcr:encoding property set the Document Service will use the one configured in the service (defaultEncoding) 3. if nothing is configured a JVM, the default encoding will be used

If the question is about the performance, it is difficult to answer, because each database database can be configured to have better performance in special case. According to the results of our internal tests the best choice is Oracle 11G R2 even when we store the binary data in the db, on other db it is recommended to store the binary data on the file system unless you have only small file content to store. MySQL and PostgreSQL also demonstrated in our benchmark results that they could provide good performance. DB2 and MSSQL are slower in default configurations. Default configuration of Sybase leader of slowness. But in this question, take the database server maintenance in account. MySQL and PostgreSQL are simple in installation and can work even on limited hardware. Oracle, DB2, MSSQL or Sybase need more efforts. The same actual for maintenance during the work. Note for Sybase: "check-sns-new-connection" data container configuration parameter should be set to "true". For testing purpose, embedded database such as HSQLDB is the best choice. Apache Derby and H2 also supported. But H2 surprisingly needs "beta" feature enabled - MVCC=TRUE in JDBC url.

To allow multiple character sets to be sent from the client, the UTF-8 encoding should be used, either by configuring utf8 as the default server character set, or by configuring the JDBC driver to use UTF-8 through the characterEncoding property. MySQL database should be created in single-byte encoding, e.g. "latin1":

CREATE DATABASE db1 CHARACTER SET latin1 COLLATE latin1_general_cs;

eXo JCR application (e.g. GateIn) should use JCR dialect "MySQL-UTF8".

In other words: MySQL database default encoding and JCR dialect cannot be UTF8 both. Use single-byte encoding (e.g. "latin1") for database and "mysql-utf8" dialect for eXo JCR.

Notice: "MySQL-UTF8" dialect cannot be auto-detected, it should be set explicitly in configuration.

Index's key length of JCR_SITEM (JCR_MITEM) table for mysql-utf8 dialect is reduced to 765 bytes (or 255 chars).

To enable JCR working properly with Sybase, a property 'check-sns-new-connection' with 'false' value is required for each workspace data container:

<container class="org.exoplatform.services.jcr.impl.storage.jdbc.optimisation.CQJDBCWorkspaceDataContainer">
  <properties>
    <property name="source-name" value="jdbcjcr" />
    <property name="dialect" value="auto" />
    <property name="multi-db" value="true" />
    <property name="max-buffer-size" value="200k" />
    <property name="swap-directory" value="target/temp/swap/ws" />
    <property name="swap-directory" value="target/temp/swap/ws" />
    <property name="check-sns-new-connection" value="false" />
  </properties>

Session session = repository.login(credentials);
try
{
// here your code
}
finally
{
session.logout();
}

No. Any instance of Session or Node (acquired through session) shouldn't be used after loging out anymore. If you use Session or Node after logging out then you get an exception.

So we have configured JCR in standalone mode and want to reconfigure it for clustered environment. First of all, let's check whether all requirements are satisfied:

So now, we need to configure the Container a bit. Check exo-configuration.xml to be sure that you are using JBossTS Transaction Service and Infinispan Transaction Manager, as shown below.

<component>
   <key>org.infinispan.transaction.lookup.TransactionManagerLookup</key>
   <type>org.exoplatform.services.transaction.infinispan.JBossStandaloneJTAManagerLookup</type>
</component>
   
<component>
  <key>org.exoplatform.services.transaction.TransactionService</key>
  <type>org.exoplatform.services.transaction.infinispan.JBossTransactionsService</type>
  <init-params>
    <value-param>
      <name>timeout</name>
      <value>3000</value>
    </value-param>
  </init-params>   
</component>

Next stage is actually the JCR configuration. We need Infinispan configuration templates for : data-cache, indexer-cache and lock-manager-cache. Later they will be used to configure JCR's core components. There are pre-bundled templates in EAR or JAR in conf/standalone/cluster. They can be used as is or re-written if needed. And now, re-configure a bit each workspace. Actually, a few parameters need changing, e.g. <cache>, <query-handler> and <lock-manager>.

Those properties have the same meaning and restrictions as in the previous block. The last property "max-volatile-time" is not mandatory but recommended. This notifies that the latest changes in index will be visible for each cluster node not later than in 60s.

That's all. The JCR is ready to join a cluster.

There is few steps:

If there is no any results, that means there is no suggestion, so word is correct or spellcheckers dictionary do not contain any words like the checked word.

There is two parameters in jcr QueryHandler configuration:

Minimal distance is counted as Levenshtein distance between checked word and spellchecker suggestion.

MorePopular paramter affects in next way: If "morePopular" disabled:

If "morePopular" enabled:

Yes, JCR is support hot backup. Will use org.exoplatform.services.jcr.ext.backup.BackupManager.

This is known as a finder bug started from Mac OS v.10.5.3 and not yet fixed, .

For more details follow:&nbsp; Apple Disscussion thread.

Use "cache-control" configuration parameter.

The value of this parameter must contain colon-separated pairs "MediaType:cache-control value"

For example, if you need to cache all text/xml and text/plain files for 5 minutes (300 sec.) and other text/\* files for 10 minutes (600 sec.), use the next configuration:

<component>
   <type>org.exoplatform.services.jcr.webdav.WebDavServiceImpl</type>
   <init-params>
      <value-param>
         <name>cache-control</name>
         <value>text/xml,text/plain:max-age=300;text/*:max-age=600;</value>
      </value-param>
   <init-params>
<component>

Simple Requests

For simple request such as: GET, HEAD, MKCOL, COPY, MOVE, DELETE, CHECKIN, CHECKOUT, UNCHECKOUT, LOCK, UNLOCK, VERSIONCONTROL, OPTIONS

perform:

curl -i -u 'user:pass' -X 'METHOD_NAME' 'resource_url'

for example to create a folder named test perform:

curl -i -u 'root:exo' -X MKCOL 'http://localhost:8080/rest/jcr/repository/production/test

to PUT a test.txt file from your current folder to "test "folder on server perform:

curl -i -u 'root:exo' -X PUT 'http://localhost:8080/rest/jcr/repository/production/test/test.txt' -d @test.txt

Requests with XML body

For requests which contains xml body such as: ORDER, PROPFIND, PROPPATCH, REPORT, SEARCH

add -d 'xml_body text' or -d @body.xml

(body.xml must contain a valid xml request bidy.) to you curl-command:

curl -i -u 'user:pass'  -X 'METHOD_NAME' -H 'Headers' 'resource_url' -d 'xml_body text'

For example about finding all files containing "test" perform:

curl -i -u "root:exo" -X "SEARCH" "http://192.168.0.7:8080/rest/jcr/repository/production/" -d
"<?xml version='1.0' encoding='UTF-8' ?>
   <D:searchrequest xmlns:D='DAV:'>
      <D:sql>SELECT * FROM nt:base WHERE contains(*, 'text')</D:sql>
</D:searchrequest>"

If you need to add some headers to your request, use \-H key.

To have more information about methods parameters, you can find in HTTP Extensions for Distributed Authoring specification.

OS client (Windows, Linux etc) doesn't set an encoding in a request. But eXo JCR WebDAV server looks for an encoding in a Content-Type header and set it to jcr:encoding. See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html, 14.17 Content-Type. e.g. Content-Type: text/html; charset=ISO-8859-4 So, if a client will set Content-Type header, e.g. JS code from a page, it will works for a text file as expected.

If WebDAV request doesn't contain a content encoding, it's possible to write a dedicated action in a customer application. The action will set jcr:encoding using its own logic, e.g. based on IP or user preferences.