Tutorials (#3) - Transitioning to eXist-db 2.0 (#11) - Message List
The eXist-db 2.0 (Tech Preview) is upon us, so lets talk about what this means for ESTEST software. First, this post is NOT a migration tutorial; issues with importing backups made from an eXist-db 1.4.x distribution to the new 2.0 version have yet to be resolved. This does not mean that eXist-db 2.0 cannot be used with the newest version of ESTEST >= 1.4.x--you can still setup a new ESTEST server with eXist-db 2.0. There are, however, a few changes that server administrators should be aware of with the eXist-db 2.0 distribution.
- The ZIP file generated by the backup function in the eXist-db 1.4.x client.sh tool cannot be directly restored in the 2.0 distributions. We provide migration scripts that fix the most severe issues with the restoration process mostly to do with how permissions are treated between 1.4.x and 2.x distributions. These scripts are located in the scripts/migrate subdirectory of estest. You only need to run the migrate-exist-2.0.sh main script with the backup ZIP file generated from the current eXist-db server. This script will produce a new ZIP file with the suffix -me2.zip that can be restored to the new eXist-db 2.0 database.
$ scripts/migrate/migrate_exist-2.0.sh backup.zip $ ls backup.zip backup-me2.zip
When running the migrate_exist-2.0.sh, the current eXist-db server should still be running. You will be asked to give the URL to the eXist-db XML-RPC server as well as your administrator password. If you are running the migrate script from the server itself, then the XML-RPC URL (by default) is
Once you have produced the backup -me2.zip file, this can be used with the restore function in the eXist-db 2.x client.sh tool. The re-installation of ESTEST can continue as normal once the backup is restored, in estest
$ make install $ make xrest # see below
You will need to re-index the collection after the restore.
- eXist-db 2.0 does not support soft links to XQuery scripts in /webapp where previously we installed the /webapp/estest XQuery scripts. Two solutions for this problem. You can replace the soft links with the script files themselves. Alternatively (and recommended) the XQuery scripts can be executed directly from the REST servlet in eXist-db by installing the script directly to the database. This operation is encapsulated in the GMake command
$ make xrest
For the ESTEST server to use the REST servlet paths you must also change the Apache configuration for these aliases
ProxyRequests Off <Proxy *> Order deny,allow Allow from all </Proxy> ProxyPass /exist http://localhost:8080/exist/rest/db ProxyPassReverse /exist http://localhost:8080/exist/rest/db Redirect /estest-plugins /exist/estest/plugins
- eXist-db 2.0 has overhauled document permissions to be inline with those of *NIX operating systems. Instead of the older read, write, update rwu permissions, the 2.0 distribution uses the permissions read, write, execute. Basically this means that the update permission has been absorbed into the write permission and an execute permission has been added in its place. The execute permission is important to add to collections (directories) to allow access to them as well as to XQuery scripts to allow their execution. Most collections in eXist-db created by ESTEST will take into account which version of eXist-db is being used and set permissions accordingly.
- Changes to the XML-RPC API. The XML-RPC servlet in eXist-db 2.0 does not support the function call getUsers(). Also the 2.0 servlet implements the functions getVersion(), addGroup(string), and removeGroup(string). A test for which version of eXist-db is running with XML-RPC and Python is captured by the following code snippet. The parameter localeXist is the server proxy returned by calling the xmlrpclib library.
def getVersion(localeXist): version = "1." try: v=localeXist.getVersion() if v[0:2]=="2.": version="2." except: pass return version