This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Skip to end of metadata
Go to start of metadata

Introduction

The CAS-File Manager supports a tool to export the metadata catalog from one file manager to another filemanager. This document describes how to perform this process.

Requirements

  1. Two file-manager instances running (presumably on different ports, on same or different machines)
  2. Common product-type policy existing on both file-manager instances. NOTE - you can specify the transfer of only specific product types, so it is not necessary to have all of the policy between two file manager instances be identical)

See import/export tool usage

cd $FILEMGR_HOME/bin
java -Djava.ext.dirs=../lib org.apache.oodt.cas.filemgr.tools.ExpImpCatalog

Running the transfer

The below example shows how to copy the entire metadata contents of the ‘GenericFile’ product type, from a source FileManager to a destination FileManager.

NOTE - The product type which you want to copy from a source Filemanager MUST already exist on the destination Filemanager's policy. Moreover, the destination Filemanager's policy MUST be using the same product type name and product type ID as the source Filemanager

NOTE - The funny syntax of the value for the ‘--types’ argument requires you to specify both the name of the product type as well as the unique identifier. Also, the special characters used in the value of this argument are required and need to be escaped

NOTE - The source filemanager is set to run on port 9000, and the destination is set to run on 9009 – this is entirely dependent on your own setup!

java -Djava.ext.dirs=../lib org.apache.oodt.cas.filemgr.tools.ExpImpCatalog --source http://localhost:9000 --dest http://localhost:9009 --types GenericFile\|urn\:oodt\:GenericFile

1 Comment

  1. Hey Rishi,

    This is a great starter guide to using the Tool. I am going to add a use case I just encountered on a project, where we moved from the default Lucene Catalog with XML Policy files into a PostgreSQL (or any DataSource Catalog really). Our case is a little different because we are using a hybrid approach between using the RDBMS as the Catalog and keeping the XML Files for Policy.