Coherence: using a custom operational override file with “system-property” command line overrides

The situation I am going to describe might be obvious to some people, but apparently it wasn’t to me. I was diagnosing a problem where the tangosol.coherence.clusterport system property specified on the command line (with the -D flag) was being ignored by my coherence-enabled code. The code was not overwriting the system property, however it was specifying values for other system properties that override Coherence settings, among them, it was specifying an override file by setting the tangosol.coherence.override property. Here’s an analysis of the problem:

If you write your own Coherence “operational override” file (specified with the tangosol.coherence.override property), you must re-iterate the system-property attribute on each element whose default you wish to maintain.

For example, in tangosol-coherence.xml, the clusterport command line override is specified in the port tag with: . If you were to override in your custom override file, you must include the system-property if you want to keep using it. In other words, the “preconfigured overrides” they mention throughout the documentation (especially here) are only guaranteed to be present if you use the default configuration files. Otherwise it is up to you.

This makes sense if you look at the provided override files, for example tangosol-coherence-override-dev.xml. In the time-to-live element, for example, it re-iterates the system-property setting that is also present in tangosol-coherence.xml. Unfortunately, I did not notice this, and instead assumed that I did not have to re-iterate the “preconfigured override”. I like this ability to remove the command line override functionality on specific elements. It allows us to make some of our configurations a bit more rock solid so that command line parameters cannot mess it up.