November 2005 - Zope-Dev

buildbot failure in Zope trunk 2.4 Linux zc-buildbot
by buildbot＠zope.com 03 Nov '05

03 Nov '05

The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 1311 Blamelist: andreasjung BUILD FAILED: failed compile sincerely, -The Buildbot

1 0

buildbot failure in Zope trunk 2.4 Linux zc-buildbot
by buildbot＠zope.com 03 Nov '05

03 Nov '05

The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 1308 Blamelist: philikon BUILD FAILED: failed compile sincerely, -The Buildbot

1 0

buildbot failure in Zope trunk 2.4 Linux zc-buildbot
by buildbot＠zope.com 03 Nov '05

03 Nov '05

The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 1307 Blamelist: jinty,philikon BUILD FAILED: failed compile sincerely, -The Buildbot

1 0

ZSQL method and LIMIT clause
by Thanh Hải, Hà 03 Nov '05

03 Nov '05

Hello, My problem is I don't know to prevent Zope from adding "LIMIT 1000" to the end of each of my ZSQL method (*.zsql). I am developing a filesystem-based product so I can not disable it by setting "Maximum Rows to Retrieve" to zero in the ZMI interface. I got stuck with this problem for a couple of weeks (google search and read documentation didn't help). Any help is greatly appreciated.

3 3

buildbot failure in Zope trunk 2.4 Linux zc-buildbot
by buildbot＠zope.com 03 Nov '05

03 Nov '05

The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 1305 Blamelist: yuppie BUILD FAILED: failed compile sincerely, -The Buildbot

1 0

buildbot failure in Zope trunk 2.4 Linux zc-buildbot
by buildbot＠zope.com 03 Nov '05

03 Nov '05

The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 1304 Blamelist: rogerineichen,srichter,tlotze,yuppie BUILD FAILED: failed compile sincerely, -The Buildbot

1 0

PAS tests failures
by Julien Anguenot 03 Nov '05

03 Nov '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I got tests failing with the following configuration : FC4 Zope-2.8.4 Python 2.3.5 / 2.4.2 PAS trunk as below : ====================================================================== FAIL: Doctest: ChallengeProtocolChooser.txt - ---------------------------------------------------------------------- Traceback (most recent call last): File "/opt/Zope-2.8.4/lib/python/zope/testing/doctest.py", line 2102, in runTest raise self.failureException(self.format_failure(new.getvalue())) AssertionError: Failed doctest test for ChallengeProtocolChooser.txt File "/home/zopes/zope2.8.4/Products/PluggableAuthService/plugins/tests/ChallengeProtocolChooser.txt", line 0 and all the failures within this doctest look like this one : - ---------------------------------------------------------------------- File "/home/zopes/zope2.8.4/Products/PluggableAuthService/plugins/tests/ChallengeProtocolChooser.txt", line 260, in ChallengeProtocolChooser.txt Failed example: print http(r""" POST /%s HTTP/1.1 Content-Type: text/xml; charset="utf-8" <?xml version="1.0"?> <methodCall> <methodName>test_script</methodName> </methodCall> """ % (folder_name), handle_errors=False) Exception raised: Traceback (most recent call last): File "/opt/Zope-2.8.4/lib/python/zope/testing/doctest.py", line 1315, in __run compileflags, 1) in test.globs File "<doctest ChallengeProtocolChooser.txt[62]>", line 1, in ? print http(r""" File "/opt/Zope-2.8.4/lib/python/Testing/ZopeTestCase/zopedoctest/functional.py", line 180, in http debug=not handle_errors, File "/opt/Zope-2.8.4/lib/python/ZPublisher/Test.py", line 193, in publish_module response = publish(request, module_name, after_list, debug=debug) File "/opt/Zope-2.8.4/lib/python/ZPublisher/Publish.py", line 144, in publish sys.exc_info()[2], File "/opt/Zope-2.8.4/lib/python/ZPublisher/Publish.py", line 104, in publish object=request.traverse(path, validated_hook=validated_hook) File "/opt/Zope-2.8.4/lib/python/ZPublisher/BaseRequest.py", line 461, in traverse response.unauthorized() File "/opt/Zope-2.8.4/lib/python/ZPublisher/HTTPResponse.py", line 684, in unauthorized raise Unauthorized, m Unauthorized: <strong>You are not authorized to access this resource.</strong> With Zope-2.7.8 the tests pass just fine. Any idea about the problem ? J. - -- Julien Anguenot | Nuxeo R&D (Paris, France) CPS Platform : http://www.cps-project.org Zope3 / ECM : http://www.z3lab.org mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDaXQHGhoG8MxZ/pIRAkYLAJ4upanns7PRDyYHNgSxHXkJk476IACdFfMy U6mOq7W8VdrXr0EEcCENIoU= =JMU+ -----END PGP SIGNATURE-----

1 0

buildbot failure in Zope trunk 2.4 Linux zc-buildbot
by buildbot＠zope.com 02 Nov '05

02 Nov '05

The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 1295 Blamelist: chrism,efge,fdrake,jim,philikon,srichter BUILD FAILED: failed compile sincerely, -The Buildbot

1 0

Maintenance cycles for Zope 2.X branches
by Andreas Jung 02 Nov '05

02 Nov '05

