Search This Blog

13 April 2011

using toscawidget behind apache mod_wsgi

Turbogears Ticket #2309

The problem, when it occurred, would be visible when someone clicked the login link (going to /login ). The came_from would, sometimes, be set to "/toscawidgets/resources". When I remove the "modname" parameter from the JSLink above, the problem never occurs.

Quick fix: in the .wsgi script add those 3 lines at the end

import paste.fixture
app=paste.fixture.TestApp(application)
app.get("/") 

Full explanation (copy/paste from Diez Roggish) (http://groups.google.com/group/turbogears/browse_thread/thread/ca4e3fd12a49d44/fa8721260b68741b)

The snippet will in fact force the mod_wsgi-process to pre-load the full application controller hierarchy. As a result, all the tosca-widgets should be instantiated, and their resources registered in the resource-middleware.

The reason this needs to be done is because usually, you run mod_wsgi with several processes. Lets name these P1-P10.

Now if a request hits a freshly started apache (without the "magic lines"), it hits P1. That initial request is directed at a controller action, so the full TG2 app with it's controller hierarchy is bootstrapped. All is nice and easy.

The resulting HTML now contains several references to static resources from TW. So the browser will - in parallel - request these. Because P1 is just finished, it probably won't even getting any of these requests. Instead, the are distributed amongst P2-P10.

And these processes are not bootstrapped yet. So, TW doesn't know about any resources when asked, and the result is a 404 or 500.

And for that reason, the "magic snippet" is there.

It is unfortunate, but I don't see any other way. You could try & have some sort of finalizing method-call into the Pylons/TG2-stack that essentially does the same, but the underlying technology won't be changeable.

No comments:

Post a Comment