Using Custom WebLogic JSP Tags (cache, process, repeat)

The following sections describe the use of three custom JSP tags - cache, repeat, and process - provided with the WebLogic Server distribution:

 

Overview of WebLogic Custom JSP Tags

BEA provides three specialized JSP tags that you can use in your JSP pages: cache, repeat, and process. These tags are packaged in a tag library jar file called weblogic-tags.jar. This jar file contains classes for the tags and a tag library descriptor (TLD). To use these tags, you copy this jar file to the Web Application that contains your JSPs and reference the tag library in your JSP.

 

Using the WebLogic Custom Tags in a Web Application

Using the WebLogic custom tags requires that you include them within a Web Application. For more information on Web Applications, see Assembling and Configuring Web Applications.

To use these tags in your JSP:

  1. Copy the weblogic-tags.jar file from the ext directory of your WebLogic Server installation to the WEB-INF/lib directory of the Web application containing the JSPs that will use the WebLogic Custom Tags.
  2. Reference this tag library descriptor in the <taglib> element of the Web Application deployment descriptor, web.xml. For example: 
    <taglib>



      <taglib-uri>weblogic-tags.tld</taglib-uri>



      <taglib-location>



         /WEB-INF/lib/weblogic-tags.jar



      </taglib-location>



    </taglib>

    For more information, see Writing Web Application Deployment Descriptors.

  3. Reference the tag library in your JSP with the taglib directive. For example: 
    <%@ taglib uri="weblogic-tags.tld" prefix="wl" %>

 

Cache Tag

The cache tag enables caching the work that is done within the body of the tag. It supports both output (transform) data and input (calculated) data. Output caching refers to the content generated by the code within the tag. Input caching refers to the values to which variables are set by the code within the tag. Output caching is useful when the final form of the content is the important thing to cache. Input caching is important when the view of the data can vary independently of the data calculated within the tag.

If one client is already recalculating the contents of a cache and another client requests the same content it does not wait for the completion of the recalculation, instead it shows whatever information is already in the cache. This is to make sure that the web site does not come to a halt for all your users because a cache is being recalculated. Additionally, the async attribute means that no one, not even the user that initiates the cache recalculation waits.

Two versions of the cache tag are available. Version 2 has additional scopes available.

Caches are stored using soft references to prevent the caching system from using too much system memory. Unfortunately, due to incompatibilities with the HotSpot VM and the Classic VM, soft references are not used when WebLogic Server is running within the HotSpot VM.

 

Refreshing a Cache

You can force the refresh of a cache by setting the _cache_refresh object to true in the scope that you want affected. For example, to refresh a cache at session scope, specify the following: 

<% request.setAttribute("_cache_refresh", "true"); %>

If you want all caches to be refreshed, set the cache to the application scope. If you want all the caches for a user to be refreshed, set it in the session scope. If you want all the caches in the current request to be refreshed, set the _cache_refresh object either as a parameter or in the request.

The <wl:cache> tag specifies content that must be updated each time it is displayed. The statements between the <wl:cache> and </wl:cache> tags are only executed if the cache has expired or if any of the values of the key attributes (see the Cache Tag Attributes table) have changed.

 

Flushing a Cache

Flushing a cache forces the cached values to be erased; the next time the cache is accessed, the values are recalculated. To flush a cache, set its flush attribute to true. The cache must be named using the name attribute. If the cache has the size attribute set, all values are flushed. If the cache sets the key attribute but not the size attribute, you can flush a specific cache by specifying its key along with any other attributes required to uniquely identify the cache (such as scope or vars).

For example:

  1. Define the cache. 
    <wl:cache name="dbtable" key="parameter.tablename"



    scope="application">



    // read the table and output it to the page



    </wl:cache>
  2. Update the cached table data.
  3. Flush the cache using the flush attribute in an empty tag (an empty tag ends with / and does not use a closing tag). For example 
    <wl:cache name="dbtable" key="parameter.tablename" scope="application" flush="true"/>

    Attribute

    Required

    Default Value

    Description

    timeout no -1 Cache timeout property. The amount of time, in seconds, after which the statements within the cache tag are refreshed. This is not proactive; the value is refreshed only if it is requested. If you prefer to use a unit of time other than seconds, you can specify an alternate unit by postfixing the value with desired unit:ms = milliseconds
    s = seconds (default)
    m = minutes
    h = hours
    d = days
    scope no application Specifies the scope in which the data is cached. Valid scopes include:

    • parameter, (versions 1,2)requests the HTTP servlet request parameters

    • page, (versions 1,2)requests the JSP page context attributes (This scope does not exist for the cache filter.)

    • request, (versions 1,2)requests the servlet request attributes. Request attributes are valid for the entire request, including any forwarded or included pages.

    • cookie, (version 2)requests the cookie values found in the request. If there are multiple cookies with the same name, this request returns only the first value.

    • requestHeader, (version 2)requests the values from the request Headers. If there are multiple Headers with the same name, only the value of the first is returned.
    scope (cont.)

    • responseHeader, (version 2)requests the values from the response Headers. If there are multiple Headers with the same name, only the value of the first is returned. If you set a response header, all response headers are replaced with the value you have set. This scope should not be used for storing content.

    • session, (versions 1,2)requests the values from the session attributes of the current user. If there is no session then one will not be created by accessing the scope. The caches can become very large if you are caching content.

    • application, (versions 1,2)requests the values found in the servlet context attributes.