tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cos...@apache.org
Subject cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core Handler.java ServerSession.java package.html
Date Mon, 19 Feb 2001 20:22:43 GMT
costin      01/02/19 12:22:42

  Modified:    src/share/org/apache/tomcat/core Handler.java
                        ServerSession.java package.html
  Log:
  Update core documentation ( package.html )
  
  Added a section with core dependencies, removed unused imports.
  
  This prepares for more core review.
  
  Revision  Changes    Path
  1.37      +0 -1      jakarta-tomcat/src/share/org/apache/tomcat/core/Handler.java
  
  Index: Handler.java
  ===================================================================
  RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Handler.java,v
  retrieving revision 1.36
  retrieving revision 1.37
  diff -u -r1.36 -r1.37
  --- Handler.java	2001/02/06 06:37:37	1.36
  +++ Handler.java	2001/02/19 20:22:36	1.37
  @@ -60,7 +60,6 @@
   
   import org.apache.tomcat.util.Counters;
   import org.apache.tomcat.util.log.*;
  -import org.apache.tomcat.util.collections.EmptyEnumeration;
   
   /**
    * The class that will generate the actual response or response fragment.
  
  
  
  1.4       +3 -2      jakarta-tomcat/src/share/org/apache/tomcat/core/ServerSession.java
  
  Index: ServerSession.java
  ===================================================================
  RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/ServerSession.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- ServerSession.java	2001/01/01 00:17:23	1.3
  +++ ServerSession.java	2001/02/19 20:22:38	1.4
  @@ -65,8 +65,9 @@
   import java.util.Enumeration;
   import java.util.Hashtable;
   import java.util.Vector;
  -import org.apache.tomcat.util.*;
  -import org.apache.tomcat.util.threads.*;
  +import org.apache.tomcat.util.MessageBytes;
  +import org.apache.tomcat.util.Counters;
  +import org.apache.tomcat.util.threads.TimeStamp;
   
   /**
    * Server representation of a Session.
  
  
  
  1.5       +76 -81    jakarta-tomcat/src/share/org/apache/tomcat/core/package.html
  
  Index: package.html
  ===================================================================
  RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/package.html,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- package.html	2000/05/09 17:56:19	1.4
  +++ package.html	2001/02/19 20:22:38	1.5
  @@ -5,6 +5,23 @@
     </head>
     
     <body bgcolor="#FFFFFF">
  +    <h2>Architecture</h2>
  +    
  +    <p>Tomcat core defines a number of base abstractions ( Request, Response,
  +    Context, etc ) and a simple interface for modules.</p>
  +
  +    <p>All server functionality is implemented in modules, using callbacks in
  +      a model similar with Apache and other servers. </p>
  +
  +    <p>The ServletAPI and all specific contracts are implemented in 
  +      special module(s) - that allows to keep the core simple and 
  +      permits more flexibility. </p>
  +    
  +    <p>The callbacks are defined in BaseInterceptor. A module will 
  +      extend that class and possibly Handler if it wants to generate
  +      content. The module will use the information and API provided in Request,
  +      Response, Context, Container.
  +
       <h2>Components</h2>
   
       <dl>
  @@ -12,104 +29,82 @@
         <dt>ContextManager</dt>
         <dd>
       	<ul>
  -      	  <li>maintains a list of adapters</li>
  -      	  <li>is the entry point for adapters and any component that can generate

  -	    a Request/Response and wants to use servlets.</li>
  -      	  <li>is the control point that handles callback calls and notifications.</li>
  -      	  <li>maintains a list of webapps that are configured in the system.</li>
  +      	  <li>control point for callback calls and notifications.</li>
  +      	  <li>manages server startup/shudown</li>
  +      	  <li>manages request execution (entry point,coordinates modules)</li>
  +      	  <li>maintains a list of global modules</li>
  +      	  <li>maintains a list of webapps</li>
       	</ul>
         </dd>
         
         <dt>Request,Response</dt>
  -      <dd>Internal representations, containing various attributes associated with
  -    	the request during processing.
  +      <dd>Internal representations for HTTP request/response, including 
  +	common attributes. Tuned for memory use ( recycling ) and performance,
  +	with minimal contracts.
         </dd>
   
  -      <dt>Interceptors</dt>
  +      <dt>Module base ( BaseInterceptor )</dt>
         <dd> 
  -	Request processing involves several stages - parsing, matching using url
  -	patterns, authentication and authorization, calling the handler and various
  - 	callbacks before, after and during the handler. 
  -	An interceptor defines callbacks ( or hooks ) for one or several actions
  -	and is able to alter that function.
  -	In fact, most of the processing logic is implemented as interceptor 
  -	callbacks, in an event-based system.
  +	An interceptor defines callbacks ( or hooks ) that implement one or
  +	several server functions. Almost all of the processing logic is
  +	implemented as interceptor callbacks. 
         </dd>
   
  -      <dt>Context, Container</dt>
  +      <dt>Handler</dt>
         <dd>
  -    	Container represents a group of URLs sharing common properties like handler,
  -    	security, normal properties. Context is a particular case that is associated
  -    	with a web application and keeps all the properties defined in the spec. 
  -    	We are slowly moving toward use of Container, it can also represent group
  -    	of contexts, virtual hosts, etc. 
  -    	It is not a good idea to introduce sub-classes for every type of group, 
  -    	the isA property is not allways clearly cut. 
  +    	Content generator part of modules. Simple generators ( like 
  +	error handlers), wrappers for Servlets or JSPs or complex 
  +	chains/pipelines can be implemented. The handlers are defined
  +	as part of modules.
         </dd>
         
  -      <dt>ServletWrapper</dt>
  -      <dd>
  -    	A normal servlet or JSP, plus all the surounding logic.
  +      <dt>Context</dt>
  +      <dd>Attributes shared by a web application, included local modules. 
         </dd>
  -      
  -      
  -      <dt>Facades</dt>
  -      <dd>For every object exposed in the servlet specification tomcat use a 
  -    	Facade. It have few important advantages:
  -    	<ul>
  -	  <li>Security - the user should have no way to access the real implementation
  -	    objects, except one controled way ( HttpRequestFacade.getRealRequest() ).
  -	    When policy-based security will be added that will allow the user to declare a 
  -	    "trusted" servlet, and no other servlet will be able to access internal objects.</li>
  -	  <li>Future evolution of Servlet API - the API changed and will probably change,

  -	    by adding new methods and new semantics. Facades makes very simple to make sure
  -	    we respect the spec, without having to change the core too much.
  -	    That may allow supporting multiple servlet API versions ( but it's not a goal -
  -	    each context has it's own classloader and it may be possible to load a different
  -	    JDK and set of facades ).</li>
  -	  <li>Decouple the API and the web server. Tomcat.core allows integration with
  -	    web servers, and it's  modeled after APIs like Apache's, ISAPI and NSAPI.</li>
  -    	</ul>
  -    	
  +
  +      <dt>Container</dt>
  +      <dd>
  +    	Attributes shared by a group of URLs ( mappings, modules, 
  +	authentication ). This is also the repository for modules used by
  +	ContextManager and Context ( which delegate to the "default"
  +	container ). The default container for the ContextManager stores
  +	attributes common to all URLs ( global modules, etc ), same 
  +	for Context.
  +      </dd>
  +      
  +      <dt>ServerSession</dt>
  +      <dd>Server view of a session - independent of the actual implementation
  +	of the session manager. Modules implementing the session management
  +	callbacks may use a subclass and manage the sessions/
  +      </dd>
  +
  +      <dt>OutputBuffer</dt>
  +      <dd>All content is stored in the OutputBuffer, which implement
  +	storage and conversion functions ( with a lot of tunning for
  +	performance and memory usage )
         </dd>
  +
       </dl>
   
  -    <h2>Authentication and Authorization</h2>    
  -    
  -    <p>Required steps:
  -    <ol>
  -      <li>Find if the request needs authorization. </li>
  -      <li>Check if the request have the right credentials - if not generate 401 
unauthorized.
  -      </li>
  -      <li>The normal error processing takes place: we can register special 401 error
handler 
  -	that will implement the desired auth method
  -      </li>
  -    </ol>
  -
  -    <p>The model we used is JAAS - the authenticator is a separate module that will

  -      find if enough credentials are available. We use a "normal" tomcat module to "glue"
  -      between an auth API ( like JAAS or memoryRealm or catalina Realm if needed ) and

  -      tomcat's internal representation of request. ( no "callbacks" yet - just static util
  -      functions to extract credentials from request. )
  -    </p>
  -      
  -    <p>We provide a simple implementation for standalone tomcat.: 
  -      <ul>
  -	<li>AccessInterceptor will match the security contraints and set a note "required.roles"
  -	  containing the list of valid groups.</li>
  -	<li>SimpleRealm will authorize the request against in-memory users. </li>
  -	<li>BasicLoginServlet, FormLoginServlet - implement the authentication protocol.
  -      </ul>
  -    </p>
  -    
  +    <h2>Dependencies</h2>
   
  -    <p>In "production" mode we expect tomcat to be integrated with various systems.

  -      Most web servers are using a similar mechanism - as long as the server is handling
  -      the static files we need to let him deal with authorization/authentication. 
  -      The only special case is Form based login, where the connector should forward
  -      the request to tomcat. ( no complete implementation yet ).
  -      
  -    </p>
  +    <ul>
  +       <li>org.apache.tomcat.util.log.*</li>
  +       <li>org.apache.tomcat.util.hooks.*</li>
  +       <li>org.apache.tomcat.util.http.*</li>
  +       <li>org.apache.tomcat.util.StringManager; -> res</li>
  +
  +       <li>org.apache.tomcat.util.depend.*: Context/rm </li> 
  +       <li>org.apache.tomcat.util.threads.TimeStamp: ServerSession/rm </li>
  +
  +       <li>org.apache.tomcat.util.MessageBytes;</li>
  +
  +       <li>org.apache.tomcat.util.MimeMap -> http </li>
  +       <li>org.apache.tomcat.util.MimeHeaders -> http </li>
  +
  +       <li>org.apache.tomcat.util.Counters - Handler/rm</li>
  +       <li>org.apache.tomcat.util.SimplePrincipal - Request/->facade</li>
   
  +    </ul>
     </body>
   </html>
  
  
  

Mime
View raw message