Jogging also implements a lot of the ideas from Simon's logging proposal, and can do what you're saying:
http://github.com/zain/jogging/ On Wed, May 5, 2010 at 12:33 PM, Mike Axiak <mcax...@gmail.com> wrote: > Why does this facility need to exist within Django? At least one > person [1] has written a middleware to do what you're saying. If it's > that important, people will start to use that app. There are certainly > many potential features people want out of logging, so it'd definitely > be better suited for an external app to bake. > > I'd say that the main issue here isn't with lack of logging, but with > lack of a good one-stop Django app repository (DjangoZen [2] is a > start, but missing a lot of functionality). Unfortunately I don't have > time to maintain something like that. > > Cheers, > Mike > > 1: http://github.com/djangrrl/django-logging-middleware > 2: http://djangozen.com/ > > On Wed, May 5, 2010 at 2:53 PM, Kevin Howerton <kevin.hower...@gmail.com> > wrote: > > Yeah... not sure, though thank you for actually reading and responding > > to my post. > > > > "I think the problem you are having is more related to mod_wsgi, and > > possible differences between it and mod_python, than Django." > > > > Absolutely. Though, I'm not sure if it's the official recommendation > > of django-project.com now or not, but most people in the community are > > using mod_wsgi in Daemon mode. It is definitely a result of this, > > also I doubt mod_wsgi is going to be changing the nature of their > > exception handling code faster than you guys can keep up. It seems > > like a pretty sweet setup right now so hopefully they don't change it > > ;) > > > > Where django pulls a 500 it should call these two lines, which will > > dump the exception raised to stderr. > > > > type, value, traceback = sys.exc_info() > > sys.excepthook(type, value, traceback) > > > > If you have a logger setup, which I assume most sane people in > > production do (right?!?). You can pass the exception info to the > > logger with and have the same result as one that passes straight to > > stderr only you can have more explicit control over how it behaves, > > especially if django uses named loggers: > > > > logger.error("This can't be good", exc_info=True) > > > > We don't really need both, but either one should exist in django if > > it's going to support wsgi ;) Perhaps, I'm missing some config > > setting available to mod_wsgi that will replicate mod_python's > > behavior in this regard, but i "feel" django should work with a > > default setup. > > > > Also, I've tested this on both Fedora 8, and mod_wsgi 2.x ... and the > > latest 2.6.5 python + wsgi 3.2. > > > > "http://docs.djangoproject.com/en/dev/howto/error-reporting/"; > > > > I can't use email reporting because of performance, logistics, and > > sheer volume in production. > > > > -k > > > > > > On Wed, May 5, 2010 at 1:51 PM, Karen Tracey <kmtra...@gmail.com> wrote: > >> On Wed, May 5, 2010 at 12:46 PM, Kevin Howerton < > kevin.hower...@gmail.com> > >> wrote: > >>> > >>> What I was suggesting in my post though, was that we alter the default > >>> CRITICAL error handling behavior ... as it stands (by default) all of > >>> my ERRORs are being suppressed in production. This is pretty > >>> confusing for new users (there were 3 others in IRC with the same > >>> complaint yesterday), and pretty un-pythonic IMO. Unless I missed > >>> something? > >> > >> I think you are missing something. From your earlier note you seem to be > >> saying that it is information your own code is writing to stderr that is > >> getting lost somewhere. Django does nothing to suppress anything sent do > >> stderr. I've got views that write to stderr running under mod_wsgi, and > the > >> stderr output appears in the configured Apache error log. You do need to > >> either include a newline in the data or explicitly flush stderr for the > data > >> to be written, and that may be a difference from mod_python (I don't > >> remember enough about mod_python to say one way or the other). I think > the > >> problem you are having is more related to mod_wsgi, and possible > differences > >> between it and mod_python, than Django. > >> > >>> > >>> At minimum the documentation should inform the user of this > >>> short-coming, and provide a link to a wiki with the available > >>> work-arounds. > >> > >> It isn't clear to me what shortcoming you think should be documented. If > it > >> is the behavior of mod_wsgi with respect to stderr possibly the > deployment > >> docs for mod_wsgi could mention something, but one danger of Django > putting > >> information like this in the docs is that it gets out of date as > mod_wsgi > >> evolves. In general it seems better to provide a minimum amount of > >> information in Django doc, stuff that is specific to Django, and point > the > >> user to the appropriate source for authoritative documentation on the > >> 3rd-party package. > >> > >> For the record, Django's default handling of critical errors when DEBUG > is > >> False is fully documented: > >> > >> http://docs.djangoproject.com/en/dev/howto/error-reporting/ > >> > >> Karen > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "Django developers" group. > >> To post to this group, send email to django-developers@googlegroups.com > . > >> To unsubscribe from this group, send email to > >> django-developers+unsubscr...@googlegroups.com<django-developers%2bunsubscr...@googlegroups.com> > . > >> For more options, visit this group at > >> http://groups.google.com/group/django-developers?hl=en. > >> > > > > -- > > You received this message because you are subscribed to the Google Groups > "Django developers" group. > > To post to this group, send email to django-develop...@googlegroups.com. > > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com<django-developers%2bunsubscr...@googlegroups.com> > . > > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > > > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com<django-developers%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
