repoze.zope2 1.0.3

Overview

repoze.zope2 is a decomposition of the Zope 2 appserver publication
machinery (ZPublisher) into a WSGI application component. It relies
on separately-distributed middleware pieces to perform some of the
features previously handled by ZPublisher and other parts of Zope 2.

Installing repoze.zope2

With a Python 2.4 interpreter >= 2.4.3 (**Python 2.5+ is
unsupported**) with setuptools installed, install the 'virtualenv'
package::

$PYTHONHOME/bin/easy_install virtualenv

When this is done, create a virtualenv "sandbox" to hold the
repoze.zope2 packages and instance data:

$PYTHONHOME/bin/virtualenv --no-site-packages /path/to/sandbox

A directory named 'sandbox' will be created in the /path/to.
directory. You can use any path you like.

After creating a virtualenv sandbox, install the 'repoze.zope2' egg
into the virtualenv.

/path/to/sandbox/bin/easy_install -i http://dist.repoze.org/simple repoze.zope2

NOTE: Some "Syntax Error" messages may be printed to the console
during this process; these can be ignored. This is distutils
attempting to byte-compile Zope "Python Scripts" in skin directories
that aren't valid Python syntax.

After the repoze.zope2 packages are installed into the virtualenv,
you can finally create "instance" files (config files) within the
sandbox by running "mk2zope2instance"::

/path/to/sandbox/bin/mkzope2instance

After these steps have been performed, here's what has happened::

- a "virtual Python" has been installed within the
"/path/to/sandbox" directory. Packages installed to this virtual
Python's 'site-packages' directory will not conflict with packages
installed into your "normal" Python's 'site-packages' directory.

- All packages required by repoze.zope2 have beeen downloaded,
compiled, and installed as Python eggs in the *virtual* Python's
'site-packages' directory.

- 'Products', 'logs', 'var', and 'etc' directories have been created
inside the sandbox directory. 'Products' is where 3rd party Zope
products should be installed. 'logs' is where Zope logs will go,
'var' is where ZODB data files will go, 'etc' is where config
files are placed.

- A sample set of configuration files have been installed into the
sandbox directory's 'etc' subdirectory. These include::

- 'zope.ini', a Paste configuration file used to establish the
Paste (WSGI) pipeline which repoze.zope2 will use to serve up
repoze.zope2.

- 'zope.conf', a classic Zope 2 configuration file which can be
used to adjust Zope settings.

- 'site.zcml', a boilerplate site.zcml that should be used to
control ZCML processing.

The Default Sandbox Configuration

The configuration of WSGI components in the sandbox setup form a
publishing environment in which most Zope applications should be
able to run without modification. Some of the jobs previously
filled by components in Zope have been assumed by repoze and other
WSGI middleware components:

- The job of ZServer has been filled by the zope 3 WSGI server (via
repoze.zope2.server).

- The job of ZPublisher object publishing has been filled by the
object publisher in repoze.zope2

- The job of ZPublisher transaction management has been filled by
repoze.tm middleware.

- The Zope 2 "error_log" has been replaced with error-catching /
error-logging middleware in Paste. (Visit /__error_log__ to see
the exception history).

- "access" logging can now be handled by a middleware component.

- The job of VirtualHostMonster is now filled by repoze.vhm.

Utilities

These utilities are available in the "bin/" directory of the
generated sandbox.

installproduct -- provided the directory path of a classic Zope 2
Product (unpacked), installproduct will attempt to convert the
product into a Python egg and install it into the sandbox's
site-packages directory. This is an alternative to unpacking
putting the product inside the sandbox "Products" directory.

addzope2user -- script which adds a management user to the Zope root
user folder.

runzope2script -- script which runs a Python script with the root
Zope application object as the "app" object in the globals
namespace.

debugzope2 -- runs the Python interactive interpreter with the Zope
root object bound to the "app" name in the global dictionary/

mkzope2instance -- create zope2 instance files in a directory.

Testing repoze.zope2

To all run repoze.zope2 tests, after running setup.py sandbox, cd to
the repoze.zope2 directory and run::

$sandboxdir/bin/python setup.py test

Starting repoze.zope2

To start a server that serves up a demo app on port 8080, cd to the
sandbox directory you created via "setup.py sandbox" and run::

bin/paster serve etc/zope2.ini

When you visit http://localhost:8080/ in a browser, you should see
the Zope 2 quickstart page.

To manage the resulting Zope 2 site, you'll need to add a
management user. From the sandbox directory, run::

bin/zope2adduser <username> <password>

