This documentation applies to the Coherence Common 1.4.0. The latest Coherence Common documentation is available here.

What's New?

The following changes have been made since Coherence Common 1.3.0.

• Introduced a FilteringIterator. This is useful for lazily filtering elements from standard Java Iterators with Coherence Filters.

• Introduced the com.oracle.coherence.common.sequencegenerators package to support the generation of cluster-wide unique identifiers (longs).

• Introduced namespaces for caches. All cache names used in this project are prefixed with coherence.common.

From now on all cache names used by the Incubator patterns have a coherence.<project-name>.* prefixed to ensure uniqueness and avoid cache names clashing with end-user defined application cache names.

• Hardened the implementation of classes implementing the Range interface.

• Introduced automated testing (with TestNG) into the build.xml

The AdvancedConfigurableCacheFactory

The com.oracle.coherence.common.configuration.AdvancedConfigurableCacheFactory is a drop in replacement for the standard DefaultConfigurableCacheFactory that Coherence uses to load and process cache-config.xml files.

While it's completely backwards compatible with the standard DefaultConfigurableCacheFactory, it also adds some advanced functionality to the loading and processing of cache-config.xml, like the ability to introduce and override other cache-config.xml files.

If you've ever wanted to break-up a large cache-config.xml file into separate files, say for different parts or components of an application, the AdvancedConfigurableCacheFactory is your solution.

For Example;

<cache-config>
    <introduce-cache-config file="some-other-config-file-a.xml" />
    <introduce-cache-config file="some-other-config-file-b.xml" />
</cache-config>

Order of <introduce-cache-config... /> declaration is important! Care must be taken when introducing cache config files as each introduction will override and replace any equivalently named (or identifiable) xml elements from previously introduced cache config files (in the order in which they are declared and processed).

In the example above, named elements in the "some-other-config-file-b.xml" will override any xml elements with the same name (or identities) that where introduced in "some-other-config-file-a.xml". Additionally, the outer-level config file "my-cache-config.xml" may also override any or all of the "introduced" named elements declared in the "some-other-config-file-a.xml" and "some-other-config-file-b.xml" files.

Nested (recursive) Introductions Nesting introductions are also supported. Thus it is possible to define a cache config file that introduces another cache config, that in turn introduces another cache config and so on. Additionally, graphs of introductions are also supported. That is, the following introductions are valid; A introduces B and C. B introduces D. C introduces D. D introduces E.

Frequently Asked Questions

Why isn't it called <include ... />? like it is in POF configuration files?

The <include ... /> element, as commonly used in POF configuration files, is a textual include (similar to #include in C or C++). The semantics of <introduce-cache-config ... /> are closer to that of <scheme-ref .../> but work on an entire file basis. The <introduce-cache-config ... /> is like "inheritance" but allows further overriding of "inherited" xml elements.