Re: [cgiapp] draft version of PSGI::Application and load_tmpl replacement
On 11/6/2012 12:24 PM, Mark Stosberg wrote: * Hash keys for new() must now be upper-case now. Ridiculous. Lower case hash keys are the norm throughout Perl. Upper case is SHOUTING. I agree that lower case hash keys are the norm and upper case hash keys are shouting. The choice here weas a nod to compatibility with CGI::Application, which internally was case-insensitive, but by convention, everyone has been using the upper-case keys. I'm open to reconsidering this point as well, as I would prefer lower case going forward myself. Perhaps the upper-case support can be pushed into a ::Compat transitional module. I'd vote for lower-casing them, if you're looking for feedback. -Kurt # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] cgi::application::dispatch under PSGI
On 2/28/2012 2:33 PM, Rhesa Rozendaal wrote:
On 02/28/2012 05:45 PM, Kurt Lidl wrote:
Greetings.
I've got a large application that is running under mod_perl, running on
Apache 2.2.22.
Everything is working OK there. It uses CGI::Application::Dispatch as
its invocation
method.
I'm using roughly the same stack, though I use starman in dev, and
intend to do so in prod as well (behind an apache reverse proxy).
I became interested in making that application work under PSGI. Since
that is
now supported natively by modern versions of CGI::Application, I figured
it shouldn't
be too hard to make this work.
It's not hard, but I found out it takes jumping through some hoops.
I've got a dead-simple .psgi file:
--- snip, snip ---
use lib ('..');
use Data::Dump qw(dump ddx);
use CWS1::Dispatch;
CWS1::Dispatch-as_psgi;
--- snip, snip ---
Here's mine, using your class name as example:
--- snip, snip ---
use CWS1::Dispatch;
use CGI::PSGI;
my $cgiapp = sub {
my $env = shift;
CWS1::Dispatch-as_psgi(
args_to_new = {
QUERY = CGI::PSGI-new($env),
})-($env);
};
--- snip, snip ---
The key here is that I found I needed to make sure each request gets a
fresh instance of a CGI::PSGI object.
This was part of the problem I was having. Thanks for that tip. I am
now using
a .psgi file just like the one you constructed.
In my Dispatch.pm file, I have this:
Mine is the same (in structure).
There's nothing specific in my regular apps, and I do receive params
from CA::Dispatch. So I think you'll get it working in your situation
too, as long as you make sure you pass in a fresh CGI::PSGI object every
time.
The trickier part to debug was this -- why I wasn't getting parameters
passed into
my application.
As it turns out, the LocationMatch directive I had was the problem:
LocationMatch ^/cws1/(?!static/).*$
SetHandler perl-script
PerlHandler Plack::Handler::Apache2
PerlSetVar psgi_app /path/to/websvc/CWS1/CWS1.psgi
Order allow,deny
Allow from all
/LocationMatch
The Plack::Handler::Apache2 code whacks the PATH_INFO of the environment
after striping off the components of the original PATH_INFO that match the
regular expression in the LocationMatch.
Normally, you might have something like LocationMatch ^/cws/foo.
The problem with the regex I was using that it matched everything in the
PATH_INFO,
so the Apache2 handler was changing PATH_INFO into just /, rather than
leaving
it as /cws1.
I changed my LocationMatch directive to merely be: ^/cws1/(?!static/)
and that works
just fine now.
I think, in my reading about this, that this is still subtly wrong, and
it really should be
/+cws1/+(?!static/+)/. Because LocationMatch doesn't collapse multiple
slash
characters together. So /cws1//static would still be dispatched,
whereas /cws1/static
would not. (See the special Note about / (slash) section in the
Apache core module
documentation on the Location header, for the gory details.)
-Kurt
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] cgi::application::dispatch under PSGI
On 2/28/2012 11:45 AM, Kurt Lidl wrote: Greetings. I've got a large application that is running under mod_perl, running on Apache 2.2.22. Everything is working OK there. It uses CGI::Application::Dispatch as its invocation method. Debugging this further, I see that the PATH_INFO environmental variable has been reset to /' by the time CGI::Application::Dispatch::PSGI.pm has started to run. That explains why I'm not getting parameters passed into the scripts. Curiously, the SCRIPT_NAME and SCRIPT_URL variables are still set properly. I guess I just have to figure out where the PATH_INFO is getting mangled... -Kurt # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Threading Question
On Tue, Nov 17, 2009 at 11:22:59AM +, Mike Tonks wrote: I'm just considering a problem that I think requires a bit of multi-threading. It's a new one for me so wondered if anyone has advice or experience of using threading with CGI::Application. I expect that you'll run afoul of DBI's limitation on working with threaded perl. While it kinda works, the DBI documentation says that using threads with DBI (even if you work around the various issues with making it work) isn't recommended for production environments. Scenario is: We have 5 database servers at different sites. We would like to create a search function that queries all of the databases. The web server is on an intranet and can open connections to all of the database servers. Why not just open up 5 database handles and execute the queries. The queries should run in parallel, and you can choose how to interleave the processsing of the result sets however you want. Also I guess there could be server issues with the use of multiple threads? There's also the DBIx::Threaded stuff, which spawns off additional threads and gives you an API for accessing those threads (and the database handles bound to them), but it all looks pretty scary to me. -Kurt # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Re: A new project name for CGI::Application
Mark Stosberg wrote: On 2005-12-06, Jesse Erlbaum [EMAIL PROTECTED] wrote: All three of these more of less dictate a way of doing things. CGI-App is more of a philosophy. So: ThinkingCAP ? CAPable -Kurt - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
