Coherence Common

The Coherence Common project provides a collection of classes that are commonly used to support the implementation of other Incubator projects.

Contained classes and packages include; an AdvancedConfigurableCacheFactory, several Backing Map Listener implementations, useful classes for creating different types of Identifiers, handling Tickets, Ranges, Tuples, Leases and some customized Thread Factories. Also included are methods for generating cluster-safe sequences of unique longs.

Dependencies

This project (like other Coherence Incubator projects) uses Apache Ivy for dependency specification and management. While a standard ivy.xml definition file ships with the source and documentation distribution, the following diagram visually indicates the current dependencies.

Outline

Release Name:	Version 1.5.0: October 28th, 2009
Target Platforms:	Java Standard Edition 5+
Requires Coherence Version:	3.3.1+, 3.4+ or 3.5.2+
Dependencies:	(none)
Download:	coherence-common-1.5.0.jar MD5:d352d95e917eabb8fbddd9e2caa178ea
Source and Documentation:	coherence-common-1.5.0-src.zip MD5:628ea6d2ee8d7742abd07bff0d6acffc
Previous Releases:	Coherence Common 1.4.0 Coherence Common 1.3.0 Coherence Common 1.2.0 Coherence Common 1.1.1

What's New?

The following changes have been made since Coherence Common 1.4.0.

Introduced Tristate class. This is useful for representing TRUE, FALSE and UNDEFINED values.

Now dependent on Coherence 3.5.2+ for the Coherence 3.5 Editions.

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;

my-cache-config.xml

<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.

Labels