cocoon-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cziege...@apache.org
Subject cvs commit: xml-cocoon2/src/java/org/apache/cocoon/generation ServerPagesGenerator.java
Date Wed, 05 Jun 2002 07:33:25 GMT
cziegeler    2002/06/05 00:33:25

  Modified:    src/documentation/xdocs/developing authentication.xml
                        session.xml
               src/java/org/apache/cocoon/caching CachingOutputStream.java
                        ComponentCacheKey.java PipelineCacheKey.java
                        SourceCacheValidity.java
               src/java/org/apache/cocoon/generation
                        ServerPagesGenerator.java
  Log:
  Some javadocs and doc updates
  
  Revision  Changes    Path
  1.4       +42 -42    xml-cocoon2/src/documentation/xdocs/developing/authentication.xml
  
  Index: authentication.xml
  ===================================================================
  RCS file: /home/cvs/xml-cocoon2/src/documentation/xdocs/developing/authentication.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- authentication.xml	29 May 2002 13:38:48 -0000	1.3
  +++ authentication.xml	5 Jun 2002 07:33:24 -0000	1.4
  @@ -16,12 +16,12 @@
           management/authentication system.</p>
     </s1>
     <s1 title="Sitemap-Components">
  -     <p>The authentication Framework adds some actions to the sitemap: the <en>auth-protect</en>
  -        action, the <en>auth-login</en> action, the <en>auth-logout</en>
action
  -        and the <en>auth-loggedIn</en> action. The <en>authentication-manager</en>
gets
  +     <p>The authentication Framework adds some actions to the sitemap: the <em>auth-protect</em>
  +        action, the <em>auth-login</em> action, the <em>auth-logout</em>
action
  +        and the <em>auth-loggedIn</em> action. The <em>authentication-manager</em>
gets
           the configuration for the authentication framework and the actions controle the
pipelines. 
  -        The <en>auth-login</en> and the <en>auth-logout</en> action
control the
  -        authentication whereas the <en>auth-loggedIn</en> action controls the
application
  +        The <em>auth-login</em> and the <em>auth-logout</em> action
control the
  +        authentication whereas the <em>auth-loggedIn</em> action controls the
application
           flow.</p>
        <p>The use of the authentication framework and its components is described in
the following
           chapters.</p>
  @@ -80,7 +80,7 @@
           <p>Using a unique name for each handler (only alphabetical characters
             and digits are allowed for the handler name), the framework manages different
             handlers. So various parts of the sitemap can be protected in different ways.
A
  -          document can be protected by calling this handler using the <en>auth-protect</en>
  +          document can be protected by calling this handler using the <em>auth-protect</em>
             action. The "auth-protect" action must be included in the pipeline of the
             resource. It gets the handler information as a parameter:</p>
           <source>&lt;map:match pattern="protectedresource"&gt;
  @@ -97,18 +97,18 @@
           <p>If the requested document is not accessible for the user, the framework
             redirects to a special redirect-to document. This document is a mandatory
             configuration of the authentication handler:</p>
  -        <source>&lt;org.apache.cocoon.webapps.authentication.components.AuthenticationManager&gt;
  +        <source>&lt;autentication-manager&gt;
     &lt;handlers&gt;
       &lt;!-- Now follows the handlers configuration --&gt;
       &lt;handler name="unique"&gt;
         &lt;redirect-to uri="cocoon://loginpage"/&gt; &lt;!-- The login resource