Once this is done, you should be able to visit
http://localhost:8080/manage and log in with the username and
password you supplied.

Deploying

Due to its simplicity, the default "sandbox" server is preferred for
development and for some forms of deployment, but to make life
easier for people more experienced with Apache technologies than
Zope technologies, a reasonable deployment target for repoze.zope2
is Apache via "mod_wsgi":http://code.google.com/p/modwsgi/ .
mod_wsgi is an Apache module that allows you to run WSGI
applications using the Apache HTTP server.

A sample ".wsgi" deployment script (an analogue of the ones
described in the mod_wsgi documentation) is available in the
doc/sample_zope2.wsgi file. A sample Apache configuration which
uses this deployment script is included in the
doc/sample_apache2.conf file.

It's suggested that you serve up repoze.zope2 with mod_wsgi in
"daemon mode" where each if the mod_wsgi's daemon children runs a
single-threaded Zope process. All of the Zope processes should
communicate with a single ZEO server on the back end. You can run a
ZEO server by invoking "bin/zeoctl start -C etc/zeo.conf" from
within a Repoze sandbox. You'll need to change etc/zope.conf,
uncommenting the <zodb_db> section that refers to a client storage
at that point for Zope to work.







CHANGES

1.0.3 (2009-10-12)

- Fix URL quoting on ACTUAL_URL and URL (both need to be quoted).

1.0.2 (2009-08-31)

- Add support for views-on-exceptions. This exists in Zope 2.12 and prior
to that via the FiveException package. You can now register a view onto
an exception class with the name 'index.html'. If found, this will be
rendered when the exception is caught. Note that the transaction will be
aborted regardless. This feature only works on ZODB 3.8 and later, because
it depends on the 'doom()' feature of that version. If doom() is not
available, the exception view will be ignored.

- Calculate PATH_TRANSLATED in the same way as Zope 2.

- Respect VIRTUAL_URL when computing ACTUAL_URL. VIRTUAL_URL may be set up
repoze.vhm >= 0.11, for example, and contains the URL that the user sees.

- When virtual hosting using repoze.vhm is used, and there is a VHM root,
and if that path is present in the PATH_INFO, avoid traversing to the
VHM root objects twice.

1.0.1 (2009-26-8)

- If an IPublishTraverse raises KeyError or AttributeError, the standard
Zope 2 publisher treats it as a 404. Now z2bob does as well.

1.0 (2008-28-11)

- No changes from 0.4.6; declare it 1.0 in order to kick off the 1.X
branch. The repoze.zope2 trunk will now be the home of the 2.X
version.

0.4.6 (2008-07-03)

- During helper teardown, clear out reference to request.response,
so in case the request is leaked, the tempfile associated with the
response isn't.

0.4.5 (2008-06-26)

- Make disable_gc only happen at initialization. Drool.

0.4.4 (2008-06-25)

- Add a configuration flag for the app:zope2 section: 'disable_gc'.
If this flag exists and is true, disable Python garbage collection
for the interpreter used to start the process. This flag probably
doesn't belong here.

- More explictly call noSecurityManager and clear out instance
variables in the bob helper's .teardown method in case a helper
ever leaks.

- Belatedly change Trove classifier to "Development Status :: 4 - Beta"
(it was "Development Status :: 1 - Planning").

0.4.3 (2008-06-18)

- Dont attempt any retries on conflict errors at startup.
This was never tested, and probably didn't work.

- Headers added to the response via "response.addHeaders" (aka
accumulated_headers) were not returned in the response header
list.

- Properly unquote PATH_INFO segments into
TraversalRequestNameStack.

0.4.2 (2008-06-11)

- Deal with Unauthorized exceptions properly: allow
RESPONSE._unauthorized to be run and return a value rather than
unconditionally triggering a basic authentication dialog.

This version depends on repoze.obob 0.4+.

0.4.1 (2008-05-27)

- Use view lookup as well as getattr in next_name to detect whether
a browser default page actually exists in order to support Zope
2.9 "Five.traversable" semantics: getattr alone doesn't work under
2.9 to detect whether a default view exists or not.

0.4.0 (2008-05-21)

- Raise an error Z2BobHelper's map_result method detects that it's
about to return a value to obob which does not have an __iter__
method. This avoids confusion about what's causing failures when
we attempt to publish an "unpublishable" object.

- Fix a not-true-enough emulation of Zope 2.9 publishing semantics.
Symptom: Z3 "adding" views being published without an acquisition
wrapper under Zope 2.9.

0.3.9 (2008-05-08)

