Just a second...

Upgrading from version 5.8 to version 5.9

Consider the following information when upgrading from Diffusion™ version 5.8 to version 5.9.

Upgrading your applications

Server-side components

Recompile all Java™ application components that are deployed to the Diffusion server, such as publishers and authorization handlers, against the new version diffusion.jar file. This file is located in the lib directory of your new Diffusion server installation.

Some features that your Java application components might use have been removed or deprecated. Pay attention to new deprecation warnings and compilation failures that occur during recompilation and review the API changes information in the following section to see if these changes affect your applications.

Clients

You can choose not to recompile your client applications and continue to use client libraries from a previous release. If you choose to use client libraries from a previous release, ensure that the libraries are compatible with the new server. For more information, see Interoperability.

You can choose to upgrade your client applications to use the new client libraries. To do this, recompile the client applications against the client libraries located in the clients directory of your new Diffusion server installation and repackage your client application with the new library.

Alternatively, the Java library is available in the Push Public Maven Repository and the JavaScript® library from NPM.

Some features that your client applications might use have been removed or deprecated. Review the API changes information in the following section to see if these changes affect your applications.

The Classic API has been deprecated at this release and will be removed in a future release. Consider rewriting all Classic API clients using the Unified API.

API changes

Further information about removed or deprecated features is available in following locations:
The following table lists API classes and methods that have been removed. If you attempt to recompile application code that uses these classes or methods against the version 5.9 APIs, it fails. Rewrite your application code to not include these features.
Table 1. API features removed in version 5.9
API affected Removed feature Suggested alternative
All APIs Delegated topics and all related classes and methods, including state providers.  
Java Unified API Topics.getStreamsForTopic None
Java Unified API Headers None
.NET Unified API Topics.GetStreamsForTopic None
The following table lists API classes and methods that have been deprecated. If your application code uses these classes or methods, consider rewriting your application code to not include these features.
Table 2. API features deprecated in version 5.9
API affected Deprecated feature Suggested alternative
Classic API Every Classic client API. The Java Publisher API is not deprecated. Use the Unified API instead
Java Unified API In TopicControl: removeTopics, RemoveCallback, and RemoveContextCallback remove, RemovalCallback, and RemovalContextCallback

These changes correspond to a change in behavior that allows topics to be
deleted without also deleting their child topics in the topic tree.

Apple® Unified API PTDiffusionSessionErrorHandler and PTDiffusionSessionDefaultErrorHandler  
.NET Unified API All session details methods in IClientControl Use session properties instead.
Authorisation handler API canSubscribe() Use declarative role-based security instead.
The following list includes behavior that has changed in the API. If your application code relies on the previous behavior, rewrite your application code to take into account the new behavior.
  • There are additional reasons why client sessions can become unsubscribed from a topic:

    AUTHORIZATION. A client session is unsubscribed from a topic with this reason when the session principal changes and the roles assigned to that session no longer contain permissions for that topic.

    SUBSCRIPTION_REFRESH. A client session is unsubscribed from a topic with this reason when the topic type or attributes have changed. For example, if the session connection fails over to another Diffusion server.

  • When creating a topic at a multi-part topic path, for example A/B/C, the intermediate paths, A and A/B, remain empty and topics can be created at these paths at a later point.

    In previous releases, stateless topics were created at these intermediate paths. If your application relies on these stateless topics being present, you must now explicitly create them.

Upgrading your server installation

Note:

At release 5.9, the Diffusion server is tested and supported on Java HotSpot™ Development Kit 8 (latest update).

Java 7 is not supported.

To upgrade your Diffusion server installation, complete the following steps:
  1. Use the graphical or headless installer to install the new version of Diffusion.

    For more information, see Installing the Diffusion server.

  2. You can copy your existing license file from your previous installation to the etc directory of your new installation.
  3. You can copy most of your existing configuration files from the etc directory of your previous installation to the etc directory of your new installation. When you do, consider making the following changes:
    • In Connectors.xml the default value has changed from classic to all. If you did not specify an api-type element and relied upon the default behavior, you must now specify a value of classic to restrict Unified API connections through a connector.
    • In the Management.xml file, consider removing the users and assigned-roles elements, which are now deprecated. Instead use roles and permissions defined in the Security.store.

Behavior changes at the Diffusion server

The following list includes behavior that has changed at the server. If your solution relies on the previous behavior, adjust your solution to take into account the new behavior.
  • By default, connectors now accept connections from both Classic API clients and Unified API clients. Previously the default was to only accept connections from Classic API clients. If you relied upon this behavior to restrict connections from Unified API client, you must now explicitly define an api-type element with a value classic.