Last 7 days

• Dec 23, 2009

  Overview (A very brief overview of django-logging.) Wiki page commented on by jim.hefferon   -   Can I ask if it is possible to log a unique id for each request? Sometimes tracking requests to nail down a reported bug can be very hard in a big log.

  Can I ask if it is possible to log a unique id for each request? Sometimes tracking requests to nail down a reported bug can be very hard in a big log.

Last 30 days

• Dec 01, 2009

  issue 47 (Logging breaks text/html content server via django.views.sta...) reported by reavis.sutphin.gray   -   What steps will reproduce the problem? 1. Configure and enable django-logging 2. Configure some url to return text/html content via django.views.static.serve i.e. html files required by FCKeditor 3. Request text/html content. What is the expected output? What do you see instead? The entire content of the static html file. django-logging adds styles and content to the html file. The static serve view sets the Content-Length header to the length of the original content, so the browser truncates the file. What version of the product are you using? On what operating system? trunk r42. OS X 10.5.8 Please provide any additional information below. I have included a patch that adds a new middleware class modeled after the SuppressLoggingOnAjaxRequestsMiddleware. I think it might be cleaner to implement this in LoggingMiddleware using a setting (see this middleware class from djangoflash for an example of that approach http://github.com/danielfm/django-flash/blob/master/src/djangoflash/middleware.py).

  What steps will reproduce the problem? 1. Configure and enable django-logging 2. Configure some url to return text/html content via django.views.static.serve i.e. html files required by FCKeditor 3. Request text/html content. What is the expected output? What do you see instead? The entire content of the static html file. django-logging adds styles and content to the html file. The static serve view sets the Content-Length header to the length of the original content, so the browser truncates the file. What version of the product are you using? On what operating system? trunk r42. OS X 10.5.8 Please provide any additional information below. I have included a patch that adds a new middleware class modeled after the SuppressLoggingOnAjaxRequestsMiddleware. I think it might be cleaner to implement this in LoggingMiddleware using a setting (see this middleware class from djangoflash for an example of that approach http://github.com/danielfm/django-flash/blob/master/src/djangoflash/middleware.py).

Earlier this year

• Nov 27, 2009

  issue 46 (Code display on log messages always shows the wrong code) commented on by IanKRolfe   -   Had a dig around at lunchtime and it appears the proper solution is to use os.path.normcase() around the os.path.realpath calls. On Unix & Mac, it does nothing, but on Windows it lowercases the supplied path, which would be the correct solution. So I'd propose the following change to get_meaningful_frame(): : _django_path = os.path.normcase(os.path.realpath(os.path.dirname(django.__file__))) _admin_path = os.path.normcase(os.path.realpath(os.path.dirname(admin.__file__))) _logging_path = os.path.normcase(os.path.realpath(os.path.dirname(logging.__file__))) _djangologging_path = os.path.normcase(os.path.realpath(os.path.dirname(__file__))) def get_meaningful_frame(): """ Try to find the meaningful frame, rather than just using one from the innards of the Django or logging code. """ frame = inspect.currentframe().f_back while frame.f_back: filename = os.path.normcase(os.path.realpath(frame.f_code.co_filename)) if not (filename.startswith(_django_path) or \ filename.startswith(_logging_path) or \ filename.startswith(_djangologging_path)) or \ filename.startswith(_admin_path): break frame = frame.f_back return frame :

  Had a dig around at lunchtime and it appears the proper solution is to use os.path.normcase() around the os.path.realpath calls. On Unix & Mac, it does nothing, but on Windows it lowercases the supplied path, which would be the correct solution. So I'd propose the following change to get_meaningful_frame(): : _django_path = os.path.normcase(os.path.realpath(os.path.dirname(django.__file__))) _admin_path = os.path.normcase(os.path.realpath(os.path.dirname(admin.__file__))) _logging_path = os.path.normcase(os.path.realpath(os.path.dirname(logging.__file__))) _djangologging_path = os.path.normcase(os.path.realpath(os.path.dirname(__file__))) def get_meaningful_frame(): """ Try to find the meaningful frame, rather than just using one from the innards of the Django or logging code. """ frame = inspect.currentframe().f_back while frame.f_back: filename = os.path.normcase(os.path.realpath(frame.f_code.co_filename)) if not (filename.startswith(_django_path) or \ filename.startswith(_logging_path) or \ filename.startswith(_djangologging_path)) or \ filename.startswith(_admin_path): break frame = frame.f_back return frame :
• Nov 27, 2009

  issue 46 (Code display on log messages always shows the wrong code) commented on by IanKRolfe   -   Supplemental: This is on Windows. I inserted some diagnostics in middleware.py function get_meaningful_frame() and it appears to be because os.path.realpath doesn't return the actual letter case of the 'realpath' consistantly: I modified the code as such: def get_meaningful_frame(): """ Try to find the meaningful frame, rather than just using one from the innards of the Django or logging code. """ tempfile=open('c:/LOG.TXT','w') tempfile.write('\n---------------------------\n') tempfile.write('django_path=%s\n'%(_django_path)) tempfile.write('admin_path=%s\n'%(_admin_path)) tempfile.write('logging_path=%s\n'%(_logging_path)) tempfile.write('djangologging_path=%s\n'%(_djangologging_path)) frame = inspect.currentframe().f_back while frame.f_back: filename = os.path.realpath(frame.f_code.co_filename) tempfile.write('test filename=%s\n'%(filename)) if not (filename.startswith(_django_path) or \ filename.startswith(_logging_path) or \ filename.startswith(_djangologging_path)) or \ filename.startswith(_admin_path): tempfile.write('**break**\n') break frame = frame.f_back tempfile.write('chosen frame=%s\n'%(frame.f_code.co_filename)) tempfile.close() return frame The output was: C:\>type LOG.TXT --------------------------- django_path=C:\Program Files\Apache Software Foundation\Apache2.2\bin\python\lib\site-packages\django admin_path=C:\Program Files\Apache Software Foundation\Apache2.2\bin\python\lib\site-packages\django\contrib\admin logging_path=C:\Program Files\Apache Software Foundation\Apache2.2\bin\python\Lib\logging djangologging_path=C:\Program Files\Apache Software Foundation\Apache2.2\bin\python\lib\site-packages\djangologging test filename=C:\Program Files\Apache Software Foundation\Apache2.2\bin\python\lib\site-packages\djangologging\middleware.py test filename=C:\Program Files\Apache Software Foundation\Apache2.2\bin\python\lib\logging\__init__.py **break** chosen frame=C:\Program Files\Apache Software Foundation\Apache2.2\bin\python\lib\logging\__init__.py Note that the python 'Lib' directory is uppercase in _logging_path but not in the others (it's upper case in the actual directory!) This sort of thing makes me wish I was developing on Linux and not Windows, but I have no chance of changing corporate policy at the moment. Adding '.lower()' after all the calls to os.path.realpath makes it work, but this only works on OS's that are case insensitive, and is therefore not a real fix for the problem. Any better ideas?

  Supplemental: This is on Windows. I inserted some diagnostics in middleware.py function get_meaningful_frame() and it appears to be because os.path.realpath doesn't return the actual letter case of the 'realpath' consistantly: I modified the code as such: def get_meaningful_frame(): """ Try to find the meaningful frame, rather than just using one from the innards of the Django or logging code. """ tempfile=open('c:/LOG.TXT','w') tempfile.write('\n---------------------------\n') tempfile.write('django_path=%s\n'%(_django_path)) tempfile.write('admin_path=%s\n'%(_admin_path)) tempfile.write('logging_path=%s\n'%(_logging_path)) tempfile.write('djangologging_path=%s\n'%(_djangologging_path)) frame = inspect.currentframe().f_back while frame.f_back: filename = os.path.realpath(frame.f_code.co_filename) tempfile.write('test filename=%s\n'%(filename)) if not (filename.startswith(_django_path) or \ filename.startswith(_logging_path) or \ filename.startswith(_djangologging_path)) or \ filename.startswith(_admin_path): tempfile.write('**break**\n') break frame = frame.f_back tempfile.write('chosen frame=%s\n'%(frame.f_code.co_filename)) tempfile.close() return frame The output was: C:\>type LOG.TXT --------------------------- django_path=C:\Program Files\Apache Software Foundation\Apache2.2\bin\python\lib\site-packages\django admin_path=C:\Program Files\Apache Software Foundation\Apache2.2\bin\python\lib\site-packages\django\contrib\admin logging_path=C:\Program Files\Apache Software Foundation\Apache2.2\bin\python\Lib\logging djangologging_path=C:\Program Files\Apache Software Foundation\Apache2.2\bin\python\lib\site-packages\djangologging test filename=C:\Program Files\Apache Software Foundation\Apache2.2\bin\python\lib\site-packages\djangologging\middleware.py test filename=C:\Program Files\Apache Software Foundation\Apache2.2\bin\python\lib\logging\__init__.py **break** chosen frame=C:\Program Files\Apache Software Foundation\Apache2.2\bin\python\lib\logging\__init__.py Note that the python 'Lib' directory is uppercase in _logging_path but not in the others (it's upper case in the actual directory!) This sort of thing makes me wish I was developing on Linux and not Windows, but I have no chance of changing corporate policy at the moment. Adding '.lower()' after all the calls to os.path.realpath makes it work, but this only works on OS's that are case insensitive, and is therefore not a real fix for the problem. Any better ideas?
