Just as an aside, I find this also very annoying and appeal to all
developers to always add a proper explanation when closing tickets.
Also, for bug fixes and features, regression tests and doc/changelog
updates are a must.
> PS: you trac configuration seems very picky about what it considers "a
> potential spam submission" (though I'm aware the project recently
> moved to sourceforge, being able to comment on old tickets is still a
> good thing).
The trac will be closed anyway and made read only. All open tickets have
been moved, a link in the last comment should point to the corresponding
ticket on SourceForge, so you can comment there. For closed tickets,
open a new ticket on SourceForge. We will keep the old Trac so you can
still add a reference to the old ticket. It does not make sense and is
not maintainable to have two open issue trackers.
-- Christoph
> Hi,
>
> Thanks for the quick reply.
> By any chance, do you know why this is necessary?
> That snippet looks like black magic to me and I'd rather have some
> strong technical background on this issue before I change the code on
> our production servers.
>
> I remember seeing a note somewhere on turbogears website saying that
> you may need to "preload" the application in case you use load-
> balancing services and such. It that somehow related to the issue at
> hand? (we don't use any load-balancing on our servers, so I never gave
> any attention to that warning)
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.
Diez