Terrel Shumway wrote:

> "Love, Jay" wrote:
> >
> > As far as implementing this as a pluggable architecture, I have a design
> > that I have been meaning to implement where this would fit very well.
> >

Oops. I misread one detail of Jay's idea. "Context object added to the Transaction". Catlina Container objects are a *replacement* for Application (Application -> the singleton Engine), but the goals are the same. I think the catalina architecture grows better: it is easier to compose independently-developed filters and create new classes of processing behaviors, such as the SuperServlet that Ender is suggesting.

Most of the functionality that Application currently implements (reading the config files and setting things up) fits a creational pattern. dispatchRequest (a.k.a. invoke) and serverSidePathForRequest (a.k.a. map) are decidedly behavioral, and should be factored out of the creator class (IMO). This would also make it easier to make a slimmed-down OneShot creator and batteries-included AppServer creator.

Here is a CRC diagram for catalina in a webware context:

package/classresponsibilitiescollaborations
package connectorinterface to the outside world
*Connector

(a.k.a. Adaptor: e.g. CGIConnector, Mod*Connector, HTTPConnector, FTPConnector)

  1. receives requests from an external entity,
  2. builds a Request and a Response (Transaction)
  3. dispatches this transaction to the singleton Engine container
  4. passes the response back out the the requesting entity

a connector could define its own Request/Response classes as long as they present a "standard" interface to Containers and Servlets. For example, FTPConnector would create multiple Requests from a single command connection, the Response object would have to manage the data connection.

RequestWrapper and ResponseWrapper make this even more useful.

Request
Response
package container (core) defines the structure of the URL space, access control, and how servlets are wired together.
Containerthe "structural" part of Application
+ Enginesingleton top level dispatcher
+ Hostan Engine for handling one virtual host within a standalone HTTP server.
+ Contexta "web application:" a set of resources and flow designed to be deployed as a unit.
+ Wrapper
  • interface to a leaf resource (servlet, file, PSP, etc.)
  • supplies the ServletContext available to the Servlet
  • handles servlet creation, threading, and reuse
Valve/Pipeline
  • basic behavior for each container class (the "behavior" part of Application)
  • pluggable processing behaviors (e.g. authentication, access control, logging)
Mappermaps request URIs to Containers, updates the Request object appropriately.
package server (startup)
*AppServer
the "builder" part of Application

reads config files, builds the containers and connectors, hooks everything together, then says "GO!".

Monitor
TaskKit ?
Lifecyclemixin for things that need to "start" and "stop" (e.g. Connector, Container, SessionStore)
package support
Session
Session*Store
Resourcesprovides access to "files" in a uniform way: e.g. allows serving directly from a jar file, ZODB, CVS, etc.
Realma.k.a. UserKit
CanKit
MiddleKit
package servletthe "inside world", based directly on the Java Servlet API
Servlethandles requests
ServletContextaccess to the server resources (package support)

SourceForge.net