• Nov 27, 2009

  issue 46 (Code display on log messages always shows the wrong code) reported by IanKRolfe   -   What steps will reproduce the problem? 1. Log messages to the logger 2. Click on the link next to the message that shows where the code is from 3. Always displays this code: 1 else: 2 fn, lno, func = "(unknown file)", 0, "(unknown function)" 3 if exc_info: 4 if type(exc_info) != types.TupleType: 5 exc_info = sys.exc_info() 6 record = self.makeRecord(self.name, level, fn, lno, msg, args, exc_info, func, extra) 7 self.handle(record) 8 What is the expected output? What do you see instead? I would expect to see the code that is surrounding the call to the logger - it appears to be showing code from inside the logger module (i.e. 1 call too deep!) What version of the product are you using? On what operating system? SVN version, doing an "SVN UPDATE" doesn't seem to fix it. Please provide any additional information below. I did think it might be a problem with my Django config. Here is the middleware section: MIDDLEWARE_CLASSES = ( 'django.middleware.common.CommonMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'djangologging.middleware.LoggingMiddleware', 'oup.django.custom_auth_backend.SettingsBackend', ) LOGGING_INTERCEPT_REDIRECTS = True Is this in the right place? Moving the django logging line to after our custom middleware (oup.django.---) makes no difference as far as I can see.

  What steps will reproduce the problem? 1. Log messages to the logger 2. Click on the link next to the message that shows where the code is from 3. Always displays this code: 1 else: 2 fn, lno, func = "(unknown file)", 0, "(unknown function)" 3 if exc_info: 4 if type(exc_info) != types.TupleType: 5 exc_info = sys.exc_info() 6 record = self.makeRecord(self.name, level, fn, lno, msg, args, exc_info, func, extra) 7 self.handle(record) 8 What is the expected output? What do you see instead? I would expect to see the code that is surrounding the call to the logger - it appears to be showing code from inside the logger module (i.e. 1 call too deep!) What version of the product are you using? On what operating system? SVN version, doing an "SVN UPDATE" doesn't seem to fix it. Please provide any additional information below. I did think it might be a problem with my Django config. Here is the middleware section: MIDDLEWARE_CLASSES = ( 'django.middleware.common.CommonMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'djangologging.middleware.LoggingMiddleware', 'oup.django.custom_auth_backend.SettingsBackend', ) LOGGING_INTERCEPT_REDIRECTS = True Is this in the right place? Moving the django logging line to after our custom middleware (oup.django.---) makes no difference as far as I can see.
