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/class | responsibilities | collaborations | |
---|---|---|---|
package connector | interface to the outside world | ||
*Connector | (a.k.a. Adaptor: e.g. CGIConnector, Mod*Connector, HTTPConnector, FTPConnector)
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. | ||
Container | the "structural" part of Application | ||
+ Engine | singleton top level dispatcher | ||
+ Host | an Engine for handling one virtual host within a standalone HTTP server. | ||
+ Context | a "web application:" a set of resources and flow designed to be deployed as a unit. | ||
+ Wrapper |
| ||
Valve/Pipeline |
| ||
Mapper | maps 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 ? | |||
Lifecycle | mixin for things that need to "start" and "stop" (e.g. Connector, Container, SessionStore) | ||
package support | |||
Session | |||
Session*Store | |||
Resources | provides access to "files" in a uniform way: e.g. allows serving directly from a jar file, ZODB, CVS, etc. | ||
Realm | a.k.a. UserKit | ||
CanKit | |||
MiddleKit | |||
package servlet | the "inside world", based directly on the Java Servlet API | ||
Servlet | handles requests | ||
ServletContext | access to the server resources (package support) |