By default the viewid concatenated to the component id via an underscore is used as the cache key.
Note that this component does not support a cache loader and locking mechanism. This mean several simultaenous page requests may render the same content and it's undetermined which of those will end up being cached.
An optional caching provider (see below) can be set to control the caching implementation that is used for the actual caching. If no such provider is installed, a default caching implementation is used that's based on http://code.google.com/p/concurrentlinkedhashmap in case a maximum cache capacity is set, or on a plain ConcurrentMap if no capacity is set.
A custom caching provider can be set by using the
parameter in web.xml to point to an implementation of
<context-param> <param-name>org.omnifaces.CACHE_PROVIDER</param-name> <param-value>com.example.MyProvider</param-value> </context-param>
The default provider,
org.omnifaces.component.output.cache.DefaultCacheProvider can be used as an
For the default provider, the maximum capacity and the default time to live can be specified for the
supported scopes "session" and "application". If the maximum capacity is reached, an entry will be
evicted following a least recently used policy. The default time to live specifies for how long
entries are considered to be valid. A value for the
time attribute on this component
will override this global default time to live. The following context parameters can be used in web.xml:
||Sets the maximum number of elements that will be stored per web module (application scope). Default: no limit|
||Sets the maximum number of elements that will be stored per session. Default: no limit|
||Sets the maximum amount of time in seconds that cached content is valid for the application scope. Can be overriden by individal cache components. Default: no limit|
||Sets the maximum amount of time in seconds that cached content is valid for the session scope. Can be overriden by individal cache components. Default: no limit|
||Boolean that when true installs a Servlet Filter (Servlet 3.0+ only) that works in conjunction with the
If no custom caching provider or global settings are used, no specific configuration is needed. Otherwise
org.omnifaces.component.output.cache.CacheInitializerListener needs to be installed as a
listener in web.xml:
<listener> <listener-class>org.omnifaces.component.output.cache.CacheInitializerListener</listener-class> </listener>
In case the alternative caching method via buffering is used,
to be installed as a Servlet Filter in web.xml, filtering either the FacesServlet itself or any page on which the alternative caching
method is required.
(must evaluate to
Optional key used to store content in the cache. If no key is specified, a key is calculated
based on the client Id of this component.
While auto-generated keys can be convenient, note that in the face of dynamic behavior on a view the id of a component and thus the cache key can change in ways that are difficult to predict.
Keys are relative to the scope for which they are defined, meaning a key "foo" for the a session scoped cache will not conflict with a key of the same name for an application scoped cache.
(must evaluate to
Optional scope identifier used to set the scope in which caching takes place. If no scope is specified,
the default scope "session" will be used.
The supported scopes depent on the caching provider that is installed via the
A runtime exception will be thrown if an unsupported value for scope is used.
(must evaluate to
Optional amount of time in seconds for which the cached content is valid (TTL). This is counted
from the moment content is actually added to the cache. If no time is provided the content will be subject
to the global cache settings, and in absence of these are subject to the behavior of the cache implementation
that is used. The default cache implementation will simply cache indefinitely.
Whether the content is actually removed from the cache (to preserve memory) after the given time has elapsed is dependend on the actual cache implementation that is used. The default cache implementation will NOT do this automatically, but will instead remove it only when the cache item is being accessed again.
Following the above, new content will only be inserted into the cache following a page request. A time of e.g.
Note that this component does not support a cache loader and locking mechanism. This means after content times out, several simultaneous page requests may render the same content and it's undetermined which of those will end up being cached.
(must evaluate to
Switches to an alternative method to grab the content generated by the children of this component. Default is
Normally this content is obtained by replacing the so-called response writer when the parent Cache
component delegates rendering to its children. However, in some cases (like
Via this switch, the full response is buffered if the cache doesn't contain content for this component and special markers are inserted surrounding the children's rendering. Afterwards, the content between the markers (if any) is extracted and inserted into the cache. Note that the full response is only buffered incase there's no value the cache. For all other requests this buffering will not happen.
Since this is clearly a more resource intensive and invasive method to grab content, it's not enabled by default.
In addition to setting this attribute to
Output generated by Vdldoc View Declaration Language Documentation Generator.