• Nov 14, 2009

  issue 44 (Capturing post data automagically) commented on by olivergeorge   -   Thanks Mike

  Thanks Mike
• Nov 13, 2009

  issue 44 (Capturing post data automagically) commented on by mik...@thelazy.net   -   oh, and you should consider unique filename for each file, to avoid multitasking problems (thread 1 opens file, thread 2 opens file, thread 1 writes to file, thread 2 writes to file, overwriting from thread 1). Not sure if two files opened in append will handle that correctly or not. Maybe have logfile_date_time_url_ip.log or similar.

  oh, and you should consider unique filename for each file, to avoid multitasking problems (thread 1 opens file, thread 2 opens file, thread 1 writes to file, thread 2 writes to file, overwriting from thread 1). Not sure if two files opened in append will handle that correctly or not. Maybe have logfile_date_time_url_ip.log or similar.
• Nov 13, 2009

  issue 44 (Capturing post data automagically) commented on by mik...@thelazy.net   -   Look at http://docs.djangoproject.com/en/dev/topics/http/middleware/#writing-your-own- middleware It should just be to define process_request, grab request.POST, serialize or prettyprint, and dump it to a file together with other relevant info (time, user maybe, ip, tings like that). check documentation for request objects at http://docs.djangoproject.com/en/dev/ref/request-response/#httprequest-objects for what info it have stored

  Look at http://docs.djangoproject.com/en/dev/topics/http/middleware/#writing-your-own- middleware It should just be to define process_request, grab request.POST, serialize or prettyprint, and dump it to a file together with other relevant info (time, user maybe, ip, tings like that). check documentation for request objects at http://docs.djangoproject.com/en/dev/ref/request-response/#httprequest-objects for what info it have stored
• Nov 12, 2009

  issue 44 (Capturing post data automagically) commented on by olivergeorge   -   You probably know way more about this than me but I'm surprised. Any particular reason? Perhaps because it's logging for a different purpose (disaster recovery) rather than performance monitoring?

  You probably know way more about this than me but I'm surprised. Any particular reason? Perhaps because it's logging for a different purpose (disaster recovery) rather than performance monitoring?
• Nov 12, 2009

  issue 44 (Capturing post data automagically) commented on by mik...@thelazy.net   -   That sounds like a job for a seperate middleware

  That sounds like a job for a seperate middleware
