Changes since version 2.0.x

In the 2.0.x version of Apache Cocoon, the user would include the following in their cacheable XSP file prior to the output page content (I have removed the comments from the original sample for brevity's sake):

{{{ <xsp:structure>

In version 2.0.x of Apache Cocoon, the samples demonstrate how to implement cacheable XSP files using a combination of HashUtil and the CacheValidity interface.

New caching API for use in XSP (as well as other components)

In 2.1 and above, page authors are no longer required to generate their own hash key as a long value, and CacheValidity has been replaced with the SourceValidity interface. The previous example would be written in version 2.1 and above as the following:

{{{ <xsp:structure>

As you can see, the references to org.apache.cocoon.caching.CacheValidity and org.apache.cocoon.util.HashUtil are no longer required. In addition, you must include org.apache.excalibur.source.SourceValidity, org.apache.cocoon.caching.CacheValidityToSourceValidity, and java.io.Serializable to your list of includes (Java import statements). As of 2002-01-18, users who want to use simple timeout-based cache expiration (as is used in the cacheable XSP example) must continue using org.apache.cocoon.caching.DeltaTimeCacheValidity, an implementation of CacheValidity, as there is no equivalent implementation of the SourceValidity interface. For the time being, CacheValidityToSourceValidity acts as a bridge between the two APIs, enabling the use of older 2.0.x-compatible caching implementations in the newer versions of Apache Cocoon.

Complete Example

As it happens, the existing code has a "problem." For example on a 1GHz Athlon workstation, it's quite likely that, after the initial XSP compilation step, the user will not be able to clearly see a speed difference between an uncached version and a cached version. In an attempt to simulate complexity, a complete example is included with a simple Thread.sleep(long) call. It is identical to Carsten Zielgler's example except for the 2.1 updates and a two second delay. With the delay, it is much easier for the user to recognize when the system is using a cached copy and when it is not. Obviously, for production code, you would not want this artificial delay -- don't forget to remove it.


{{{ <?xml version="1.0" encoding="ISO-8859-1"?>


This should be a drop-in replacement for the existing version of cacheable.xsp in your 2.1 webapp.