I spent a considerable amount of time reading documentation that told me how to send errors to the Apache log filewhen you use mod_wsgi. I read documentation on how to integrate mod_wsgi with Apache and Django. All of this was fine, but when I was trying to get it to work with my Django 1.0.2 installation and Apache2 running mod_wsgi, I was constantly greeted by lots of errors. The documents online didn't help at all.
Finally, after looking into the django.core.handlers.wsgi module, I figured out how to send errors to the wsgi.errors setting and subsequently send errors to your Apache2 Error.log file.
I started off with my views.py as follows:
from django.http import HttpResponse
from django.shortcuts import render_to_response, get_object_or_404
from myapp.models import F
def index(request):
c = {}
return render_to_response('myapp/index.html',c)
def detail(request, name):
n = F.objects.get(name=name)
c = {'name': n.fof}
return render_to_response('myapp/detail.html',c) If I needed to write to the Error.log file, I would have to change the code thusly:
from django.http import HttpResponse
from django.shortcuts import render_to_response, get_object_or_404
from myapp.models import F
def index(request):
c = {}
print >> request.environ['wsgi.errors'],"Teh Errorist!"
return render_to_response('myapp/index.html',c)
def detail(request, name):
n = F.objects.get(name=name)
c = {'name': n.fof}
return render_to_response('myapp/detail.html',c) The change is in line 7
I felt really stupid, because the solution was so straightforward. I felt even more stupid that I couldn't find any documentation out there. Either way, I'm pleased that my app works, and in case someone else out there is searching for how to achieve this, then the above is how to do it.
4 comments:
Or you could have used:
import sys
print >> sys.stderr, "message"
That still should have ended up in an Apache error log. Depending on your Apache configuration however, it may end up in the main Apache error log and not the virtual host error log.
So, if you were only looking in the virtual host error log, you may not have seen it.
Herro!
Thanks for stopping by and thanks for the tip. I'm quite honored that you'd leave a comment here.
I fully understand that you could write to sys.stderr. As you correctly point out, I run the application in a virtual host that had its own logfiles. I was quite keen in following the line in the "Debugging Techniques" section of the mod_wsgi project page.
--QUOTE--
In general, a WSGI application should always endeavour to only log messages via the 'wsgi.errors' object that is passed through to a WSGI application in the WSGI environment.
--QUOTE--
Thanks again.
There is a difference though between WSGI applications, ie., where WSGI is a major pillar used right through the architecture, and where it can only be hosted on WSGI, and frameworks which can host on WSGI but are not bound to it and can operate on top of other web hosting mechanisms directly, like mod_python and fastcgi. For the latter, I wouldn't blame them if they don't give access to wsgi.errors. Django is a case in point, it is a user of WSGI rather than being built with WSGI.
I couldn't agree with you more. Not everyone sees the merits of mod_wsgi and the possibility of writing really good apps for it. The Django framework makes use of mod-wsgi, as always, to couple two components together. I think there is not a whole lot of information regarding this and it seems like one needs to follow a long process of trial/error and discovery just to get things working. Coming from a security background, the restricted stdout, IMHO, is excellent, and funneling messages through the proper logging mechanisms is the way to go. These things are, however, appreciated by very few and on rare occasions; mainly because they become a hinderance to development. One of the reasons I wanted wsgi.errors to handle my messages was so that the system works the way it should. Thanks again for your responses. They are much appreciated.
Post a Comment