Miscellaneous changes in 10.15.0 affecting backwards compatibility
The following changes in Apama 10.15.0 affect backwards compatibility to previous Apama versions:
The
GenericRequest event in the
com.apama.cumulocity package has been changed to improve consistency in error handling. In all cases of a response from the server, a
GenericResponseComplete event is now sent to the correct response channel. In addition, the
GenericResponseComplete event now has the following additional members:
boolean error - Set to
true if the
GenericRequest received either an error content type or a non-2xx HTTP return code.
integer status - The HTTP return code.
string details - Details of the response which were not sent as a
GenericResponse.
It is recommended that you now use the updated GenericResponseComplete event instead of the Error event since the GenericResponseComplete event is sent to the same channel as the GenericResponse event.
In addition, there is a change in behavior where previously some
GenericRequest events which received non-2xx response codes were still sending
GenericResponse events. As of this version, only requests where
error is
false and the payload is JSON will send
GenericResponse events. For more details, see the
com.apama.cumulocity package in the
API Reference for EPL (ApamaDoc) .
In previous versions, no response events were sent at all in some cases. As of this version, the GenericResponseComplete event is always sent for all GenericRequest events in any error case.
As of Cumulocity IoT release 10.14, sending email requests from Apama to Cumulocity IoT requires the user to have the
ROLE_EMAIL_CREATE permission. This means that the user name that is used in Software AG Designer projects and any Apama applications connecting externally to the Cumulocity IoT platform must have this permission.
There is a change in behavior for the Cumulocity IoT transport. Previously, when a project was run with an incorrectly configured Cumulocity IoT bundle, the correlator failed to start. Now, the correlator keeps running and an error is logged indicating that it failed to create a Cumulocity IoT notification chain instance.
The Apama C++ samples and libraries have been updated to be compatible with the latest C++ standard, which is C++20. Therefore, you must now update any projects that are compiling against those libraries so that they use the following flags (or the equivalent for your compiler):
For Visual Studio 2019:
/std:c++latestFor G++ 8.5.0:
-std=c++2aFor Clang 12:
-std=c++20This release of Apama withdraws support for using a Java 8 runtime with the Apama APIs. You must now use at least Java 11 to run Java applications using the Apama Java APIs.
Note:
Support for Java 8 was already removed in Apama 10.11.0. It was possible, however, to still use it in some situations. See also
Java upgrade in 10.11.0.
To fix a security vulnerability, the Kafka client library which is used by the Kafka transport has been upgraded from version 2.5.0 to version 2.8.1. Connecting to Kafka brokers older than 2.8.1 is no longer supported.
The classpath for the Kafka transport is now configured in a different way to allow future customization. It now also points to
${APAMA_HOME}/lib/kafka-clients.jar. See also
Loading the Kafka transport.
Adding the Kafka bundle to your project gives you your own copy of the configuration. If you have already added the Kafka bundle to your project, you must edit the Kafka.yaml file in your project to use the new configuration. That is, you have to change the following line:
classpath: ${APAMA_HOME}/lib/connectivity-kafka.jar
to this:
classpath: ${APAMA_HOME}/lib/kafka-clients.jar;${APAMA_HOME}/lib/connectivity-kafka.jar
Java libraries such as Log4J, SLF4J, Jackson and Spring that used to be distributed under
APAMA_HOME/../common/lib/ext have been moved to the
APAMA_HOME/lib directory. You may need to update build scripts if you are using these jars from the installation to build custom plug-ins.
In previous versions, chain names could contain newline characters, thus causing newlines in the correlator log file. For security reasons, this is no longer allowed. If a newline character is detected in a chain name, an exception is now thrown.
There may also be removed features that affect backwards compatibility. See
Removed and deprecated features in 10.15.0 for more information.