Has the situation with code coverage changed at all since the posts in
2010?
--
You received this message because you are subscribed to the Google Groups
modwsgi group.
To post to this group, send email to modwsgi@googlegroups.com.
To unsubscribe from this group, send email to
to?
Graham
On 28 March 2012 10:44, bc craft.br...@gmail.com wrote:
On Mar 27, 3:08 pm, bc craft.br...@gmail.com wrote:
Has the situation with code coverage changed at all since the posts in
2010?
I gave the following a try, which gave me some results (using daemon
mode)
Set
To be clear, I'm not using anything from that post. I'm just using the
process I outlined, using the coverage start/stop/save methods from
django view functions (while limiting apache to one thread).
On Mar 27, 8:01 pm, bc craft.br...@gmail.com wrote:
http://groups.google.com/group/modwsgi
When adding mod_deflate config to apache, I'm finding that requests
handled by file_wrapper get gzipped, even if they don't match the
filter specification (e.g. images). Here's the config:
AddOutputFilterByType DEFLATE text/html text/plain text/css
application/x-javascript
Requests that are
On Mar 3, 5:08 pm, Graham Dumpleton graham.dumple...@gmail.com
wrote:
Okay, that one specific case will cause sys.path to grow.
What happens is that on very first load of WSGI script file, if it
fails at global level it will log error and then throw what was loaded
away and so will look as
:
http://code.google.com/p/modwsgi/issues/detail?id=204
So, actually only fixed in most recent public release.
Graham
On 2 March 2011 09:56, bc craft.br...@gmail.com wrote:
On Mar 1, 2:47 pm, Graham Dumpleton graham.dumple...@gmail.com
wrote:
What version of mod_wsgi are you
I read over the docs for wsgi with virtualenv, and am now calling
site.addsitedir() on the site-packages of my virtual install, from the
wsgi script. However I was getting errors trying to import a module
(django.core.handlers.wsgi). Doing the addsitedir() and import on the
command line worked
On Mar 3, 1:37 pm, Graham Dumpleton graham.dumple...@gmail.com
wrote:
Don't use embedded mode. Preferably use daemon mode and you will not
have this problem.
I thought I was. I have a number of WSGIDaemonProcess directives, each
running as a different user. I'm assigning WSGIProcessGroup via
graham.dumple...@gmail.com
wrote:
On 4 March 2011 08:53, bc craft.br...@gmail.com wrote:
On Mar 3, 1:37 pm, Graham Dumpleton graham.dumple...@gmail.com
wrote:
Don't use embedded mode. Preferably use daemon mode and you will not
have this problem.
I thought I was. I have a number
anything to make it easier
for me will be most appreciated.
On 4 March 2011 10:46, bc craft.br...@gmail.com wrote:
I strongly suspect this is due to uncaught, or badly handled
exceptions. It doesn't happen on requests that don't throw exceptions.
In that case I see sys.path updated once
On Mar 1, 2:47 pm, Graham Dumpleton graham.dumple...@gmail.com
wrote:
What version of mod_wsgi are you using? Some older versions of
mod_wsgi could see such logging go missing where HTTPS was used or
other strange VirtualHost configurations.
More details about your Apache configuration, use
Is the application group name available to the wsgi application? I'm
trying to understand how application groups work, and would like to
log the application group name from the application.
--
You received this message because you are subscribed to the Google Groups
modwsgi group.
To post to
On Feb 25, 8:58 am, bc craft.br...@gmail.com wrote:
I just read the page on using wsgi with virtualenv. I don't quite
understand the point of using virtualenv. How is it different than
doing a parallel install of python (which is fairly painless)?
Replying to my own question
I just read the page on using wsgi with virtualenv. I don't quite
understand the point of using virtualenv. How is it different than
doing a parallel install of python (which is fairly painless)?
--
You received this message because you are subscribed to the Google Groups
modwsgi group.
To post
the cracks.
On 15 February 2011 04:11, bc craft.br...@gmail.com wrote:
I'm using wsgi.file_wrapper to serve secured media in the context of
wsgi (the important part being that wsgi can run as a different user).
I notice in the mod_rewrite logs that when I do this, the file path
passes
I'm using wsgi.file_wrapper to serve secured media in the context of
wsgi (the important part being that wsgi can run as a different user).
I notice in the mod_rewrite logs that when I do this, the file path
passes through apache as a subrequest with the wsgi mount point
stripped off.
That is, if
Can anyone explain how SCRIPT_NAME is calculated? I'm using
mod_rewrite to do per-developer cgi directories, with sometimes
amusing results in SCRIPT_NAME. I've seen in the forums that
SCRIPT_NAME is the wsgi 'mount point', but this is clearly a
simplification, because there's not always a
17 matches
Mail list logo