• Nov 12, 2009

  issue 45 (Cookie doesn't save with path) reported by mik...@thelazy.net   -   The javascript function currently doesn't give a path, which means that it gets the path of the current url. Example: Lets say you have web path /a/b/c/d/ You first visit / and set INFO and higher as visible. All good, it works for all the paths. You go to /a/b/c/ and change it to All visible. This will now be all visible for /a/b/c/ and /a/b/c/d/ but only info for /, /a/ and /a/b/ - which is probably not what you wanted. To store the settings for all pages, the JS cookie function in logging.html should be like this: function writeCookie(key, value) { document.cookie = key + '=' + escape(value) + "; path=/"; }

  The javascript function currently doesn't give a path, which means that it gets the path of the current url. Example: Lets say you have web path /a/b/c/d/ You first visit / and set INFO and higher as visible. All good, it works for all the paths. You go to /a/b/c/ and change it to All visible. This will now be all visible for /a/b/c/ and /a/b/c/d/ but only info for /, /a/ and /a/b/ - which is probably not what you wanted. To store the settings for all pages, the JS cookie function in logging.html should be like this: function writeCookie(key, value) { document.cookie = key + '=' + escape(value) + "; path=/"; }
• Nov 11, 2009

  issue 44 (Capturing post data automagically) reported by olivergeorge   -   I'm looking for a nice simple way to store all POST data in a log file. The main reason being it'd be a handy insurance policy for cases where a user claims to have submitted data which doesn't appear in the database. It seems like this is something django-logging could easily be extended do but I don't see any code for this yet.

  I'm looking for a nice simple way to store all POST data in a log file. The main reason being it'd be a handy insurance policy for cases where a user claims to have submitted data which doesn't appear in the database. It seems like this is something django-logging could easily be extended do but I don't see any code for this yet.
• Nov 11, 2009

  issue 43 (Enable / disable bar based on logged in user) commented on by mik...@thelazy.net   -   New patch. Two differences: 1. There was some indentation issue in the original patch 2. It now checks if request have session. If not, urls without trailing "/" would fail

  New patch. Two differences: 1. There was some indentation issue in the original patch 2. It now checks if request have session. If not, urls without trailing "/" would fail
• Nov 11, 2009

  issue 43 (Enable / disable bar based on logged in user) commented on by mik...@thelazy.net   -   Created a small patch for it. Done some small testing, and seem to work. Either ip have to be specified in INTERNAL_IPS or username in INTERNAL_USERS. The code does not require that INTERNAL_USERS is specified in settings.py

  Created a small patch for it. Done some small testing, and seem to work. Either ip have to be specified in INTERNAL_IPS or username in INTERNAL_USERS. The code does not require that INTERNAL_USERS is specified in settings.py
• Nov 11, 2009

  issue 43 (Enable / disable bar based on logged in user) reported by mik...@thelazy.net   -   Would be nice if the bar could be set to display or not based on username instead of IP adresses. Right now we have several people (me included) connected to the internet via a NAT ip, and as such the debug bar shows for everyone on my test server, which is not ideal. Further, I have a laptop with dynamic ip (dialup thing), which makes the bar useless. It would be MUCH better to key it to specific users instead of ip's :)

  Would be nice if the bar could be set to display or not based on username instead of IP adresses. Right now we have several people (me included) connected to the internet via a NAT ip, and as such the debug bar shows for everyone on my test server, which is not ideal. Further, I have a laptop with dynamic ip (dialup thing), which makes the bar useless. It would be MUCH better to key it to specific users instead of ip's :)
• Nov 09, 2009

  issue 36 (Ignore cannot-find-source IOErrors from inspect.getsourcelin...) commented on by modfilms   -   This didn't work for me but I was getting IndexError from the same line I included that error in the excecption handling as per attached patch and it _sees_ to be ok.

  This didn't work for me but I was getting IndexError from the same line I included that error in the excecption handling as per attached patch and it _sees_ to be ok.
• Nov 05, 2009

  Overview (A very brief overview of django-logging.) Wiki page commented on by matuspo   -   Hi all...i just replaced my new django project from development to real life...but after few minutes server get stuck...i realized, that because we put it on 4 years used domain name. and i think, many known urls were requested to this server, but now they just don't exists. i think, this logging started to store all those 404 errors into database.and it killed him. could it be, that django logging is not good for projects placed in real life(for deployment)??? just for development and debugging? thank you

  Hi all...i just replaced my new django project from development to real life...but after few minutes server get stuck...i realized, that because we put it on 4 years used domain name. and i think, many known urls were requested to this server, but now they just don't exists. i think, this logging started to store all those 404 errors into database.and it killed him. could it be, that django logging is not good for projects placed in real life(for deployment)??? just for development and debugging? thank you
• Oct 09, 2009

  issue 30 (Add a simply setup.py) commented on by cfkarsten   -   -e hg+http://bitbucket.org/refack/djangologging/#egg=djangologging ianbicking: I want you to have a drink on me every time I post "Successfully installed"

  -e hg+http://bitbucket.org/refack/djangologging/#egg=djangologging ianbicking: I want you to have a drink on me every time I post "Successfully installed"
• Oct 08, 2009

  Overview (A very brief overview of django-logging.) Wiki page commented on by moman...@google.com   -   This library has saved me *hours* of troubleshooting already. I love it!

  This library has saved me *hours* of troubleshooting already. I love it!
• Sep 16, 2009

  Overview (A very brief overview of django-logging.) Wiki page commented on by bonya1980   -   I've just installed djangologging and it works really cool! Thank for the usefull tool :)

  I've just installed djangologging and it works really cool! Thank for the usefull tool :)
• Sep 07, 2009

  issue 42 (Error when using HttpResponse iterator) reported by benjaoming   -   What steps will reproduce the problem? 1. Use yield "some string" inside a view function, so it becomes an iterator 2. An exception occurs What is the expected output? What do you see instead? I would expect Django Logging to wait until no more is yielded from the view function - OR - not to do any logging, since it might not be possible. Please provide any additional information below. Traceback (most recent call last): File "/usr/local/lib/python2.6/dist-packages/django/core/servers/basehttp.py", line 278, in run self.result = application(self.environ, self.start_response) File "/usr/local/lib/python2.6/dist-packages/django/core/servers/basehttp.py", line 636, in __call__ return self.application(environ, start_response) File "/usr/local/lib/python2.6/dist-packages/django/core/handlers/wsgi.py", line 245, in __call__ response = middleware_method(request, response) File "/home/me/myproject/djangologging/middleware.py", line 256, in process_response self._rewrite_html(request, response) File "/home/me/myproject/djangologging/middleware.py", line 310, in _rewrite_html response.write(footer) File "/usr/local/lib/python2.6/dist-packages/django/http/__init__.py", line 391, in write raise Exception("This %s instance is not writable" % self.__class__)

  What steps will reproduce the problem? 1. Use yield "some string" inside a view function, so it becomes an iterator 2. An exception occurs What is the expected output? What do you see instead? I would expect Django Logging to wait until no more is yielded from the view function - OR - not to do any logging, since it might not be possible. Please provide any additional information below. Traceback (most recent call last): File "/usr/local/lib/python2.6/dist-packages/django/core/servers/basehttp.py", line 278, in run self.result = application(self.environ, self.start_response) File "/usr/local/lib/python2.6/dist-packages/django/core/servers/basehttp.py", line 636, in __call__ return self.application(environ, start_response) File "/usr/local/lib/python2.6/dist-packages/django/core/handlers/wsgi.py", line 245, in __call__ response = middleware_method(request, response) File "/home/me/myproject/djangologging/middleware.py", line 256, in process_response self._rewrite_html(request, response) File "/home/me/myproject/djangologging/middleware.py", line 310, in _rewrite_html response.write(footer) File "/usr/local/lib/python2.6/dist-packages/django/http/__init__.py", line 391, in write raise Exception("This %s instance is not writable" % self.__class__)
• Aug 31, 2009

  issue 41 (Wanted to divert Django Console output to Log file) reported by skmail80   -   What steps will reproduce the problem? 1. We are using Django as a windows service.we want to divert the console output of Django to log files..how can we configure this? 2. 3. What is the expected output? What do you see instead? Django should show nothing on the console,but should send all the console output to the log file. What version of the product are you using? On what operating system? We are working on windows.And version of django-logging for python 2.5 Please provide any additional information below.

  What steps will reproduce the problem? 1. We are using Django as a windows service.we want to divert the console output of Django to log files..how can we configure this? 2. 3. What is the expected output? What do you see instead? Django should show nothing on the console,but should send all the console output to the log file. What version of the product are you using? On what operating system? We are working on windows.And version of django-logging for python 2.5 Please provide any additional information below.
• Aug 21, 2009

  Overview (A very brief overview of django-logging.) Wiki page commented on by Alex.Margetts   -   Thanks for this great application, its unbelievable how much the SQL debugging helps :-)

  Thanks for this great application, its unbelievable how much the SQL debugging helps :-)