--&gt;
       &lt;/handler&gt;
     &lt;/handlers&gt;
  -&lt;/org.apache.cocoon.webapps.authentication.components.AuthenticationManager&gt;</source>
  +&lt;/autentication-manager&gt;</source>
           <p>This redirect-to document is an unprotected document in the
             sitemap. For tracking which document was requested, the redirect-to document
             gets the request parameter "resource" with the value. In addition all
  -          parameters specified inside the <en>redirect-to</en> tag of the handler
  +          parameters specified inside the <em>redirect-to</em> tag of the handler
             configuration are passed to the document.</p>
           <p>This redirect-to document can contain a form for the user
             authentication. This form should invoke the real login document which is
  @@ -159,7 +159,7 @@
           <p>Using this flexible approach nearly any kind of authentication is
             possible (e.g. database, LDAP). The authentication resource is another
             mandatory configuration of the authentication handler:</p>
  -        <source>&lt;org.apache.cocoon.webapps.authentication.components.AuthenticationManager&gt;
  +        <source>&lt;autentication-manager&gt;
     &lt;handlers&gt;
       &lt;!-- Now follows the handlers configuration --&gt;
       &lt;handler name="unique"&gt;
  @@ -167,11 +167,11 @@
         &lt;authentication uri="cocoon:raw://authenticationresource"/&gt;
       &lt;/handler&gt;
     &lt;/handlers&gt;
  -&lt;/org.apache.cocoon.webapps.authentication.components.AuthenticationManager&gt;</source>
  +&lt;/autentication-manager&gt;</source>
           <p>If the authentication resource is a sitemap resource or a remote
             resource, this resource is requested by the framework with the given parameters
from
  -          the <en>auth-login</en> action (see previous chapter: parameters:
userid and
  -          password). In addition all parameters inside the <en>authentication</en>
tag of
  +          the <em>auth-login</em> action (see previous chapter: parameters:
userid and
  +          password). In addition all parameters inside the <em>authentication</em>
tag of
             the handler configuration are passed to the resource. The response for this
             resource must contain valid XML conforming to the following scheme:</p>
           <source>&lt;authentication&gt;
  @@ -260,7 +260,7 @@
        <s2 title="Configuring an Application">
           <p>A "authentication" application is related to one authentication handler,
so an
             application is part of the authentication handler configuration:</p>
  -        <source>&lt;org.apache.cocoon.webapps.authentication.components.AuthenticationManager&gt;
  +        <source>&lt;autentication-manager&gt;
       &lt;handlers&gt;
           &lt;handler name="unique"&gt;
                ....redirect-to/authentication configuration
  @@ -272,7 +272,7 @@
                &lt;/applications&gt;
           &lt;/handler&gt;
       &lt;/handlers&gt;
  -&lt;/org.apache.cocoon.webapps.authentication.components.AuthenticationManager&gt;</source>
  +&lt;/autentication-manager&gt;</source>
           <p>A configuration for an application consists of a unique name (only
             alphabetical characters and digits are allowed for the application name) and
             optional load and save resources. The application configuration can contain
  @@ -333,7 +333,7 @@
           configuring such components.</p>
        <p>The module configuration is part of the application
           configuration:</p>
  -     <source>&lt;org.apache.cocoon.webapps.authentication.components.AuthenticationManager&gt;
  +     <source>&lt;autentication-manager&gt;
     &lt;handlers&gt;
       &lt;handler name="unique"&gt;
         ....redirect-to/authentication configuration
  @@ -347,7 +347,7 @@
         &lt;/applications&gt;
       &lt;/handler&gt;
     &lt;/handlers&gt;
  -&lt;/org.apache.cocoon.webapps.authentication.components.AuthenticationManager&gt;</source>
  +&lt;/autentication-manager&gt;</source>
        <p>So whenever the portal engine is asked to build the portal it can
           easily retrieve its configuration from the current application by getting the
           module configuration named "portal".</p>
  @@ -356,7 +356,7 @@
        <p>Using the framework it is possible to add new roles to the system and to
           add new users. For this purpose, there are several optional entries for the
           authentication handler which provide the needed functionality:</p>
  -     <source>&lt;org.apache.cocoon.webapps.authentication.components.AuthenticationManager&gt;
  +     <source>&lt;autentication-manager&gt;
     &lt;handlers&gt;
       &lt;handler name="unique"&gt;
                ...redirect-to/authentication configuration...
  @@ -383,7 +383,7 @@
         &lt;delete-user uri="cocoon:raw://financeresource-sunrise-deluser"/&gt;
       &lt;/handler&gt;
     &lt;/handlers&gt;
  -&lt;/org.apache.cocoon.webapps.authentication.components.AuthenticationManager&gt;</source>
  +&lt;/autentication-manager&gt;</source>
        <p>The entries are described in the following subchapters. All tags can
           have additional parameter definitions which are passed to the given resource,
           e.g:</p>
  @@ -393,7 +393,7 @@
     &lt;url&gt;db:usertable&lt;/url&gt;
   &lt;/delete-user&gt;</source>
        <s2 title="Getting Roles">
  -        <p>The <en>load-roles</en> resource is invoked from the framework
