Hi all, I've been running a test-setup using ZPublisher/WSGIPublisher.py mongrel2 -> wsgid -> zope2 I'm running into some minor, some larger issues. Most importantly, transactions are not committed. You know better than I do what that means. For me, I can't create Plone sites, or even DTMLDocuments. And when I create then using ZServer, I can't delete them any more through the wsgi route. I have a small patch against WSGIPublisher.py (branch 2.13) that fixes above behaviour (attached). After applying it creating and deleting content works ok, but when using the sunburst theme, the created site looks completely unstyled, whereas using the classic plone theme everything looks much better. The plot thickens however because when I enable debug-mode, everything works great! Maybe someone with better understanding of the mechanics involved now has an epiphany. FYI, I'm using the following buildout: https://github.com/pjstevns/plone.mongrel2 thanks. -- ________________________________________________________________ Paul J Stevens pjstevns @ gmail, twitter, skype, linkedin * Premium Hosting Services and Web Application Consultancy * www.nfg.nl/info@nfg.nl/+31.85.877.99.97 ________________________________________________________________
On Wed, Jun 6, 2012 at 5:06 PM, Paul J Stevens <paul@nfg.nl> wrote:
FYI, I'm using the following buildout:
You are missing some required middleware for the current un-documented WSGI feature. I made an experiment quite a while back and came up with: https://github.com/hannosch/zope2-wsgi/blob/master/templates/zope.ini I've looked into WSGI again at the Plone Symposium East sprint and I think we should remove the middleware approach again for Zope2. Primarily as we loose some features like publisher events and exception views, which in practice are used by Plone. There's a reason why Pyramid came up with the tweens concept and I think there's little benefit for existing Zope2 applications to be split up into middleware. Since the repoze project itself isn't moving forward any longer, there's little benefit in code re-use with it either. So I'd probably just merge back the exception and transaction handling into the Zope2 WSGI publisher (keeping some of the code cleanup). Hanno
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/06/2012 12:11 PM, Hanno Schlichting wrote:
On Wed, Jun 6, 2012 at 5:06 PM, Paul J Stevens <paul@nfg.nl> wrote:
FYI, I'm using the following buildout:
You are missing some required middleware for the current un-documented WSGI feature. I made an experiment quite a while back and came up with:
https://github.com/hannosch/zope2-wsgi/blob/master/templates/zope.ini
I've looked into WSGI again at the Plone Symposium East sprint and I think we should remove the middleware approach again for Zope2. Primarily as we loose some features like publisher events and exception views, which in practice are used by Plone. There's a reason why Pyramid came up with the tweens concept and I think there's little benefit for existing Zope2 applications to be split up into middleware. Since the repoze project itself isn't moving forward any longer, there's little benefit in code re-use with it either.
I don't think that is a reasonable characterizaztion: repoze.tm2, repoze.vhm etc. are stable and mature, but they aren't unmaintained: for instance, they actually support Python 3.2. Many he repoze.* packages are in heavy production use for many non-Zope applications.
So I'd probably just merge back the exception and transaction handling into the Zope2 WSGI publisher (keeping some of the code cleanup).
That could still be a reasonable choice. Another choice would be to just add an integration point into the publisher which wrapped the middleware in at startup time, without requiring explicit configuration. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/PjgUACgkQ+gerLs4ltQ7q0gCgyrITqGyH72+y7q/sgIRoeIAc KJAAn3bSQY6iAErXAmjursPgTzuhoJzF =typz -----END PGP SIGNATURE-----
On Wed, Jun 6, 2012 at 7:06 PM, Tres Seaver <tseaver@palladion.com> wrote:
On 06/06/2012 12:11 PM, Hanno Schlichting wrote:
I've looked into WSGI again at the Plone Symposium East sprint and I think we should remove the middleware approach again for Zope2. Primarily as we loose some features like publisher events and exception views, which in practice are used by Plone.
[snip my subjective view on repoze project]
So I'd probably just merge back the exception and transaction handling into the Zope2 WSGI publisher (keeping some of the code cleanup).
That could still be a reasonable choice. Another choice would be to just add an integration point into the publisher which wrapped the middleware in at startup time, without requiring explicit configuration.
As I said above, my main concern is keeping publisher events and exception views intact. Some of these events need to happen in code that's currently inside repoze.* middleware. Like "before transaction commit", "publication failure" or "publication success". For exception handling Plone wants to load some settings from inside the database. Mangling those into a WSGI environment is a bit tedious - having a real Zope request/response object makes that a bit easier. Hanno
Am 06.06.2012 um 19:58 schrieb Hanno Schlichting: […]
As I said above, my main concern is keeping publisher events and exception views intact. Some of these events need to happen in code that's currently inside repoze.* middleware. Like "before transaction commit", "publication failure" or "publication success". […]
+1 to re-add these events. In our WSGI projects it hurts that they are gone now. Yours sincerely, -- Michael Howitz · mh@gocept.com · software developer gocept gmbh & co. kg · Forsterstraße 29 · 06112 Halle (Saale) · Germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Python, Pyramid, Plone, Zope - consulting, development, hosting, operations
On 7 June 2012 07:20, Michael Howitz <mh@gocept.com> wrote:
Am 06.06.2012 um 19:58 schrieb Hanno Schlichting: […]
As I said above, my main concern is keeping publisher events and exception views intact. Some of these events need to happen in code that's currently inside repoze.* middleware. Like "before transaction commit", "publication failure" or "publication success". […]
+1 to re-add these events. In our WSGI projects it hurts that they are gone now.
There was a thread on this a while ago, and I did some in-depth research on the current state of WSGI publishers. See http://old.nabble.com/Zope-2-WSGI-investigation-to33063118.html#a33063118. Summary: use infrae.wsgi for now. Martin
On 7 June 2012 07:20, Michael Howitz <mh@gocept.com> wrote:
Am 06.06.2012 um 19:58 schrieb Hanno Schlichting: […]
As I said above, my main concern is keeping publisher events and exception views intact. Some of these events need to happen in code that's currently inside repoze.* middleware. Like "before transaction commit", "publication failure" or "publication success". […]
+1 to re-add these events. In our WSGI projects it hurts that they are gone now.
There was a thread on this a while ago, and I did some in-depth research on the current state of WSGI publishers. See http://old.nabble.com/Zope-2-WSGI-investigation-to33063118.html#a33063118. Summary: use infrae.wsgi for now. Martin
Am 08.06.2012 um 00:15 schrieb Martin Aspeli: […]
There was a thread on this a while ago, and I did some in-depth research on the current state of WSGI publishers.
See http://old.nabble.com/Zope-2-WSGI-investigation-to33063118.html#a33063118. Summary: use infrae.wsgi for now.
Thank you for the link and the investigation you did. After reading it I'm not sure that infra.wsgi is a good answer for the problem: it seems to have its own problems. But I'll give it a try in our projects to get the publication events back. Yours sincerely, -- Michael Howitz · mh@gocept.com · software developer gocept gmbh & co. kg · Forsterstraße 29 · 06112 Halle (Saale) · Germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Python, Pyramid, Plone, Zope - consulting, development, hosting, operations
Martin Aspeli <optilude+lists@gmail.com> writes:
On 7 June 2012 07:20, Michael Howitz <mh@gocept.com> wrote:
Am 06.06.2012 um 19:58 schrieb Hanno Schlichting: […]
As I said above, my main concern is keeping publisher events and exception views intact. Some of these events need to happen in code that's currently inside repoze.* middleware. Like "before transaction commit", "publication failure" or "publication success". […]
+1 to re-add these events. In our WSGI projects it hurts that they are gone now.
There was a thread on this a while ago, and I did some in-depth research on the current state of WSGI publishers.
See http://old.nabble.com/Zope-2-WSGI-investigation-to33063118.html#a33063118. Summary: use infrae.wsgi for now.
FYI, while working on the Plone WebPI installer, I tried both infrae.wsgi and the Zope2 WSGI publisher. I couldn't get infrae.wsgi to work for a few different reasons: https://github.com/plone/Installers-UnifiedInstaller/commit/be495bb5e0a71137... Fix problem with hanging requests and orphaned python processes. Opening ZMI or the `@@plone-addsite` view worked fine, but a vanilla Plone site would cause the browser to start getting a response but it never finished and the Python FCGI process would be orphaned from IIS. Switching back to the Zope2 WSGI server I found that Diazo themeing seems to work just fine anyways so I don't think we need it. So the Zope2 WSGI publisher works for plone.app.themeing when I was told that it wouldn't work without events. *Shrug* Ross
Hanno Schlichting <hanno@hannosch.eu> writes:
On Wed, Jun 6, 2012 at 5:06 PM, Paul J Stevens <paul@nfg.nl> wrote:
FYI, I'm using the following buildout:
You are missing some required middleware for the current un-documented WSGI feature. I made an experiment quite a while back and came up with:
https://github.com/hannosch/zope2-wsgi/blob/master/templates/zope.ini
I've looked into WSGI again at the Plone Symposium East sprint and I think we should remove the middleware approach again for Zope2. Primarily as we loose some features like publisher events and exception views, which in practice are used by Plone. There's a reason why Pyramid came up with the tweens concept and I think there's little benefit for existing Zope2 applications to be split up into middleware. Since the repoze project itself isn't moving forward any longer, there's little benefit in code re-use with it either.
So I'd probably just merge back the exception and transaction handling into the Zope2 WSGI publisher (keeping some of the code cleanup).
+10. If there's anything I can do to help with this, I'd like to do so. I could start by just trying to copy the bits from the non-WSGI publisher back into the WSGI publisher. But I don't really know enough about the edge cases to write useful tests. Hanno, would that help or is this the kind of thing that you already have a clear notion of in your head and contributions won't really help? Ross
participants (6)
-
Hanno Schlichting -
Martin Aspeli -
Michael Howitz -
Paul J Stevens -
Ross Patterson -
Tres Seaver