• Aug 18, 2009

  Overview (A very brief overview of django-logging.) Wiki page commented on by specialbrew   -   The "Real Python logging example" page has moved to: http://antonym.org/2005/03/a-real-python-logging-example.html

  The "Real Python logging example" page has moved to: http://antonym.org/2005/03/a-real-python-logging-example.html
• Aug 04, 2009

  issue 30 (Add a simply setup.py) commented on by leidel   -   @seocam: I'm in.

  @seocam: I'm in.
• Aug 04, 2009

  issue 30 (Add a simply setup.py) commented on by seocam   -   We are maintaining a branch working with django 1 and 1.1 where: http://bitbucket.org/refack/djangologging/ I'm thinking about fork the project, I just don't want to do this alone. If there is any volunteers let me know! :)

  We are maintaining a branch working with django 1 and 1.1 where: http://bitbucket.org/refack/djangologging/ I'm thinking about fork the project, I just don't want to do this alone. If there is any volunteers let me know! :)
• Aug 04, 2009

  issue 30 (Add a simply setup.py) commented on by atkinsonr   -   Is this project even maintained? Please could you add this simple setup.py because without it PIP can't install djangologging :-(

  Is this project even maintained? Please could you add this simple setup.py because without it PIP can't install djangologging :-(
• Jul 28, 2009

  issue 33 (django logging raises IOError ) commented on by onelson   -   Yeah, I didn't get it at first, but it makes sense now. I guess before today I had source files in my path for every lib I was importing. Wanted to add a note here trying this and http://code.google.com/p/django-logging/issues/detail?id=36 together since it smoothed my issue over quite nicely (I even get my celery logs displayed!)

  Yeah, I didn't get it at first, but it makes sense now. I guess before today I had source files in my path for every lib I was importing. Wanted to add a note here trying this and http://code.google.com/p/django-logging/issues/detail?id=36 together since it smoothed my issue over quite nicely (I even get my celery logs displayed!)