whenever
  +        <p>The <em>load-roles</em> resource is invoked from the framework
whenever
             it needs information about the available roles. This resource gets the
             parameter "type" with the value "roles" and should deliver an XML schema with
             the root node "roles" and for each role a subelement "role" with a text child
  @@ -405,7 +405,7 @@
   &lt;/roles&gt;</source>
        </s2>
        <s2 title="Getting Users">
  -        <p>The <en>load-users</en> resource is called whenever information
  +        <p>The <em>load-users</em> resource is called whenever information
             about the available users is needed. There are three different uses of this
             resource:</p>
           <ul>
  @@ -437,36 +437,36 @@
   &lt;/users&gt;</source>
        </s2>
        <s2 title="Creating a new role">
  -        <p>The <en>new-role</en> resource creates a new role in the system.
It
  +        <p>The <em>new-role</em> resource creates a new role in the system.
It
             gets the parameters "type" with the value "role" and "role" with the new
             rolename.</p>
        </s2>
        <s2 title="Creating a new user">
  -        <p>The <en>new-user</en> resource creates a new user with a role.
It
  -          gets the parameters <en>"type"</en> with the value <en>"user"</en>,
  -          <en>"role"</en> with the rolename and <en>"ID"</en> with
the new ID for this
  +        <p>The <em>new-user</em> resource creates a new user with a role.
It
  +          gets the parameters <em>"type"</em> with the value <em>"user"</em>,
  +          <em>"role"</em> with the rolename and <em>"ID"</em> with
the new ID for this
             user.</p>
        </s2>
        <s2 title="Changing information of a user">
  -        <p>The <en>change-user</en> resources changes information of
a user.
  +        <p>The <em>change-user</em> resources changes information of
a user.
             It gets the parameters "type" with the value "user", "role" with the rolename
             and "ID" with the ID of the user. In addition all - application specific -
             information of this user is send as parameters.</p>
        </s2>
        <s2 title="Delete a user">
  -        <p>The <en>delete-user</en> resource should delete a user. It
gets the
  +        <p>The <em>delete-user</em> resource should delete a user. It
gets the
             parameters "type" with the value "user", "role" with the rolename and "ID" with
             the ID of the user.</p>
        </s2>
        <s2 title="Delete a role">
  -        <p>The <en>delete-role</en> resources deletes a role. It gets
the
  +        <p>The <em>delete-role</em> resources deletes a role. It gets
the
             parameters "type" with the value "role" and "role" with the rolename .</p>
        </s2>
     </s1>
     <s1 title="Configuration Summary">
        <p>Here is a brief summary of the authentication handler configuration: </p>
   
  -     <source>&lt;org.apache.cocoon.webapps.authentication.components.AuthenticationManager&gt;
  +     <source>&lt;autentication-manager&gt;
     &lt;handlers&gt;
       &lt;handler name="unique"&gt;
         &lt;redirect-to uri="cocoon:raw://loginpage"/&gt; &lt;!-- The redirect-to
