Here is a table which summarises the steps required to actually deploy +your application in the different server environments or frameworks:
+ +| Framework | +Deployment Steps | +
|---|---|
| BaseHTTPRequestHandler | +Just run the adapter code | +
| CGI | +Declare a script directory in the Web server + Deploy application code in the specified script directory + Restart the Web server |
+
| Java Servlet | +Use the supplied script in tools/JavaServlet and
+ follow your servlet container's instructions |
+
| mod_python | +Declare a handler directory in Apache + Deploy application code in the specified handler directory + Restart Apache |
+
| Twisted | +Just run the adapter code | +
| Webware | +Copy or symbolically link your application code directory to reside
+ alongside other Webware plug-ins + Configure your application within Webware + Start Webware |
+
| WSGI | +(Follow the instructions for CGI - this may change in future.) | +
| Zope | +Copy or symbolically link your application code directory to reside
+ in the Zope Products directory+ Configure etc/zope.conf+ Start Zope + Add a product instance for your application at the desired location + in the Zope filesystem |
+
Notes on each server environment can be found in subdirectories within the
+docs directory:
The process of deploying a WebStack application should be as +straightforward as taking some adapter or "glue" code and either running it +or using the deployment processes of the server environment or framework in +which the application will be living.
+ +When deploying an application, it is possible to use a one-shot deploy
-function for certain frameworks. The deploy function is called
-as follows:
deploy(resource) -deploy(resource, authenticator) # where authenticators are used+
What adapter or "glue" code does is to set up your applications main +resource object and to hook that object up with the underlying server +environment. It typically looks something like this:
+from WebStack.Adapters.CGI import deploy # import the support for the server environment +from MyApplication import MyResource # import the main resource class +deploy(MyResource()) # connect a resource object to the server environment-
For some frameworks, an address may be specified:
-deploy(resource, address=(host_string, port_integer)) -deploy(resource, authenticator, address=(host_string, port_integer))+
Unfortunately, not all server environments can be connected up with +applications this easily. Some environments require special classes and +functions to be defined in the adapter code in order for the applications to +be properly integrated into the environments. Here is a summary which +indicates the server environments or frameworks which need most work:
-| Framework | -Address Information | +Adapter Code Requirements | +Deployment Process |
|---|---|---|---|
| BaseHTTPRequestHandler | -Supported | +Simple - see above | +Run the adapter code directly |
| CGI | -Ignored | +Simple - see above | +Web server runs the adapter code | +
| Java Servlet | +Must subclass HttpServlet |
+ Application must be deployed using supplied tools | +|
| mod_python | +Must implement handler function |
+ Web server runs the adapter code (which must be declared within + Apache) | |
| Twisted | -Supported (host_string is ignored) |
+ Simple - see above | +Run the adapter code directly | +
| Webware | +<= 0.8.1: Must implement InstallInWebKit
+ function+ > 0.8.1: Simple, but must provide a urlParser
+ object |
+ Application must be deployed within WebKit | |
| WSGI | -Ignored | +Simple - see above | +Web server runs the adapter code | +
| Zope | +Must provide lots of Zope administative classes and functions | +Application must be deployed within Zope |
The other frameworks do not support the deploy function due to the way -applications are typically integrated into the various server mechanisms:
- -| Framework | -Deployment Details | -
|---|---|
| JavaServlet | -Applications are packaged specially | -
| ModPython | -Applications must expose certain functions | -
| Webware | -Applications must expose certain classes | -
| Zope | -Applications must expose certain functions/classes | -
When deploying your application, it is essential that it has access to all
+the necessary libraries and packages that it uses. If such libraries and
+packages were installed using the standard setup.py program,
+then you may only need to worry about the application itself being found by
+Python.
For those server environments where you can just run the adapter code
+(BaseHTTPRequestHandler, Twisted), you can choose to specify the
+PYTHONPATH on the command line when you run the code. Here is an
+example of this (using bash on GNU/Linux or UNIX
+distributions):
PYTHONPATH=.:examples/Common python examples/BaseHTTPRequestHandler/SimpleApp.py+ +
For those server environments where the Web server itself runs the adapter
+code (CGI, mod_python, WSGI), you may need to either configure the Web server
+to alter the PYTHONPATH, if possible, or to add some extra lines
+in the adapter code to change Python's sys.path variable. Here
+is an example of this:
sys.path.append("/home/paulb/Software/Python/WebStack/examples/Common")
+
+In servlet container deployments, all required libraries and packages are
+typically bundled with the application itself. Since this bundling process is
+usually very inconvenient, a script has been included in the
+tools/JavaServlet directory to make it slightly easier.
Since Webware's WebKit runs as a separate process, it is possible to
+specify PYTHONPATH on the command line when you start that
+process. Here is an example of this (using bash on GNU/Linux or
+UNIX distributions):
cd WebKit +PYTHONPATH=/home/paulb/Software/Python/WebStack/examples/Common ./AppServer+ +
In Zope's etc/zope.conf file, path directives
+can be used to indicate the location of various resources. Here is an example
+of this:
path /home/paulb/Software/Python/WebStack/examples/Common+ + diff -r bc524d856696 -r e870f9802b37 docs/writing-adapters.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/docs/writing-adapters.html Sat Apr 09 12:32:28 2005 +0000 @@ -0,0 +1,67 @@ + + + + +
Depending on how "simple" the adapter code is allowed to be for a given +server environment (see the table for a +summary), you will either need to write a small piece of code which +initialises and deploys your application, or to produce a more complicated +piece of code which satisfies some more demanding server requirements.
+ +When deploying an application, it is possible to use a one-shot deployment
+function for BaseHTTPRequestServer, CGI, Twisted and WSGI. The
+deploy function is called as follows:
deploy(resource) +deploy(resource, authenticator) # where authenticators are used+ +
For some frameworks, an address may be specified:
+deploy(resource, address=(host_string, port_integer)) +deploy(resource, authenticator, address=(host_string, port_integer))+ +
Here is a summary of which frameworks require address information:
+ +| Framework | +Address Information | +
|---|---|
| BaseHTTPRequestHandler | +Supported | +
| CGI | +Ignored | +
| Twisted | +Supported (host_string is ignored) |
+
| WSGI | +Ignored | +
The remaining frameworks (Java Servlet, mod_python, Webware and Zope) do
+not support the deploy function due to the way applications are
+typically integrated into the various server mechanisms. In these cases, it
+may be worth investigating the examples provided and using their adapter code
+as a template for the code for your own applications.