1. Supported platforms

The following Linux distributions are supported:

  • Debian 6 (Squeeze) and 7 (Wheezy)

  • Fedora 17, 18

  • Ubuntu 10.04 LTS (Lucid Lynx), 12.04 LTS (Precise Pangolin)

2. Changes in 2.2.2

2.1. Support JSON::XS 3.0

Version 3.0 JSON::XS changed its internal representation of Boolean values. OpenSRF’s JSON utility routines had been dependent on details of that representation used by previous versions of JSON::XS, but that dependency is now gone.

2.2. Protect subrequests from post-complete messages

Subrequests (AKA method_lookup()-based API calls) sometimes append final-lvalue responses to the response list even after respond_complete() has been called from within the implementation method. OpenSRF now discards all post-respond_complete values, protecting against extra, spurious values being returned to the ultimate client.

3. Changes in 2.2.1

3.1. Disable use of multipart/mixed XHR for most clients

Due to Mozilla withdrawing support for multipart XHR responses from Firefox as of version 22, multipart message support is now disabled for all clients except the Evergreen staff client.

3.2. Default per-process client locale (Perl)

A method was added to get and/or set the locale used by all new client sessions for the current process. This is primarily useful for clients that wish to make a series of OpenSRF calls and don’t wish to set the locale for each new AppSession object.

3.3. Minor fixes

One fix improves support for Debian testing while another resolves some unitialized variable warnings.

4. New features in 2.2.0

4.1. Apache 2.4 support

OpenSRF now supports Apache 2.4.

4.2. Support graceful reload of Perl services via SIGHUP

Sending a SIGHUP signal to the listener process of a Perl service will now cause it to re-read the OpenSRF core configuration and respawn its child processes. This allows the log level of the service to be changed on the fly.

4.3. Send Perl warnings to OpenSRF logs

Warning messages generated by warn() and carp() calls in Perl services are now sent to the main OpenSRF log subsystem rather than the *_stderr.log files.

4.4. Enable client logtrace with environment vars

A new environment variable, OSRF_LOG_CLIENT, is now recognized which, if set to true, enables control and generation of the client log trace value. This is the same as setting <client>true</client> within the OpenSRF core configuration file.

As a shortcut, if the MOD_PERL environment variable is set, assume client=true.

This allows clients and non-clients to share an OpenSRF core configuration file, when previously the only difference between the two was the <client> setting.

5. Significant bugfixes in 2.2.0

5.1. Eliminate CPU spikes caused by use of MultiSession

The MultiSession module now blocks on the XMPP socket while waiting for responses from the service requests it fires off rather than using a CPU-intensive loop to poll for responses.

5.2. Fix Java client’s parsing of OpenSRF core configuration

This issue had prevented Java client library from successfully connecting to an OpenSRF network.

6. Build improvements

OpenSRF no longer uses /opensrf as a non-standard default installation directory prefix, easing the task of packagers.

OpenSRF’s Java libraries can now be built without requiring that src/Java/Makefile be edited manually.

OpenSRF no longer incorrectly asserts a dependency on the RPC::XML Perl module.

6.1. Continuous integration support

An example configuration file for the Buildbot continuous integration server can be found in examples/buildbot.cfg. The most current version of this file will always be found in the master branch of the OpenSRF git repository.

The build steps configure and compile the code using the default arguments to configure, as well as running the unit tests for C, Perl, and Python, and running pylint against the Python source code.