resource --&gt;
  @@ -503,20 +503,20 @@
   
       &lt;/handler&gt;
     &lt;/handlers&gt;
  -&lt;/org.apache.cocoon.webapps.authentication.components.AuthenticationManager&gt;</source>
  +&lt;/autentication-manager&gt;</source>
     </s1>
     <s1 title="Pipeline Patterns">
  -     <p>As explained in the previous chapters, the framework uses the <en>auth-protect</en>
  +     <p>As explained in the previous chapters, the framework uses the <em>auth-protect</em>
           action for authentication and protecting documents. This chapter shows some
           common used pipeline patterns for using this framework.</p>
        <s2 title="Single protected document">
  -        <p>For protecting a document with an authentication handler only the <en>auth-protect</en>
  +        <p>For protecting a document with an authentication handler only the <em>auth-protect</em>
             action with the parameter configuration for the handler is required.</p>
           <p>Pattern:</p>
           <ol>
             <li>Pipeline matching
             </li>
  -          <li>Using the <en>auth-protect</en> action for protecting
  +          <li>Using the <em>auth-protect</em> action for protecting
             </li>
           </ol>
           <p>Example:</p>
  @@ -529,7 +529,7 @@
       &lt;map:serialize/&gt;
     &lt;/map:act&gt;
   &lt;/map:match&gt;</source>
  -        <p>It is very important that the <en>auth-protect</en> action
wrapps the real
  +        <p>It is very important that the <em>auth-protect</em> action
wrapps the real
             pipeline, as the pipeline is only invoked if the action grants access. The
             matching must be done before the action is checked as the action performs a
             redirect for this document.</p>
  @@ -544,7 +544,7 @@
           <ol>
             <li>Pipeline pattern matching
             </li>
  -          <li>Using the <en>auth-protect</en> action for protection
  +          <li>Using the <em>auth-protect</em> action for protection
             </li>
             <li>Pipeline matching
             </li>
  @@ -574,9 +574,9 @@
        </s2>
        <s2 title="Controlling the Application Flow">
           <p>If you want to create documents which behave different wheather you
  -          are logged in or not, the <en>auth-loggedIn</en> action is the component
to
  +          are logged in or not, the <em>auth-loggedIn</em> action is the component
to
             controll your application flow. This action checks if the user is authenticated
  -          for a given handler and calls all sitemap components inside the <en>act</en>
  +          for a given handler and calls all sitemap components inside the <em>act</em>
             tag.</p>
           <source>&lt;map:match pattern="startpage"&gt;
   
  @@ -591,10 +591,10 @@
     &lt;map:serialize/&gt;
   &lt;/map:match&gt;</source>
           <p>In the example above, if the user is already logged he is
  -          redirected to the <en>loggedInStartPage</en> document. If he is not
logged in
  +          redirected to the <em>loggedInStartPage</em> document. If he is not
logged in
             for the given handler, the usual start page is generated.</p>
  -        <p>Both actions, the <en>auth-protect</en> and the
  -          <en>auth-loggedIn</en> action return - if the user is logged in for
the
  +        <p>Both actions, the <em>auth-protect</em> and the
  +          <em>auth-loggedIn</em> action return - if the user is logged in for
the
             given handler - all values from the context to the sitemap, e.g. ID, role etc.
             These values can be used within the other components:</p>
           <source>&lt;map:match pattern"protected"&gt;
  @@ -608,9 +608,9 @@
   
     &lt;/map:act&gt;
   &lt;/map:match&gt;</source>
  -        <p>But the <en>auth-loggedIn</en> action does not give the included
pipeline
  +        <p>But the <em>auth-loggedIn</em> action does not give the included
pipeline
             access to the authentication context belonging to the handler. If you want this,
you
  -          have to nest the <en>auth-protect</en> action inside!</p>
  +          have to nest the <em>auth-protect</em> action inside!</p>
           <source>&lt;map:match pattern"start"&gt;
   
     &lt;map:act type="auth-loggedIn"&gt;  &lt;!-- check authentication --&gt;
  
  
  
  1.3       +17 -0     xml-cocoon2/src/documentation/xdocs/developing/session.xml
  
  Index: session.xml
  ===================================================================
  RCS file: /home/cvs/xml-cocoon2/src/documentation/xdocs/developing/session.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- session.xml	8 May 2002 06:21:38 -0000	1.2
  +++ session.xml	5 Jun 2002 07:33:24 -0000	1.3
  @@ -30,6 +30,23 @@
           special contexts are the request context, the response context and the
           temporary context.</p>
     </s1>
  +  <s1 title="Session Tracking">
  +    <p>If a user has a session, Cocoon is able to connect new requests from this