- Instance creation now expands the sandbox path in derived files
(e.g. $INSTANCE in zope.conf).

- Do not depend on ZODB3 3.7.2. zopelib ships with a copy of ZODB.
This was initially intended as a "convenience upgrade", but let's
not impose it on people. That said, repoze.retry has a dependency
on a ZODB3 so we'll just wind up with whatever version of ZODB3
happens to be in the index being used anyway.

- Add a setup.cfg that specifies:

[easy_install]
index_url = http://dist.repoze.org/zope2/2.10/simple

This overrides the default PyPI index URL. Because we removed
dependency-links and we don't publish our eggs to PyPI, it is
required to allow "setup.py test", "setup.py develop", and
"setup.py install" to work without the specification of an
'--index_url' argument ("test" doesn't even take one).

- Do not use a dependency-links= in setup.py. Instead, trust the
index to provide the right software.

- Remove explicit version dependencies from install_requires and
test_requires. Use whatever versions of the software are in our
index.

- Provide support for Zope 2.9 (previously support was limited to
Zope 2.10+).

- ZServer didn't call app_iter.close after it finished a request as
required by the WSGI spec (found via Paste#lint).

0.3.8 (2008-05-02)

- Cause zope2testrunner to sys.exit with a nonzero exit code when
any tests fail (for usage under buildbot).

- Filter warnings during addzope2user.

0.3.7 (2008-04-18)

- "Legacy" (VHM) virtual hosting was broken for virtual host roots
that contained more than one path element (e.g. /plone/folder).

- Overhauled "browser default" handling by moving code out of
before_invoke into next_name in the Z2 obob helper. We now treat
browser default names such as 'index_html' as just another
traversal step.

- Depend on repoze.vhm 0.6, which re-adds support for
path-segment-based virtual hosting parameters (as
egg:repoze.vhm#vhm_path).

0.3.6 (2008-04-16)

- "http" exceptions (like Redirect and Unauthorized) weren't handled
properly anywhere except in the repoze.zope2 obob helper's
'invoke' step. In-the-wild code uses these exceptions before the
published object has been located (e.g. during traverse() or
before_traverse()). We now depend on repoze.obob >=0.3 to get
extended exception handling behavior, and we implement a
'handle_exception' method on our z2bob helper which will turn
Zope2 Unauthorized and Redirect exceptions into their
"httpexception" equivalents for consumption by upstream
middleware. This was prompted by code found in the wild in
Plone's OpenId implementation which raises a redirect during
traversal.

0.3.5 (2008-04-16)

- "Legacy" virtual hosting (via Virtual Host Monster) did not work
properly. Symptom: if you set up proxy-rewrite rules in Apache
pointing at the Zope root a repoze.zope2 server running under a
separate paster server, and tried to visit the ZMI via the Apache
virtualhost's /manage URL, you'd be presented with the
VirtualHostMonster ZMI configuration page instead of the ZMI's
framed root UI. Reason: the PARENTS[0] item was not set up early
enough (it was set up in traverse rather than
before_traverse). Since it was depended on by Zope API's which VHM
called out to to set the virtual root, this didn't work, and the
resulting traversal name stack was incorrect.

0.3.4 (2008-03-24)

- Bump ez_setup.py version.

- When Zope 2 starts, it potentially writes data to the database
during product initialization. When multiple clients talk to the
same ZEO storage at startup, they often simultaneously try to
write (the same) information to the database concurrently. This
causes startup failure due to conflict errors. We now retry
product initialization up to five times to work around this issue.

0.3.3 (2008-03-10)

- repoze.zope2 now properly respects virtual host directives
provided to it by repoze.vhm xheaders middleware >= 0.4. Zope's
VHM can still be used as necessary, but is no longer required.

0.3.2 (2008-03-03)

- Fix bug reported by Martin Aspeli: repoze.zope2 would choke on
large images and files (symptom: broken images when images were
large). This was due to the fact that the Zope File- and
Image-rendering machinery used HTTPResponse.write, which
repoze.zope2's response handling didn't handle properly. We now
subclass HTTPResponse (as RepozeHTTPResponse) to solve the issue.

0.3.1 (2008-03-02)

- mkzope2instance now:

o takes no arguments, only options. '-d' replaces the single
argument path.

o creates a "log" directory

o writes out a zeo.conf into "etc" (unconditionally); you can
start a ZEO instance after installation now via 'bin/runzeo -C
etc/zeo.conf', after ensuring that the 'address' in the ZEO
section is correct.

o allows the specification of 'sandbox' (-s) (replaces
single-argument instancedir), 'zeo-port' (-z) , 'zope-port'
(-p), and 'use-zeo' (-z) options. If 'use-zeo' is specified,
the zope.conf that's written will use a ClientStorage by
default.

o writes a zope.conf with a zodb cache-size of 50000 rather than
10000.

- addzope2user, runzope2script, and debugzope2 now respect a
"ZOPE_CONF" environment variable, which can be used to specify the
zope.conf configuration file to use.

- Add a sample <zodb_db main> section to the generated zope.conf
that can be uncommented if the installer wants to use ZEO instead
of FileStorage or vice versa.

- Added an (experimental) 'zope2testrunner' script that sets up
stuff in the environment before running
'zope.testing.testrunner.run'. It accepts the same arguments as
the Zope 3 testrunner. E.g. 'bin/zope2testrunner -m
Products.faster'. This also respects the ZOPE_CONF envvar.

- Depend on Zope 2.10.5 (zopelib-2.10.5.0) instead of 2.10.4.2 and
various other updated repoze libraries.

0.3.0

- Install a mkzope2instance script as a console script to support
non-repozeproject based installs.

- Change documentation to prefer non-repozeproject installations.

0.2.9

- Fix up noncompliant WSGI environment server keys (
CHANNEL_CREATION_TIME was an integer, QUERY_STRING
didn't always exist) in "zserver".

- Make zope2.wsgi mod_wsgi shim actually
work (Carlos de la Guardia).

0.2.8

- Ensure that the REQUEST['URL'] is as computed as possible before
calling __bobo_traverse__/__getitem__/whatever during traversal to
fix a ZMI-related bug. Symptom: when adding folders or Python
Scripts, the redirect back to manage_main would either do nothing
or would cause a traceback.

- Made setuptools 'description' include CHANGES.txt.

0.2.7

- Don't make a 'doc' directory, but make an 'import' directory
during sandbox creation.

- During traversal via __bobo_traverse__, turn any KeyError,
AttributeError, and zExceptions.NotFound into
paste.httpexceptions.NotFound error.

- During traversal via __getattr__, turn AttributeError into a
paste.httpexceptions.NotFound error.

- During traversal via __getitem__, turn KeyError into a
paste.httpexceptions.NotFound error.

- Ensure that request['URL'] is not unicode when inserting it into
the body during _insertBaseTag (or it turns the body into unicode
too, after we've tried to ensure that it's not unicode with a
typecheck and cast).

- Depend on repoze.errorlog >= 0.4, and cause our default error log
handler to ignore httpexceptions.HTTPNotFound, httpexceptions.HTTPFound,
and httpexceptions.Unauthorized.

0.2.6

- Depend on repoze.errorlog and put it in the default pipeline.
Visit '/__error_log__' to see exception history. We do this
because under Repoze, the Zope through-the-web 'error_log'
exception history view is always empty. Use this instead.

- Implement WebDAV support.

0.2.5

- Fix read from RESPONSE.write (it also writes headers).

0.2.4

- Depend on repoze.vhm >= 0.3.

- Allow RESPONSE.write to work (implemented using a temp file).

0.2.3

- Implement XML-RPC marshalling.

- Get maintainer email address right.

- Ditch 'python setup.py sandbox' in favor of documenting
repoze.project-based install (see README.txt).

0.2.2

- Zope2ObobHelper.setup() was URL-quoting the ACTUAL_URL value. This
caused usage of Plone's login portlet to fail (symptom: keyerror on
"http:").

0.2.1

- Add explicit ZODB3 requirement (>= 3.7.2, < 3.8.0a1), because repoze.tm
and repoze.retry have relaxed their requirements, and might therefore
bring in a ZODB incompatible with our zopelib version.

0.2

- Use repoze.obob 0.2 publishing semantics in order to be able to
continue respecting 'TraversalRequestNameStack' (CMF modifies this
stack in before-traversal hooks in CMFDynamicType). This fixes
Plone/CMF (symptoms: Plone front page not shown properly; 'edit'
link for front page pointed to portal instead of default front-page
content).

- Close the ZPublisher HTTPRequest at obob "teardown" time. This
appears to fix a problem where CMF skin method names could not be
found while running CMF and Plone Symptom: transient and
intermittent AttributeError, NotFound error, or KeyError when
attempting to render a page which used skins when running under the
Paste http, PasteScript wsgiutils, or repoze.zope2.server WSGI
servers. Under mod_wsgi, this symptom was never evident.

- Allowed the number of threads to be configurable in the
repoze.zope2.server WSGI server (threads option in server config
section).

0.1

Initial release.