• Jul 28, 2009

  issue 36 (Ignore cannot-find-source IOErrors from inspect.getsourcelin...) commented on by onelson   -   confirming (lol), this patch solved my issue too. Hooray for swallowing exceptions!

  confirming (lol), this patch solved my issue too. Hooray for swallowing exceptions!
• Jul 28, 2009

  issue 33 (django logging raises IOError ) commented on by onelson   -   I'm also having this issue (all of a sudden). http://paste2.org/p/345966 Yesterday I made the switch from using had-rolled lrp's and crons to using celery. Celery worked great in a little stand-alone django app I built to test it, but when I integrated it with my main project (which was already making use of djangologging), I get the IOError on pages that make use of the system.

  I'm also having this issue (all of a sudden). http://paste2.org/p/345966 Yesterday I made the switch from using had-rolled lrp's and crons to using celery. Celery worked great in a little stand-alone django app I built to test it, but when I integrated it with my main project (which was already making use of djangologging), I get the IOError on pages that make use of the system.
• Jul 21, 2009

  issue 40 (Logs in Redis) reported by jonas.esp   -   The logs could be stored in Redis since that it's an excellent choice to store data related to metrics and logs. http://code.google.com/p/redis/ http://adam.blog.heroku.com/past/2009/7/8/sql_databases_are_an_overapplied_solution_and_what_to_use_instead/

  The logs could be stored in Redis since that it's an excellent choice to store data related to metrics and logs. http://code.google.com/p/redis/ http://adam.blog.heroku.com/past/2009/7/8/sql_databases_are_an_overapplied_solution_and_what_to_use_instead/
• Jul 20, 2009

  Overview (A very brief overview of django-logging.) Wiki page commented on by andreas....@gmx.ch   -   How do you configure django-logging to print in a file? The problem is that code placed in settings.py gets executed several times, and each time a new filehandler is added. The logger ends up writing each line several times in the log file. There is a discussion of this problem here: http://www.djangosnippets.org/snippets/16/ None of the proposed solutions work for me. I found a way to avoid the problem by configuring the logger through a file. This works on windows, but I haven't been able to make it work on linux yet. It would be great if you could explain this with an example.

  How do you configure django-logging to print in a file? The problem is that code placed in settings.py gets executed several times, and each time a new filehandler is added. The logger ends up writing each line several times in the log file. There is a discussion of this problem here: http://www.djangosnippets.org/snippets/16/ None of the proposed solutions work for me. I found a way to avoid the problem by configuring the logger through a file. This works on windows, but I haven't been able to make it work on linux yet. It would be great if you could explain this with an example.
• Jul 17, 2009

  issue 39 (Choose where to display the logging messages) reported by seocam   -   With this patch the django-logging middleware look for two variables in the settings: LOGGING_BODY_PREPEND_PATTERN and LOGGING_HEAD_PREPEND_PATTERN Usage example: base.html template: {{{ <html> <head></head> <body> ... <-- start logging --> <-- end logging --> ... </body> </html> }}} settings.py: {{{ LOGGING_BODY_PREPEND_PATTERN = '(<-- end logging -->)' }}} Doing that the logging messages will be inserted between the comments instead of in the bottom of the page.

  With this patch the django-logging middleware look for two variables in the settings: LOGGING_BODY_PREPEND_PATTERN and LOGGING_HEAD_PREPEND_PATTERN Usage example: base.html template: {{{ <html> <head></head> <body> ... <-- start logging --> <-- end logging --> ... </body> </html> }}} settings.py: {{{ LOGGING_BODY_PREPEND_PATTERN = '(<-- end logging -->)' }}} Doing that the logging messages will be inserted between the comments instead of in the bottom of the page.
• Jul 17, 2009

  issue 30 (Add a simply setup.py) commented on by seocam   -   If you are running the your django project from an egg this is also required.

  If you are running the your django project from an egg this is also required.
• Jun 15, 2009

  issue 38 (Include traceback) commented on by ref...@gmail.com   -   I've opened a branch on bitbucket: http://bitbucket.org/refack/djangologging/

  I've opened a branch on bitbucket: http://bitbucket.org/refack/djangologging/