user
  +       to the session of the user. This is done by session tracking. Basically,
  +       the session tracking of Cocoon uses the session tracking of the environment,
  +       which is usually the servlet engine.
  +    </p>
  +    <p>There are two methods for session tracking: cookies and url rewriting. If
you
  +       use cookies, you don't have to care about session tracking. Just refer to
  +       the documentation of your servlet engine on how to turn on cookies for session
  +       handling.</p>
  +    <p>URL rewriting instead is a little bit complicated. For url rewriting, each
link
  +       the user can select, needs a special session ID appended to this link. 
  +       Unfortunately, this is not done automatically by Cocoon or the servlet engine.
  +       You can either do this by hand or you can use the <em>encodeURL</em>
transformer
  +       just before the <em>html serializer</em>.
  +    </p>
  +  </s1>
     <s1 title="Sessions">
        <p>The session action is responsible for creating and
           terminating a session. It is controlled by a sitemap parameter named "action".
  
  
  
  1.6       +2 -2      xml-cocoon2/src/java/org/apache/cocoon/caching/CachingOutputStream.java
  
  Index: CachingOutputStream.java
  ===================================================================
  RCS file: /home/cvs/xml-cocoon2/src/java/org/apache/cocoon/caching/CachingOutputStream.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- CachingOutputStream.java	22 Feb 2002 07:03:49 -0000	1.5
  +++ CachingOutputStream.java	5 Jun 2002 07:33:24 -0000	1.6
  @@ -54,12 +54,12 @@
   import java.io.OutputStream;
   
   /**
  - * This is an OutputStream which forwards all received bytes to another
  + * This is an {@link OutputStream} which forwards all received bytes to another
    * output stream and in addition caches all bytes, thus acting like a
    * TeeOutputStream.
    *
    * @author <a href="mailto:cziegeler@apache.org">Carsten Ziegeler</a>
  - * @version CVS $Id: CachingOutputStream.java,v 1.5 2002/02/22 07:03:49 cziegeler Exp $
  + * @version CVS $Id: CachingOutputStream.java,v 1.6 2002/06/05 07:33:24 cziegeler Exp $
    */
   
   public final class CachingOutputStream
  
  
  
  1.12      +3 -3      xml-cocoon2/src/java/org/apache/cocoon/caching/ComponentCacheKey.java
  
  Index: ComponentCacheKey.java
  ===================================================================
  RCS file: /home/cvs/xml-cocoon2/src/java/org/apache/cocoon/caching/ComponentCacheKey.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- ComponentCacheKey.java	28 May 2002 13:16:31 -0000	1.11
  +++ ComponentCacheKey.java	5 Jun 2002 07:33:24 -0000	1.12
  @@ -55,13 +55,13 @@
    * This is the cache key for one sitemap component.
    * It consists of three parts:<br/>
    * a.) The component type (generator, transformer etc.)<br/>
  - * a.) The component identifier - a unique handle for the sitemap
  + * b.) The component identifier - a unique handle for the sitemap
    *      component<br/>
  - * b.) The cache key - a key, generated by the component, which
  + * c.) The cache key - a key, generated by the component, which
    *      is unique inside the components space.
    *
    * @author <a href="mailto:cziegeler@apache.org">Carsten Ziegeler</a>
  - * @version CVS $Id: ComponentCacheKey.java,v 1.11 2002/05/28 13:16:31 cziegeler Exp $
  + * @version CVS $Id: ComponentCacheKey.java,v 1.12 2002/06/05 07:33:24 cziegeler Exp $
    */
   public final class ComponentCacheKey
       implements Serializable {
  
  
  
  1.16      +3 -3      xml-cocoon2/src/java/org/apache/cocoon/caching/PipelineCacheKey.java
  
  Index: PipelineCacheKey.java
  ===================================================================
  RCS file: /home/cvs/xml-cocoon2/src/java/org/apache/cocoon/caching/PipelineCacheKey.java,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- PipelineCacheKey.java	3 Jun 2002 12:36:46 -0000	1.15
  +++ PipelineCacheKey.java	5 Jun 2002 07:33:24 -0000	1.16
  @@ -54,11 +54,11 @@
   import java.util.List;
   
   /**
  - * This is the cache key for one pipeline. It consists of one
  - * or more {@link ComponentCacheKey}s.
  + * This is the cache key for one pipeline (or the first part of a pipeline).
  + * It consists of one or more {@link ComponentCacheKey}s.
    *
    * @author <a href="mailto:cziegeler@apache.org">Carsten Ziegeler</a>
  - * @version CVS $Id: PipelineCacheKey.java,v 1.15 2002/06/03 12:36:46 cziegeler Exp $
  + * @version CVS $Id: PipelineCacheKey.java,v 1.16 2002/06/05 07:33:24 cziegeler Exp $
    */
   public final class PipelineCacheKey
       implements java.io.Serializable {
  
  
  
  1.6       +2 -2      xml-cocoon2/src/java/org/apache/cocoon/caching/SourceCacheValidity.java
  
  Index: SourceCacheValidity.java
  ===================================================================
  RCS file: /home/cvs/xml-cocoon2/src/java/org/apache/cocoon/caching/SourceCacheValidity.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- SourceCacheValidity.java	4 Jun 2002 08:55:48 -0000	1.5
  +++ SourceCacheValidity.java	5 Jun 2002 07:33:24 -0000	1.6
  @@ -54,11 +54,11 @@
   
   /**
    * A CacheValidity object wrapping the Avalon Excalibur
  - * <code>SourceValidity</code> object.
  + * {@link SourceValidity} object.
    *
    * @since @next-version@
    * @author <a href="mailto:cziegeler@apache.org">Carsten Ziegeler</a>
  - * @version CVS $Id: SourceCacheValidity.java,v 1.5 2002/06/04 08:55:48 cziegeler Exp $
  + * @version CVS $Id: SourceCacheValidity.java,v 1.6 2002/06/05 07:33:24 cziegeler Exp $
    */
   public final class SourceCacheValidity
   implements CacheValidity {
  
  
  
  1.16      +1 -2      xml-cocoon2/src/java/org/apache/cocoon/generation/ServerPagesGenerator.java
  
  Index: ServerPagesGenerator.java
  ===================================================================
  RCS file: /home/cvs/xml-cocoon2/src/java/org/apache/cocoon/generation/ServerPagesGenerator.java,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- ServerPagesGenerator.java	4 Jun 2002 11:22:59 -0000	1.15
  +++ ServerPagesGenerator.java	5 Jun 2002 07:33:24 -0000	1.16
  @@ -66,7 +66,6 @@
   import org.apache.cocoon.caching.CacheValidity;
   import org.apache.cocoon.caching.Cacheable;
   import org.apache.cocoon.caching.CompositeCacheValidity;
  -import org.apache.cocoon.caching.ParametersCacheValidity;
   import org.apache.cocoon.components.language.generator.ProgramGenerator;
   import org.apache.cocoon.components.source.SourceUtil;
   import org.apache.cocoon.environment.SourceResolver;
  @@ -98,7 +97,7 @@
    *
    * @author <a href="mailto:ricardo@apache.org">Ricardo Rocha</a>
    * @author <a href="mailto:sylvain@apache.org">Sylvain Wallez</a>
  - * @version CVS $Id: ServerPagesGenerator.java,v 1.15 2002/06/04 11:22:59 cziegeler Exp
$
  + * @version CVS $Id: ServerPagesGenerator.java,v 1.16 2002/06/05 07:33:24 cziegeler Exp
$
    */
   public class ServerPagesGenerator extends ServletGenerator
           implements Disposable, Cacheable, Configurable {
  
  
  

----------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          cocoon-cvs-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-cvs-help@xml.apache.org


Mime
View raw message