Fork me on GitHub

Upgrading from Previous Releases

Upgrading from Coherence Incubator 10 and 11

While Coherence Incubator 12 is considered a major release, most developers should find that upgrading from Coherence Incubator 10 or 11 should be as simple as replacing the previous jars.

In terms of branches, Coherence Incubator 12 was branched from Coherence Incubator 11.1.0 which means all of the latest and applicable fixes in Coherence Incubator 11.1.0+ are also in Coherence Incubator 12.

There of course will be exceptions, especially for those developers that have customized internal implementation classes (as these may have changed, been refactored or removed), but for the most part challenges like this should be very isolated. We've tried hard to ensure we didn't remove important interfaces, especially those that aren't provided by Coherence.

If you're using Maven, all you should do is update the appropriate artifact version from the maven.java.net repository.

<dependency>
    <groupId>com.oracle.oracle.incubator<groupId>
    <artifactId>Coherence Incubator Site<artifactId>
    <version>12.0.0</version>
</dependency>

Where the Coherence Incubator Site is one of: coherence-common, coherence-commandpattern, coherence-functorpattern, coherence-messagingpattern, coherence-eventdistributionpattern, or coherence-pushreplicationpattern.

Fundamentally there are two major areas of change:

  1. This release extensively leverages the new configuration models provided by Coherence 12.1.2 (as part of the com.tangosol.config and com.tangosol.coherence.config packages) instead of the previous configuration models provided by the Coherence Common module (as part of the com.oracle.coherence.common.configuration and com.oracle.coherence.common.environment packages). The previous packages have now been removed as all future configuration infrastructure will be based on that which is provided by Coherence.

    Developers that are familiar with the previous approaches will find these features now available in Coherence itself (in some manner). Migrating to use the Coherence provided infrastructure should not be too difficult (as the method signatures are almost identical).

    Developers that aren't familiar with this should have nothing to worry about - if you don't know about it, then it should not affect you.

    Importantly all of the patterns that made use of the previous technology have been refactored to use the new approach provided by Coherence 12.1.2. If you're using the previous patterns that leveraged namespaces, there should be little or no change as we refactored those implementations to use Coherence 12.1.2. We've even kept the class names the same so configuration files should not need to change.

  2. This release extensively leverages the new Live Events framework provided by Coherence 12.1.2 instead of the previously provided BackingMapListener-based framework. The previous packages supporting this, namely com.oracle.coherence.common.events and com.oracle.coherence.common.backingmaplisteners have now been removed. All future use of server-side event technology will be based on Live Events.

    Importantly all patterns that made use of BackingMapListener features have now been refactored to use Live Events. This has dramatically simplified the implementations, including many of the threading models previously implemented in earlier releases of the Coherence Incubator.

The change history for Coherence Incubator 12 can be found here.

Upgrading from pre-Coherence Incubator 10 Releases

Migrating from releases prior to Oracle Coherence Incubator 10 requires more effort. In most cases the changes will require refactoring previous configurations to use newer styles and technologies. Some patterns, like Push Replication, may require more effort than others, however once migrated to this release, moving forward will be much easier.