Sitemap

# Release Notes

## tl;dr

CI? You should have it.

The complete setup to test anything against one or more versions of eXistDB on TravisCI with caching enabled

## Preface

I was recently working on node-exist. It is a node package, that consumes eXist's RPC API. In order to run the tests the database needed to be up.

Mocking of the database responses could have solved that problem, but…

Now you got 2 problems

1. how to test against another version or multiple ones
2. validating mock responses (of multiple versions)

A much better solution is for the tests to run on a continous integration platform. Here, every commit can be tested against different versions of the database in parallel. And, there is no need to have them runnning on the development machine. Plus, everyone with access can verify if a certain build is running and which database versions are supported by your application.

There are more arguments pro continuous integration, which you can easily find online.

TravisCI seemed to be a reasonable choice, not only because eXistDB itself runs its automated tests here.

## Which version to test against?

As travis automatically starts one build per entry in env your tests will be run against the 3.0.RC1 and the 2.2 release of eXist with

```yaml env: - EXISTDBVERSION=eXist-3.0.RC1 - EXISTDBVERSION=eXist-2.2 ```

Add or remove versions as you need them.

## before install

It proved to be handy to store the installation folder of the current DB version in an environment variable `EXISTDBFOLDER`. It will be used by following scripts and commands.

```yaml before install: - export EXISTDBFOLDER=$HOME/exist/${EXISTDBVERSION} ```

## installation and setup

To install the database we download the source from github, extract it and then call its build routine.

```sh export TARBALLURL=https://github.com/eXist-db/exist/archive/${EXISTDB_VERSION}.tar.gz

All of the above can be nicely packed into a setup script.

`yaml install: - ci/setup-db.sh `

Note: `EXISTDBVERSION` is the environment variable we defined at the very beginning. This can be a tag or branchname or even a commit hash.

## Can't we start already?

Yes, but in order to do that we have to start eXist in the background and wait for it to listen to requests. Last, ensure that by doing a very simple one.

```sh cd ${EXISTDBFOLDER} nohup bin/startup.sh & sleep 30 curl http://127.0.0.1:8080/exist ```

Yes, you guessed it. There is a database start-up script.

`yaml before_script: - ci/start-db.sh `

Note: Without changing to its installation folder a bunch of exceptions will end up in nohup.out complaining about log files that cannot be found and opened.

## That's it

Run your tests!

```yaml script: - do test / ```

Now it is time to clean up the closet:

```yaml afterscript: - cd ${EXISTDB_FOLDER} - bin/shutdown.sh ```

## Tweaks

## What if Java is not you first language?

If you are not testing a java-application, as I was, you need to install java 1.8 into to the testing container with:

`yaml addons: apt: packages: - oracle-java8-installer `

and make this version the default by adding

`yaml - export JAVA_HOME=/usr/lib/jvm/java-8-oracle `

to the before_install step.

## The Gist of the Story

(Integration) testing is necessary, so if you're application depends on eXistDB then you should definitely have a look at this project.

examples on GitHub

results on Travis

# XML Prague 2016

This year the XML Prague conference is taking place from 11th to 13th of February.

Topics will be:

• Markup and the Extensible Web
• Semantic visions and the reality
• Publishing for the 21st century
• XML databases and Big Data
• State of the XML Union

As each year members of the community and other interested parties are invited to join the 'eXist-db Unlike Preconference' to share and exchange knowledge around eXistdb.

## Mission Critical Bug Fixes

There have been numerous bug fixes and enhancements since eXist 2.2, the most critical are:

• Patched a memory leak in the Java service wrapper that occurred on certain Linux systems
• Solved a potential deadlock which manifested when storing XQuery files into the database under certain conditions
• Fixed a memory leak when storing query results into the HTTP session; Web applications making use of the HTTP session should now consume less memory and scale further
• Fixed an occasional deadlock when shutting down the database
• Fixes to match highlighting with the Lucene full text index
• Lucene range index now correctly handles != comparisons