cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <>
Subject Re: Contribution: session tracking for Cocoon 2
Date Wed, 21 Feb 2001 12:19:46 GMT

Checked in your code and samples. 

1. Can you please make sure that everything is checked in and works as intended? 
2. Can you please modify your doc to reflect the current CVS. Basically get rid of the steps
modifying the session.xsl and the java code. Then i can add it to the docs.

If you have any updates/changes. **Please** submit cvs diff's


--- Jörg Prante <> wrote:
> After using Cocoon 2 since October last year and reading the Cocoon-devel
> list since January, I like to give something back.
> I have added URI-based session tracking to Cocoon 2. This will be used in one
> of our commercial tools that will use a modified Cocoon 2. I'm sure that
> session tracking will convince many companies of using Cocoon 2 because it is
> a useful feature.
> Please apologize if I'm wrong but I couldn't find information on the project
> site about plans if and how Cocoon 2 will support session tracking.
> I allowed myself getting bold and wrote an XML Stylebook document for the
> Cocoon 'xdocs' directory which explains all the changes I did to the latest
> CVS. It includes all the code fragments I have added, plus a short
> introduction for people who are not familiar with session tracking. I hope
> this document can be useful for the Cocoon 2 documentation if you decide to
> receive my contribution.
> Please excuse me that I am not sending diff's because this will not explain
> things I've done. The CVS is moving so fast that this does not make much
> sense.
> I'd like to contribute more features to Cocoon 2 and other Apache projects -
> e.g. log analysis of tracked sessions - if you agree with the proposed
> solution, so please give me some feedback.
> Please see the attached sessions.xml for all the details.
> Jörg
> --
> Jörg Prante
> Sevenval AG (HRB 32757) e-business marketing technologies
> D-50667 Köln . Alter Markt 36-42
> Fon +49 221 65007-0 . Fax 4249891
> .
> > <?xml version="1.0" encoding="iso-8859-1"?>
> <!DOCTYPE document SYSTEM "dtd/document-v10.dtd">
> <document>
>   <header>
>     <title>Session tracking with Cocoon</title>
>     <subtitle>Introduction, Installation and Example</subtitle>
>     <version>0.1</version>
>     <type>Technical Document</type>
>     <authors>
>       <person name="Jörg Prante" email=""/>
>     </authors>
>     <abstract>
>     This document explains what Cocoon 2 provides to support session tracking.
>     Session tracking is an important feature for web server frameworks
>     because HTTP and related protocols are stateless,
>     but sometimes we need stateful information about visitors of a Cocoon site.
>     For a more precise analysis of a web site, the tracking of visitors
>     should work independant of the visitor's browser and of the visitor's decision
>     whether we enabled cookies or not. Last not least, Cocoon 2 should not
>     be dependant of the method the servlet engine prefers to generate session IDs.
>     In this document, it is described step by step what has to be done to enable
>     Cocoon 2 for session management.
>     </abstract>
>   </header>
>   <body>
>     <s1 title="Introduction">
>       <s2 title="Goal">
>         <p>
>          Maintaining state is a common problem for web server frameworks
>          because HTTP is a stateless protocol. There are many solutions known
>          to obtain stateful information. Client-side storage of state information
>          like the usage of cookies will not be discussed here, since this depends
>          heavily on the client's browser. Since Cocoon is a server-side framework,
>          storing visitor information at the server side will give full access
>          to the list of all visitors, to what they have done, and what they are
>          doing.
>          </p>
>          <p>Please always think a little while if you really want to set up
>          session management. Less scalability and performance is the dark
>          side of keeping user sessions at the server-side. Each user session consumes
>          memory, disk, and CPU, and it is always recommended that you be careful to
>          system resources before wasting it.
>          </p>
>          <p>
>          If you decided to set up session tracking, Cocoon 2 offers you:
>          </p>
>           <ul>
>             <li>creation of new session IDs</li>
>             <li>full session control by the underlying Servlet API 2.2 servlet
>             <li>cookie- and URI-based session managment</li>
>             <li>automatic link rewrite if you like your XSP pages to be URI-session-aware</li>
>           </ul>
>          </s2>
>       </s1>
>       <s1 title="Installation">
>         <s2 title="Install built-in logicsheet session.xsl">
>           <p>
>           Check if you have the built-in <code>session.xsl</code> logicsheet
installed in your
>           Cocoon framework. <code>cocoon.xconf</code> is the file that defines
>           logicsheets and other <link href="avalon.html">Avalon</link> Components.
>           The following must be present in <code>${cocoon}/cocoon.xconf</code>:
>           </p>
> <source><![CDATA[
> <builtin-logicsheet>
>   <parameter name="prefix" value="session"/>
>   <parameter name="uri" value=""/>
>   <parameter name="href"
> value="resource://org/apache/cocoon/components/language/markup/xsp/java/session.xsl"/>
> </builtin-logicsheet>
> ]]></source>
>          </s2>
>         <s2 title="Set up the session:encode-url template">
>         <p>
>         To enable Cocoon for URI-based session IDs, an XSP template with the name
>         <code>session:encode-url</code> will do this for you. It uses the
>         <code>encodeURL</code> method from the Servlet API which encodes
>         an URL in a way that a session ID is being attached. Consult your
>         servlet engine documentation for information about what the <code>encodeURL</code>
>         method returns. For example, the Tomcat
>         engine adds a string <code>;jsession=</code> followed by an MD5 hash
>         to the URL, but only if the client's browser does not accept cookies.
>         </p>
>         <p>Here is the fragment for the <code>session:encode-url</code>:</p>
> <source><![CDATA[
>   <!-- encode an URL with the session ID -->
>   <xsl:template match="session:encode-url">
>     <xsl:variable name="href">
>         "<xsl:value-of select="@href"/>"
>     </xsl:variable>
>     <xsp:element name="a">
>        <xsp:attribute name="href">
>           <xsp:expr>response.encodeURL(String.valueOf(<xsl:copy-of select="$href"/>))</xsp:expr>
>        </xsp:attribute>
>        <xsl:value-of select="."/>
>     </xsp:element>
>   </xsl:template>
> ]]></source>
>          <p>
>          As you might wonder, the XSP template constructs a HTML tag <code>&lt;a&gt;</code>
> an
>          attribute <code>href</code> which is enough for most of the cases.
>          Other methods, like XLink, are planned to be supported at a later time when
>          final W3C recommendations are out.
>          </p>
>          </s2>
>          <s2 title="Creating new sessions">
>          <p>
>          The best place of a web site where new sessions should be created is the entry
>          where all or most of the visitors step in. After creating the session, or
>          retrieving an old session, the visitor is redirected to a start page.
>          In Cocoon, you must edit your sitemap in order to
>          specify this interesting point of session creation.
>          The <code>map-redirect-to</code>
>          has an extra attribute <code>session</code>, which can be set to
>          or <code>false</code>. The former will generate a new session ID
if needed
>          by invoking the Servlet API method <code>session = request.getSession(true)</code>,
>          while the latter ignores session ID handling.
>          </p>
>          <p>
>          How can Cocoon recognize URIs with appended session IDs? The answer is:
>          Cocoon can match a wildcard against your sessionized pages and keeps happy.
>          So please do not forget to append an asterisk '*' to your patterns in the pipelines.
>          </p>
>          <p>
>          This fragment from <code>sitemap.xsl</code> shows how you can add
>          <code>map:redirect-to</code> to
>          your Cocoon framework with session handling at the root URL for your
>          web application:
>          </p>
> <source><![CDATA[
>  <map:pipelines>
>   <map:pipeline>
>    <map:match pattern="">
>      <map:redirect-to session="true" uri="welcome"/>
>    </map:match>
>    <map:match pattern="welcome*">
>     <map:generate type="file" src="site/welcome.xml"/>
>     <map:transform src="stylesheets/welcome.xsl"/>
>     <map:serialize/>
>    </map:match>
>    <map:match pattern="**.xsp*">
>     <map:generate type="serverpages" src="site/{1}.xsp"/>
>     <map:transform src="stylesheets/dynamic-page2html.xsl"/>
>     <map:serialize/>
>    </map:match>
> ]]></source>
>            <p>
>            The following code must be present in the <code>sitemap.xsl</code>
file to support
>            the extra session parameter for <code>map:redirect-to</code>.
>            </p>
> <source><![CDATA[
>   <!-- generate the code to redirect a request -->
>   <xsl:template match="map:redirect-to">
>     <xsl:choose>
>       <!-- redirect to a internal resource definition -->
>       <xsl:when test="@resource">
>         if(true)return resource_<xsl:value-of select="translate(@resource, '- ',
> '__')"/>(pipeline, listOfMaps, environment, cocoon_view);
>       </xsl:when>
>       <!-- redirect to a external resource definition with optional session mode attribute.
> the environment do the redirect -->
>       <xsl:when test="@uri">
>         <xsl:variable name="sess">
>           <xsl:choose>
>             <xsl:when test="@session='yes'">true</xsl:when>
>             <xsl:when test="@session='true'">true</xsl:when>
>             <xsl:when test="@session='no'">false</xsl:when>
>             <xsl:when test="@session='false'">false</xsl:when>
>             <xsl:when test="not(@session)">false</xsl:when>
>           </xsl:choose>
>         </xsl:variable>
>         getLogger().debug("Sitemap: session='<xsl:value-of select="$sess"/>', redirecting
> '<xsl:value-of select="@uri"/>'");
>         environment.redirect (<xsl:value-of select="$sess"/>, substitute(listOfMaps,
> "<xsl:value-of 
=== message truncated ===> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

Davanum Srinivas, JNI-FAQ Manager

Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices!

View raw message