| Anchor | ||||
|---|---|---|---|---|
|
| Excerpt |
|---|
| Info |
Beginning in version R28, XperienCentral no longer uses the Apache Jackrabbit JCR indexing solution by default. This topic is only relevant to users of XperienCentral versions R27 and lower or if you configure XperienCentral to use Apache Jackrabbit. See The XperienCentral JCR Index for more information. |
In This Topic
| Table of Contents | |||
|---|---|---|---|
|
|
...
Installing the JCR Import/Export Tool
...
The tool is now usable via the command line. Note that the tool should be started from its installation directory. If the application terminates abnormally, a nonzero status code is returned. If the operation was successful, the status code will be zero.
Error message | Solutions |
|---|---|
java.io.IOException | Remove the database. |
| Could not register namespace mapping wo -> http://gx.nl/wm9object | Remove the /repository/ directory. |
...
...
Export
To export a complete repository, defined by the <xperiencentral-root>\work\jcr\repository.xml and with the <xperiencentral-root>\work\jcr\repository\
...
The export functionality also includes the option to specify a set of absolute paths to export. This may be helpful if, for example only the /configuration subtree needs to be imported.
...
Import
To import a previously exported repository (the export.zip) into an existing repository:
...
The existing namespaces and node types are not deleted during an import, but that other content is overwritten.
...
JCR Substitution Operations
The contents of a repository can be changed using an XML document (the XML document is called instructions.xml). This XML document contains a set of operations that have to be executed against the contents of the JCR repository. All operations use an Xpath query for retrieving all matching nodes from the repository. The operations are performed on these matching nodes by retrieving all properties of the nodes and checking whether the name of the property matches any of the property names that have been specified in the operation. The values of the matching properties of the matching nodes are modified by using one of the four following operations:
| Operation | Description |
|---|---|
| All assigned values will be removed and replaced by the specified list of values. |
| The specified list of values will be appended to the existing set of values. |
| All assigned values for the property will be removed. |
substitute | Matches the pattern regular expression to the assigned values. All matching parts are replaced by the replacement argument. See http://java.sun.com/j2se/1.5.0/docs/api/java/util/regex/Pattern.html for description of the allowed patterns. |
Use the following command:
...
| Code Block |
|---|
$ java -Djava.util.logging.config.file=logging.properties -Xmx512M -jar JcrImportExportTool-x.y.z*.jar -c <xperiencentral-root>\work\jcr\repository.xml -d <xperiencentral-root>\work\jcr\repository\ -ns -nt -s instructions.xml -jd com.mysql.jdbc.Driver -jn jdbc:mysql://localhost:3306/dbname?autoReconnect=true -ju root -jp admin |
Example Instruction.xml
...
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<?xml version="1.0"?>
<mapping xmlns="http://webmanager.gx.nl/xsd/JCRmapping/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://webmanager.gx.nl/xsd/JCRmapping/1.0.0 webmanager-jcr-mapping-V1.0.0.xsd">
<description></description>
<operations>
<!-- set the hostnames -->
<set>
<query>//element(*,wm:website_settings)</query>
<properties>
<property>wm:backend_hostname</property>
</properties>
<values>
<value>webmanager.test.gx.nl</value>
</values>
</set>
<add>
<query>//element(*,wm:website_settings)</query>
<properties>
<property>wm:backend_server_alias</property>
</properties>
<values>
<value>webmanager.gx.nl</value>
</values>
</add>
<substitute>
<query>//element(*,wm:dbcpmanager)</query>
<properties>
<property>wm:datasourceurl</property>
</properties>
<pattern>(.*)@production\.gx\.nl(.*)</pattern>
<replacement>$1@test.gx.nl$2</replacement>
</substitute>
<remove>
<query>//element(*,wm:website_settings)</query>
<properties>
<property>wm:frontend_server_alias</property>
</properties>
</remove>
</operations>
</mapping>
|
...
...
JNDI
For installations that make use of JNDI to access the database, a different set of arguments needs to be passed into the command. To determine if JNDI is being used, simply view the repository.xml. If the driver is javax.naming.InitialContext, JNDI is being used: <param name="driver" value="javax.naming.InitialContext" />
Because the repository.xml by default does not contain the actual connection details and no application server context is available during the execution of this tool, it is necessary to provide these connection details directly or indirectly in the arguments passed.
...
In the background of the execution of the tool, a copy of the passed repository.xml is created that is populated with connection details and then used by the tool. After execution, the file is deleted again. This generated file can be viewed by passing --keep-generated as an argument.
When in JNDI mode, if the -d argument points to an existing JCR index, this index will be deleted as a whole. After execution of the tool in JNDI mode, the resulting index will also be deleted again. The reason for doing so has to do with the fact with an actual connection, a populated repository.xml copy is used and thus connection details are stored in files within the resulting index. This needs to be undone in order to ensure that when the application server runs again, it will make use of JNDI via the application server context.
Note also that if the -d argument points to an existing JCR index, this index will be deleted as a whole. Also after execution of the tool in JNDI mode, the resulting index will also be deleted again. The consequence of this deletion is that there is always a need to build a full index twice when using this tool using the copy process of an environment: First by this tool and secondly when the application server starts.