• Jun 13, 2009

  issue 34 (prevent default behavior on clicked anchor scrolls to top) commented on by ref...@gmail.com   -   Patch fix this issue (+ better printing of variable values)

  Patch fix this issue (+ better printing of variable values)
• Jun 13, 2009

  issue 38 (Include traceback) reported by ref...@gmail.com   -   Based on r42 I fixed the find-source-lines issues (issue 33 & 36), and implemented trace-back. Also merged profiling branch (minus the hint)

  Based on r42 I fixed the find-source-lines issues (issue 33 & 36), and implemented trace-back. Also merged profiling branch (minus the hint)
• May 20, 2009

  issue 30 (Add a simply setup.py) commented on by mackstann   -   Please apply this patch! I've recently discovered the greatness of pip and virtualenv. While django-logging is also great, I'm going to have to stop using it until this patch is applied, since I don't want to manually manage my project's dependencies anymore.

  Please apply this patch! I've recently discovered the greatness of pip and virtualenv. While django-logging is also great, I'm going to have to stop using it until this patch is applied, since I don't want to manually manage my project's dependencies anymore.
• Apr 30, 2009

  issue 37 (LoggingMiddleware conflicts (somehow) with django-pyodbc) reported by bjruth   -   What steps will reproduce the problem? 1. setup an environment using django-pyodbc backend (sql_server) 2. add djangologging to installed apps, add LoggingMiddleware in settings 3. run the server and make some queries... What is the expected output? What do you see instead? I expect for my SQL queries to work and for the appropriate logging info to be shown to me e.g "1 database query which took 6 ms" + the sql queries that were ran (in my case via ajax calls). An error is thrown consistently: DataError: (`22018`, "[22018] [FreeTDS][SQL Server]Conversion failed when converting the varchar value `on` to data type int. (245) (SQLExecDirectW)"). If I disable the middleware, it works perfectly. It kind of doesn't make sense (since in fact `on` can't be converted to an int), but why would it be there in the first place. What version of the product are you using? On what operating system? I am using rev 42 on os x. Please provide any additional information below. I don't really expect YOU to fix this, since this is a conflict with another app, but if you have a suspicious to what it could be or point me in a direction within your code to patch it, I would be more than happy to attempt to fix it. Then again, who knows if it is your code that is the issue.. but up until I installed djangologging into my apps and added the middleware I never had this issue.. so there must be conflict somewhere. And by the way.. django logging is outstanding. Thanks for the great tool.

  What steps will reproduce the problem? 1. setup an environment using django-pyodbc backend (sql_server) 2. add djangologging to installed apps, add LoggingMiddleware in settings 3. run the server and make some queries... What is the expected output? What do you see instead? I expect for my SQL queries to work and for the appropriate logging info to be shown to me e.g "1 database query which took 6 ms" + the sql queries that were ran (in my case via ajax calls). An error is thrown consistently: DataError: (`22018`, "[22018] [FreeTDS][SQL Server]Conversion failed when converting the varchar value `on` to data type int. (245) (SQLExecDirectW)"). If I disable the middleware, it works perfectly. It kind of doesn't make sense (since in fact `on` can't be converted to an int), but why would it be there in the first place. What version of the product are you using? On what operating system? I am using rev 42 on os x. Please provide any additional information below. I don't really expect YOU to fix this, since this is a conflict with another app, but if you have a suspicious to what it could be or point me in a direction within your code to patch it, I would be more than happy to attempt to fix it. Then again, who knows if it is your code that is the issue.. but up until I installed djangologging into my apps and added the middleware I never had this issue.. so there must be conflict somewhere. And by the way.. django logging is outstanding. Thanks for the great tool.
• Apr 20, 2009

  issue 34 (prevent default behavior on clicked anchor scrolls to top) commented on by bjruth   -   worked for firefox 3 on arch linux. thanks for the patch.

  worked for firefox 3 on arch linux. thanks for the patch.
• Apr 20, 2009

  issue 36 (Ignore cannot-find-source IOErrors from inspect.getsourcelin...) commented on by bjruth   -   I also applied the patch and it stopped throwing IOError. Thanks.

  I also applied the patch and it stopped throwing IOError. Thanks.
• Apr 13, 2009

  issue 36 (Ignore cannot-find-source IOErrors from inspect.getsourcelin...) commented on by roscoedesign   -   I applied this patch and it fixed my 'IOError could not get source'

  I applied this patch and it fixed my 'IOError could not get source'
• Apr 11, 2009

  issue 29 (Conflict with django-debug-toolbar: OperationalError: Unable...) commented on by ubershmekel   -   I also got this on the pinax project when I used the bookmarks app. I had to disable the debug toolbar. I managed to pin the problem down to {% for bookmark in bookmarks %}. When everything is commented in the for-loop, the for-loop itself causes the exception.

  I also got this on the pinax project when I used the bookmarks app. I had to disable the debug toolbar. I managed to pin the problem down to {% for bookmark in bookmarks %}. When everything is commented in the for-loop, the for-loop itself causes the exception.
