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 Tue, 20 Feb 2001 17:58:11 GMT
Hi Jörg,

Do you have some time to look into the session.xsl which currently exists in Cocoon2 and come
with a doc/samples? This session.xsl has been ported from C1 and my guess is that a lot of
would like to use it again. You could also send us a comparison of your version and the one
is already checked in.


--- 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!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!

View raw message