Differences between revisions 1 and 2
Revision 1 as of 2003-01-30 10:40:42
Size: 6316
Editor: anonymous
Comment: missing edit-log entry for this revision
Revision 2 as of 2003-01-30 10:40:43
Size: 6442
Editor: anonymous
Comment: missing edit-log entry for this revision
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
=== Changes since version 2.0.x === == Changes since version 2.0.x ==
Line 24: Line 24:
=== New caching API for use in XSP (as well as other components) ===
== New caching API for use in XSP (as well as other components) ==
Line 47: Line 48:
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 must continue using the !CacheValidity implementation org.apache.cocoon.caching.!DeltaTimeCacheValidity as there is no equivalent implementation that implements !SourceValidity. For the time being, !CacheValidityToSourceValidity acts as a bridge between the two APIs, enabling the use of older 2.0.x-compatible caching mechanisms in 2.1 and newer. 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.
Line 49: Line 50:
=== Complete Example ===
== Complete Example ==

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>

  • </xsp:structure>

    <xsp:logic>

    </xsp:logic>}}}

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"?>

  • <xsp:page language="java"

    <xsp:structure>

    </xsp:structure>

    <xsp:logic>

    • /**
      • Generate the unique key.
      • This key must be unique inside the space of this XSP page.
      • This method will be invoked before the generateValidity() method.
      • @return The generated key or null if the component
      • is currently not cacheable.
      • /
      public Serializable generateKey() {
      • // Generate unique key; add parameters' values here return "" + request.getParameter("param");
      } /**
      • Generate the validity object.
      • Before this method can be invoked the generateKey() method
      • will be invoked.
      • @return The generated validity object or null if the
      • component is currently not cacheable.
      • /

      public SourceValidity generateValidity() {

      }

    </xsp:logic>

    <page>

    • <title>A Cacheable XSP Page</title> <content>

      • <!-- Two second wait --> <xsp:logic>

        </xsp:logic>

        <para>Hi there! I'm a simple dynamic page generated by XSP

        • (eXtensible Server Pages).</para>

        <para>I'm cached for every different value of request parameter

        • 'param'. Value is: <b> <xsp-request:get-parameter name="param"/>

          • </b></para>

        <para>All other request parameters do not influence cache status, but

        • my validity will expire after 5 sec (see source).

          Value of parameter 'other' is: <b>

          • <xsp-request:get-parameter name="other"/></b>

            • </para>

        <para>Links:

        • <ul> <li><a href="cacheable?param=one">param=one</a></li> <li><a href="cacheable?param=two">param=two</a></li> <li><a href="cacheable?param=three&other=abc">param=three, other=abc</a></li> <li><a href="cacheable?param=three&other=xyz">param=three, other=xyz</a></li> </ul> Try two last links with delay 5 sec; and try without delay.

          • </para>

      </content>

    </page>

    </xsp:page>}}}


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

XSPCachingWithCocoonHEAD (last edited 2009-09-20 23:41:25 by localhost)