Django + Cherokee Web Server

[hcarvalhoalves]

I'm able to configure Cherokee to run my Django project correctly,
using the included wizard. The problem is, if an exception is thrown,
Cherokee just shows a "Unhandled Exception" page. I figured out that
if I run fcgi with debug=true, then I get a stacktrace from Flup, but
I wanted the default Django behaviour (showing debug pages when
DEBUG=TRUE on settings.py), similar to Apache or the development
server.

Anyone knows how to do it?

[Jarek Zgoda]

Wiadomość napisana w dniu 2009-11-27, o godz. 00:31, przez
hcarvalhoalves:

This is not the response from web server, nor Django - this page is
served by Flup. This indicates the error at the stage of loading
Django machinery (eg. some problem with settings.py) and can not be
passed to Django's error handling because Django is simply not yet
loaded or not initialized properly. The only possible way to get any
debugging information is to turn on FastCGI debug.

--
Artificial intelligence stands no chance against natural stupidity

Jarek Zgoda, R&D, Redefine
jarek...@redefine.pl

[hcarvalhoalves]

On Nov 27, 5:56 am, Jarek Zgoda <jarek.zg...@redefine.pl> wrote:
> Wiadomo¶æ napisana w dniu 2009-11-27, o godz. 00:31, przez  

> jarek.zg...@redefine.pl

I understand it's a debug page from Flup, but it shouldn't be: the
exception is not caused by settings or anything, in fact, it's an
IOError exception thrown because my view tries to access some file
that doesn't exist. But with the development server, I get the
stacktrace with Django's debug page for this same case. So I was
wondering why now the exception is going up one layer and getting
caught by Flup instead.

[Jarek Zgoda]

Wiadomość napisana w dniu 2009-11-27, o godz. 17:42, przez

hcarvalhoalves:

>>> I'm able to configure Cherokee to run my Django project correctly,
>>> using the included wizard. The problem is, if an exception is
>>> thrown,
>>> Cherokee just shows a "Unhandled Exception" page. I figured out that
>>> if I run fcgi with debug=true, then I get a stacktrace from Flup,
>>> but
>>> I wanted the default Django behaviour (showing debug pages when
>>> DEBUG=TRUE on settings.py), similar to Apache or the development
>>> server.
>>
>> This is not the response from web server, nor Django - this page is
>> served by Flup. This indicates the error at the stage of loading
>> Django machinery (eg. some problem with settings.py) and can not be
>> passed to Django's error handling because Django is simply not yet
>> loaded or not initialized properly. The only possible way to get any
>> debugging information is to turn on FastCGI debug.
>

> I understand it's a debug page from Flup, but it shouldn't be: the
> exception is not caused by settings or anything, in fact, it's an
> IOError exception thrown because my view tries to access some file
> that doesn't exist. But with the development server, I get the
> stacktrace with Django's debug page for this same case. So I was
> wondering why now the exception is going up one layer and getting
> caught by Flup instead.

This should not look like this. In case of server error, Django calls
the 500 view and acts accordingly to DEBUG setting - either renders
technical 500 response or sends mail. The returned HTTP code in both
cases is 500 and I guess Flup hides it with its own error handling
routine. Anyway, I never encountered such behaviour when working with
nginx and lighttpd and all Django error handling machinery has been
fully loaded - only in cases when Django initialization has been
interrupted.

--
Artificial intelligence stands no chance against natural stupidity

Jarek Zgoda, R&D, Redefine

jarek...@redefine.pl

[Gary D]

one thing I can add is that, is that possibly-- your development and
production environment may not be identical

(going with what Jarek said)

and an error is happening on your production environment that gets
bypassed in the development machine

this has happened to me a few times

GD