• Apr 07, 2009

  issue 36 (Ignore cannot-find-source IOErrors from inspect.getsourcelin...) reported by marius.eriksen   -   Sometimes, inspect.getsourcelines will fail. Eg, if you're using a library for which you don't have the source. The attached patch ignores this error, and displays an error message for the "source" instead.

  Sometimes, inspect.getsourcelines will fail. Eg, if you're using a library for which you don't have the source. The attached patch ignores this error, and displays an error message for the "source" instead.
• Mar 23, 2009

  issue 35 (Suppressing output in Inclusion tag ) reported by coulix   -   What steps will reproduce the problem? @suppress_logging_output @register.inclusion_tag('agenda/calendar/calendar.html', takes_context=True) def show_month_cal_for_meetings(context, year=date.today().year, month=date.today().month): the rendered result will still include Request SQL log info. When i force LOGGING_LOG_SQL = False in settings it will still append Request Log No log entries. At the end of my rendered calendar element, how do i completely suppress loggin output for a tag ? What version of the product are you using? On what operating system?. Django logging svn 42 Django 1.0.2 Python 2.5.2 Ubuntu

  What steps will reproduce the problem? @suppress_logging_output @register.inclusion_tag('agenda/calendar/calendar.html', takes_context=True) def show_month_cal_for_meetings(context, year=date.today().year, month=date.today().month): the rendered result will still include Request SQL log info. When i force LOGGING_LOG_SQL = False in settings it will still append Request Log No log entries. At the end of my rendered calendar element, how do i completely suppress loggin output for a tag ? What version of the product are you using? On what operating system?. Django logging svn 42 Django 1.0.2 Python 2.5.2 Ubuntu
• Mar 11, 2009

  issue 34 (prevent default behavior on clicked anchor scrolls to top) reported by smiletall   -   What steps will reproduce the problem? 1. click any anchor element in the django-logging output on a rendered template What is the expected output? What do you see instead? I expect the hidden trace to show while the page position remains intact. Instead, the trace does show as it should, but the window is scrolled to the top. What version of the product are you using? On what operating system? trunk Firefox 3.0.7 on MacOS X 10.5.6 Please provide any additional information below. Firefox 3 does not support a return value on event handlers. instead, you can use the method, preventDefault, to stop the default action from occurring. attached is a patch i'm using, and it works on each of my environments (IE6&7 on XP, IE7 on Vista, Safari 3.2.1 and Firefox 3.0.7 on Mac OS X). thanks for the fantastic app!

  What steps will reproduce the problem? 1. click any anchor element in the django-logging output on a rendered template What is the expected output? What do you see instead? I expect the hidden trace to show while the page position remains intact. Instead, the trace does show as it should, but the window is scrolled to the top. What version of the product are you using? On what operating system? trunk Firefox 3.0.7 on MacOS X 10.5.6 Please provide any additional information below. Firefox 3 does not support a return value on event handlers. instead, you can use the method, preventDefault, to stop the default action from occurring. attached is a patch i'm using, and it works on each of my environments (IE6&7 on XP, IE7 on Vista, Safari 3.2.1 and Firefox 3.0.7 on Mac OS X). thanks for the fantastic app!
• Feb 23, 2009

  issue 33 (django logging raises IOError ) commented on by guenter....@wanagu.at   -   Problem is still there. Traceback can be found at http://www.dpaste.com/155/. Thank you Günter

  Problem is still there. Traceback can be found at http://www.dpaste.com/155/. Thank you Günter
• Feb 15, 2009

  issue 33 (django logging raises IOError ) commented on by frasern   -   I have just added a fix for issue 26 which makes thinks work better with symlinked code. In case this has inadvertently solved your problems, could you please update to the latest trunk version of django-logging and try again? If you are still having problems, could you please post a traceback of the issue? This will help track down exactly where the issue lies.

  I have just added a fix for issue 26 which makes thinks work better with symlinked code. In case this has inadvertently solved your problems, could you please update to the latest trunk version of django-logging and try again? If you are still having problems, could you please post a traceback of the issue? This will help track down exactly where the issue lies.
• Feb 15, 2009

  issue 27 (django-logging interfers with AJAX requests) Status changed by frasern   -   Fixed in r42.

  Status: Fixed

  Fixed in r42.

  Status: Fixed
• Feb 15, 2009

  r42 (Fixed issue 27 -- added SuppressLoggingOnAjaxRequestsMiddlew...) committed by frasern   -   Fixed issue 27 -- added SuppressLoggingOnAjaxRequestsMiddleware to help automatically suppress the output on AJAX requests. Thanks Marius Eriksen.

  Fixed issue 27 -- added SuppressLoggingOnAjaxRequestsMiddleware to help automatically suppress the output on AJAX requests. Thanks Marius Eriksen.