JCR Import Export Tool

In This Topic

Installing the JCR Import/Export Tool

Copy the file jcr-import-export-tool-x.y.z*.jar to an arbitrary location, and unpack it with the command:

Windows
jar -xf jcr-import-export-tool-x.y.z*.jar lib\ logging.properties

Linux
jar -xf jcr-import-export-tool-x.y.z*.jar lib/ logging.properties

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.

Back to top

Export

To export a complete repository, defined by the <xperiencentral-root>\work\jcr\repository.xml and with the <xperiencentral-root>\work\jcr\repository\ directory as its home directory:

-Djava.util.logging.config.file=logging.properties -Xmx512M -jar jcr-import-export-tool-x.y.z*.jar -c <xperiencentral-root>\work\jcr\repository.xml -d <xperiencentral-root>\work\jcr\repository\ -ns -nt -e export.zip

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.

Back to top

Import

To import a previously exported repository (the export.zip) into an existing repository:

-Djava.util.logging.config.file=logging.properties -Xmx512M -jar jcr-import-export-tool-x.y.z*.jar -c <xperiencentral-root>\work\jcr\repository.xml -d <xperiencentral-root>\work\jcr\repository\ -ns -nt -i export.zip

The existing namespaces and node types are not deleted during an import, but that other content is overwritten.

Back to top

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:

Use the following command:

java -Djava.util.logging.config.file=logging.properties -Xmx512M -jar Jcr-Import-Export-Tool-x.y.z*.jar -c <xperiencentral-root>\work\jcr\repository.xml -d <xperiencentral-root>\work\jcr\repository\ -ns -nt -s instructions.xml -j <xperiencentral-apache-tomcat-root>\conf\server.xml

For non-JNDI:

java -Djava.util.logging.config.file=logging.properties -Xmx512M -jar jcr-import-export-tool-x.y.z*.jar -c <xperiencentral-root>\work\jcr\repository.xml -d <xperiencentral-root>\work\jcr\repository\ -ns -nt -s instructions.xml

For IBM Websphere and Oracle JBoss:

$ 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

<?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>

Back to top

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.

• If you are using Apache Tomcat for your application server, the connection details are defined in <tomcat-home>/conf/server.xml and therefore the path to the server.xml can be passed as a -j attribute.
• If you are using IBM WebSphere or Oracle Jboss AS, the connection details need to be passed individually:

• • driver class: -jd
  • database url: -jn
  • username: -ju
  • password: -jp

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.

 

Back to top