Let’s you configure a CacheManager
at creation time, using a XML file, according to
this schema definition, namely:
The root element of our XML configuration. One <config>
element, and as such one XML file, corresponds to
a CacheManager
. From Ehcache’s perspective though, nothing prohibits from creating multiple CacheManager
instances
off one XML configuration file. Ehcache does not act as a repository of CacheManager
, unlike JSR-107’s
javax.cache.spi.CachingProvider
.
Currently, no built-in services are provided. But <service>
elements are, and will remain, an extension point for
CacheManager
lifecycled services, i.e. Service
instances that will be .start()
and .stop()
'ed by the
CacheManager
during its own lifecycle state transitions.
These Service
instances can then be used by Cache
instances managed by the CacheManager
. JSR-107 uses this
extension point of the XML configuration (and Ehcache 3’s modular architecture), as explained in the
JSR-107 configuration section.
<cache>
elements each represent a Cache
that will be created, and then on managed, by the CacheManager
.
Each <cache>
requires the alias
attribute, used at runtime to retrieve the corresponding Cache<K, V>
instance using
the org.ehcache.CacheManager.getCache(String, Class<K>, Class<V>)
method. The optional usesTemplate
attribute, let’s you reference
a <cache-template>
element’s name
attribute. See the cache-template section
for further details on using them.
Supported nested elements are optional:
-
<key-type>
: the fully qualified class name (FQCN) of the keys (<K>
) held in theCache<K, V>
, defaults tojava.lang.Object
-
<value-type>
: FQCN of the values (<V>
) held in theCache
, defaults tojava.lang.Object
-
<capacity>
: a positive numerical value, defaults tonull
, i.e. unconstrained -
<expiry>
: lets you control the expiry type and its parameters -
<eviction-veto>
: FQCN of aorg.ehcache.config.EvictionVeto<K, V>
implementation, defaults tonull
, i.e. none -
<integration>
: lets you configure aCacheLoaderWriter
for a cache-through pattern
<cache-template>
elements represent a uniquely named (specified using the mandatory name
attribute) template for
<cache>
elements to inherit from. A <cache-template>
. A <cache>
element that references a <cache-template>
by
its name
using the usesTemplate
attribute, will inherit all of the <cache-template>
's properties. Every <cache>
can override these properties as it needs.
A <cache-template>
element may contain all the same child elements as a <cache>
element.
Note
|
We’ve setup a complete configuration example for you to inspire from. |
Note
|
If you are obtaining your CacheManager through the JSR-107 API, what follows below is automatically done for you
when invoking javax.cache.spi.CachingProvider.getCacheManager(java.net.URI, java.lang.ClassLoader) , so you
probably don’t have to worry about any of this…
|
final URL myUrl = this.getClass().getResource("/my-config.xml"); // (1)
XmlConfiguration xmlConfig = new XmlConfiguration(myUrl); // (2)
CacheManager myCacheManager = CacheManagerBuilder.newCacheManager(xmlConfig); // (3)
-
Obtain a
URL
to your XML file’s location -
Instantiate a
XmlConfiguration
passing the XML file’s URL to it -
Using the static
org.ehcache.CacheManagerBuilder.newCacheManager(org.ehcache.config.Configuration)
lets you create yourCacheManager
instance using theConfiguration
from theXmlConfiguration
We can also use <cache-template>
declared in the XML file to seed instances of CacheConfigurationBuilder
. In order
to use a <cache-template>
element from a XML file, e.g. the /my-config.xml
contained this XML fragment:
<ehcache:cache-template name="example">
<ehcache:capacity>120</ehcache:capacity>
</ehcache:cache-template>
Creating a CacheConfigurationBuilder
of that example
<cache-template>
element, would be done so:
CacheConfigurationBuilder<String, Object> cacheBuilder = xmlConfig.newCacheConfigurationBuilderFromTemplate("example", String.class, Object.class); // (1)
cacheBuilder.capacityConstraint(100L); // (2)
-
Creates a builder, inheriting the capacity constraint of 120 entries, specializing the key type to
java.lang.String
-
But you can obviously override the inherited properties, by simply providing a different value prior to building the
CacheConfiguration