Hi, because of the fact that we are switching to a time-based release cycle for Zope 2 and Zope 3. I would like to discuss how deal with the maintenance of older branches. My idea is to support branches for one year from now on. Zope 2.7 should be maintained until the end of this year, Zope 2.8 until the release of Zope 2.10 in June 2006, Zope 2.9 until the release of Zope 2.11 in December 2006. In case of severe bugs and security problems we can think of making releases for deprecated Zope versions. We could extend the maintenance period for releases if there are some volunteers to take over the responsibility for older branches (isn't there a maintainer for the Linux 2.0 kernel? :-)) From the maintenance point of view it just a nightmare (and it takes a lot of time) to have an overview over more than two or three branches. What do you think? Andreas

3 2

[Proposal] RFC2396 compatible traversal parameters
by Dieter Maurer 01 Nov '05

01 Nov '05

Title: RFC2396 compatible traversal parameters Version: 1.0 Last-Modified: 2005/10/23 Author: Dieter Maurer <dieter(a)handshake.de> Content-Type: text/x-rst Created: 23-October-2005 Abstract ======== RFC2396 defines the overall uri structure. Hierachical uri schemes have a path component consisting of a sequence of path segments. Each path segment consists of a name and optionally a sequence of parameters separated by ``;``. This proposal describes how Zope's publishing component can be enhanced to support path segment parameters, herein called traversal parameters. Rationale ========= There are some important use cases that require information to be kept across successive requests. The most prominent ones are maintaining the session id as well as skin and language selection. We recently met more special ones: keeping tab activation and information about the authentication domain (for remote login). The currently available solutions store this information in: - the session - a cookie - the URL Session and cookie storage have the disadvantages that they do not play well with the browser's history function and that they can seriously confuse caching (mittigated a bit by appropriate 'vary' cache controls, but not solved). Furthermore, cookies might not be available for security reasons. URL storage does not suffer these disadvantages but currently requires the introduction of artificial path segments for the additional information and difficult traversal magic to prevent the artificial segments from interfering with the traversal process. Traversal parameters can solve this much more naturally than artificial path segments. Zope currently does not support traversal parameters. Usage types =========== Traversal parameters can have two kinds of uses: - controlling the traversal process itself - providing information for the whole request Skin selection belongs for example to the first kind, tab activation to the second one; language selection may belong to either of them. While it seems most natural to attach information for the whole request to the last path segment, it is much more practical to use some path segment further to the front as this information might be used automatically (without explicit URL construction) by relative uri references. Risks ===== Support for traversal parameters controlling the traversal process itself will inevitably require deeper changes in Zope's traversal implementation. As this implementation is already quite complex and supports many use cases, the new extension might break some of them. I will outline the special risks in the solution part. There might be clients not implementing RFC 2396. Such clients might support parameters only at the path end and view everything after the first ``;`` as part of the parameters. Such clients might resolve relative uri references incorrectly in the presence of traversal parameters. Proposed solution ================= The solution modifies Zope's ``ZPublisher.BaseRequest.BaseRequest.traverse``. Currently, the ``path`` argument is split into a sequence of names, maintained reversed in the ``TraversalRequestNameStack``. The solution splits it into a sequence of pairs, consisting of the name and the sequence of parameters. ``TraversalRequestNameStack`` will contain the name only when the parameter sequence is empty but the pair, otherwise. Usually, this will allow traversal magic (modification of ``TraversalRequestNameStack`` to change the traversal process) to continue to work as previously unless it hits a pair when it expects a name only. Such (hopefully rare) cases will break. When the traversal process has located a subobject, it checks whether it has a ``__traversal_parameter_process_hook__``. If so, it calls it with ``request`` and the parameter list as arguments. The method may change the list which will affect the parameters added to the constructed (URL) path segment. The traversal will maintain the parameters for the current step in ``TraversalRequestStepParameterList`` to make them available for ``__bobo_traverse__``. An aware ``__bobo_traverse__`` implementation might change this list affecting the parameters seen in further processing. To support parameters destined to the complete request (rather than individual traversal steps), all found parameters are collected in ``TraversalRequestCollectedParameterList``. Individual steps that want to modify the collected parameters can assign a new list to ``TraversalRequestStepCollectParameterList``. The original value is a reference to ``TraversalRequestStepParameterList``. Thus, if it is changed in place, this other list changes as well. For an application, it is difficult to work with parameter lists. Therefore, ``BaseRequest`` gets the new method ``dictifyTraversalParameters``. It takes a parameter list as argument and returns a parameter dictionary. It performs the same conversions and assemblies as ``ZPublisher.HTTPRequest.HTTPRequest.processInputs``. To avoid code duplication, ``processInputs`` is refactored. After traversal, the request gets a lazy key ``TraversalRequestCollectedParameterDict``. It makes the collected traversal parameters available as a dictionary. ``BaseRequest`` gets a new method ``physicalPathToURL`` (that of ``HTTPRequest`` is modified accordingly). It checks whether an object on the path defines a ``__traversal_parameter_creation_hook__``. If so, it is called with the request as argument and can determine the path segment corresponding to this object. This allows ``absolute_url`` and friends to add request parameters to created URLs. There remain some open questions with respect to virtual hosting. I prefer that the URL parts corresponding to the virtual host cannot be modified by traversal parameters during URL construction. -- Dieter

3 3