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
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 star
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 env
On 03/11/2011 11:20 PM, Ron Savage wrote:
> Hi James
>
> On Fri, 2011-03-11 at 19:58 -0800, James.Q.L wrote:
>> Thanks for reporting it on RT.
>>
>> I think C::A::D should respect C::A's start_mode. If no rm is defined in
>> C::A::D rules, the start_mode in the dispatched module should be used.
Hi James
On Fri, 2011-03-11 at 19:58 -0800, James.Q.L wrote:
> Thanks for reporting it on RT.
>
> I think C::A::D should respect C::A's start_mode. If no rm is defined in
> C::A::D rules, the start_mode in the dispatched module should be used.
>
> A sentence of describing the use of start_mode
avage wrote:
> From: Ron Savage
> Subject: Re: [cgiapp] cgi::application::dispatch doesn't handle start_mode
> To: "CGI Application"
> Date: Friday, March 11, 2011, 3:59 PM
> Hi James
>
> I've logged an error report:
>
> https://rt.cpan.org/Ticket/D
Hi James
I've logged an error report:
https://rt.cpan.org/Ticket/Display.html?id=66558
--
Ron Savage
http://savage.net.au/
Ph: 0421 920 622
# CGI::Application community mailing list
####
## To unsubscribe, or
Hi James
On Thu, 2011-03-10 at 20:15 -0800, James.Q.L wrote:
> --- On Sat, 3/5/11, Ron Savage wrote:
>
> > From: Ron Savage
> > Subject: Re: [cgiapp] cgi::application::dispatch doesn't handle start_mode
> > To: "CGI Application"
> > Date:
--- On Sat, 3/5/11, Ron Savage wrote:
> From: Ron Savage
> Subject: Re: [cgiapp] cgi::application::dispatch doesn't handle start_mode
> To: "CGI Application"
> Date: Saturday, March 5, 2011, 6:40 PM
> Hi James
>
> On Sat, 2011-03-05 at 01:25 -0800, James.Q
Hi James
On Sat, 2011-03-05 at 01:25 -0800, James.Q.L wrote:
> Hi,
>
> It seems that C::A::D always sets the runmode to $rm_HTTP_METHOD even when
> $rm is not set, which produces a _HTTP_METHOD runmode. that' doesn't work
> when start_mode is expected to be run. it is due to the following code
On 10/11/2010 10:53 AM, Michael Peters wrote:
> On 10/11/2010 10:00 AM, Kurt Lidl wrote:
>
>> But, to follow up the "tighter integration" part of the answer: Is there
>> a good
>> example/resource that shows how this is done?
>
> I depends on what you want to do. One of the benefits of C::A is th
On 10/11/2010 10:00 AM, Kurt Lidl wrote:
> But, to follow up the "tighter integration" part of the answer: Is there
> a good
> example/resource that shows how this is done?
I depends on what you want to do. One of the benefits of C::A is that it
separates out your development from Apache so that
On 10/8/2010 12:29 PM, Michael Peters wrote:
> On 10/08/2010 11:12 AM, Kurt Lidl wrote:
>
>> Now this is all basically working, but not exactly as I would expect.
>> I see that for request that comes in, both cgiapp_init as
>> well as cgiapp_prerun get executed, for every request.
> >
>> I expect
On 10/08/2010 11:12 AM, Kurt Lidl wrote:
> Now this is all basically working, but not exactly as I would expect.
> I see that for request that comes in, both cgiapp_init as
> well as cgiapp_prerun get executed, for every request.
>
> I expected that cgiapp_init would get executed only when
> Apac
On May 10, 2010, Michael Peters wrote:
> On 05/10/2010 09:36 AM, Brad Van Sickle wrote:
> > It appears that Dispatch.pm is never getting a value for $ENV{PATH_INFO}
> >
> > Printing out my environment hash, I can see that PATH_INFO is not
> > available as an option, however I do have a REQUEST_URI
Server version: Apache/2.2.12 (Unix)
mod_perl2
Michael Peters wrote:
> On 05/10/2010 09:36 AM, Brad Van Sickle wrote:
>
>> It appears that Dispatch.pm is never getting a value for $ENV{PATH_INFO}
>>
>> Printing out my environment hash, I can see that PATH_INFO is not
>> available as an option,
On 05/10/2010 09:36 AM, Brad Van Sickle wrote:
> It appears that Dispatch.pm is never getting a value for $ENV{PATH_INFO}
>
> Printing out my environment hash, I can see that PATH_INFO is not
> available as an option, however I do have a REQUEST_URI option that
> looks like it might work.
This see
It appears that Dispatch.pm is never getting a value for $ENV{PATH_INFO}
Printing out my environment hash, I can see that PATH_INFO is not
available as an option, however I do have a REQUEST_URI option that
looks like it might work.
in my dispatch handler I attempted to set the PATH_INFO key
Thanks! this looks like it will work perfectly.
However, I'm still having a bit of trouble getting dispatching to work
properly. I have a handler set up under mod_perl to send all requests
that start with /dispatchperl/ to my dispatcher, and I have verfiied
that this setup is infact handling
On 05/07/2010 11:09 AM, Brad Van Sickle wrote:
> example:
> I have the URI - /Home and I want to translate that to rm=Content and
> populate the $self->param('Session') "variable" with "Home" Today I
> simply use mod_rewrite to translate that URI into
> /index.pl?rm=Content&Section=Home and then
Ah. of course. Appears to be working now.
Thanks!
Michael Peters wrote:
> On 04/27/2010 03:12 PM, Brad Van Sickle wrote:
>
>
>> [Tue Apr 27 11:58:35 2010] -e: [Dispatch] ERROR for request
>> '/dispatchperl/': Can't locate object method "new" via package
>> "public::Packages::PublicSite" a
On 04/27/2010 03:12 PM, Brad Van Sickle wrote:
> [Tue Apr 27 11:58:35 2010] -e: [Dispatch] ERROR for request
> '/dispatchperl/': Can't locate object method "new" via package
> "public::Packages::PublicSite" at
> /usr/lib/perl5/site_perl/5.8.8/CGI/Application/Dispatch.pm line 702.
> [Tue Apr 27 11:
On Wed, Feb 11, 2009 at 5:45 AM, Lyle wrote:
> Hi All,
> I was just looking at this modules docs and I noticed it says:-
>
> It will translate a URI like this (under mod_perl):
>
> /app/module_name/run_mode
>
> or this (vanilla cgi)
>
> /app/index.cgi/module_name/run_mode
>
> I'm guess it mig
Michael Peters wrote:
Lyle wrote:
Which is way, way more SEO friendly.
Really? A .html extension makes it easier for Google (the only one
that really matters
http://www.codinghorror.com/blog/archives/001224.html) to find it?
What evidence do you have for that?
It won't make it any more l
Lyle wrote:
Which is way, way more SEO friendly.
Really? A .html extension makes it easier for Google (the only one that really matters
http://www.codinghorror.com/blog/archives/001224.html) to find it? What evidence do you have for that?
If someone knows the Apache config to get this down
P Kishor wrote:
CGI::Application::Dispatch->dispatch(
prefix => '',
default => '',
debug => 1,
table => [
'' => { app => $App, rm => 'view' },
'find' => { app => $App, rm => 'find', },
'view/:p?/:o?/:s?' => { app => $App,
> That right there is kind of a red-flag. Not that you're doing anything wrong,
> but Apache has a weird notion of PATH_INFO when a real directory exists. And
> Dispatch relies on PATH_INFO for parsing. You can check what Apache thinks it
> is by printing the $ENV{PATH_INFO} in your Dispatch.pm.
fREW Schmidt wrote:
I am a little confused about how CAD is supposed to work I guess.
Let's see if we can help...
First off, I have a directory, call it abc.
That right there is kind of a red-flag. Not that you're doing anything wrong, but Apache has a weird
notion of PATH_INFO when a rea
Jason A. Crome wrote:
mpeters: If I sent you a CGI::Application::Dispatch::IIS subclass, could
you (or Mark) incorporate it into the CA::Dispatch distribution? Or, if
you don't want to mess with it and wouldn't mind another co-maintainer,
I'd be happy to maintain this bit of it.
I'd be happ
Ok, not instead of trying to use the toolchain to install Module::Build and then
Apache::Test (if you answered yes at the prompt) I'm just going to be really
dumb. If you have Apache::Test on your machine I will use it and run the
mod_perl tests as well as the CGI ones. Else I won't. And since app
Michael,
> Ok, not instead of trying to use the toolchain to install Module::
> Build and then
> Apache::Test (if you answered yes at the prompt) I'm just going to be
really
> dumb. If you have Apache::Test on your machine I will use it and run the
> mod_perl tests as well as the CGI ones. Else I
Hello Michael,
>> [EMAIL PROTECTED]:~/perltemp/CGI-Application-Dispatch-2.12]> perl
>> Makefile.PL
>> This module can optionally use Apache::Test to test the mod_perl
>> functionality.
>> Undefined subroutine &ExtUtils::MakeMaker::prompt called at
>> Makefile.PL
>> l
Michael Peters wrote:
> Ok, not instead of trying to use the toolchain to install Module::Build and
> then
> Apache::Test (if you answered yes at the prompt) I'm just going to be really
> dumb. If you have Apache::Test on your machine I will use it and run the
> mod_perl tests as well as the CGI
Michael Peters wrote:
> I am trying to be smarter than the average Makefile.PL, but I just seem to be
> getting more trouble then it's work at this point. I'll probably just go back
> to
> being dumb and not run the Apache/mod_perl tests unless the person already
> have
> Apache::Test installed.
Todd Ross wrote:
> [EMAIL PROTECTED]:~/perltemp/CGI-Application-Dispatch-2.12]> perl Makefile.PL
> This module can optionally use Apache::Test to test the mod_perl
> functionality.
> Undefined subroutine &ExtUtils::MakeMaker::prompt called at Makefile.PL
> line 31, line 547.
I'm curious about
Hello Todd,
I had the same issues, see bug:
http://rt.cpan.org/Public/Bug/Display.html?id=33498
I found that I needed to patch a Build.PL and Makefile.PL when Apache::Test
wasn't installed.
There are patches attached to the bug, give them a try. I'm pretty confident
they will work (that p
Hi Todd
On Fri, 2008-03-07 at 09:34 -0600, Todd Ross wrote:
> I've seen quite a few posts on this list concerning
> CGI::Application::Dispatch. I'd like to try it out. Installing it,
> however, seems to be a problem. Since there is no README or INSTALL
> included in the archive, I'm followin
On Fri, Mar 7, 2008 at 8:34 AM, Todd Ross <[EMAIL PROTECTED]> wrote:
> I've seen quite a few posts on this list concerning
> CGI::Application::Dispatch.
Was it Dispatch or Plugin::ActionDispatch?
http://search.cpan.org/perldoc?CGI%3A%3AApplication%3A%3APlugin%3A%3AActionDispatch
I know I mentio
Michael Peters wrote in an email message dated 2/15/2008 6:37 PM:
Bruce McKenzie wrote:
Thanks Michael. Any way I name it, I get a Not Found.
That's becuase you didn't follow my advice :) See below.
Well, I tried :-(
So your module is called 'Notify'. If you notice in my last email I said
Bruce McKenzie wrote:
> Thanks Michael. Any way I name it, I get a Not Found.
That's becuase you didn't follow my advice :) See below.
> I tried this:
> #!/usr/bin/perl
> use strict;
> use FindBin qw($Bin);
> use lib "$Bin/../perl_lib"; # my standard lib
> use lib "$Bin/Modules"; # lib
Michael Peters wrote in an email message dated 2/15/2008 5:00 PM:
Is your module's package called "Modules::Notify" or just "Notify"? If it's the
first then change your "use lib" line to:
use lib $Bin;
If it's the latter, then you don't need a prefix at all:
CGI::Application::Dispatch->dis
Bruce McKenzie wrote:
> CGI::Application::Dispatch is a favorite plugin of many on this list,
> and it used to be one of mine, but it stopped working in my setup at
> version 2.x. Never figured out why, and I'm OK doing things the
> old-fashioned way, but I thought I'd give it another shot.
>
> Su
Simon Rees wrote:
> Hello
>
> I'm using CGI::Application::Dispatch under mod_perl 2 to display all the
> pages
> on a site I'm working on and have had problems getting it to play nicely with
> path_info as reported by Apache.
>
> What I would like to happen is:
> Request: http://example.com/fo
Alexander Becker wrote:
> I thought on using prefix => '' in the dispatch specific configuration,
> but that only for additional prefixes, it doesn't alter the "global"
> prefix (and that makes sense).
Yeah, that's a bug in Dispatch. It should be able to work like that. Let me see
if I can fix t
Alexander Becker wrote:
Hi Alexander
That works fine, as long as I write all modules my own. But today, I
wanted to use the CGI::Application::Photogallery. That didn't work
One way would be to sub-class that module, with a My:: prefix.
Then, you could, perhaps, have that module know where t
> > On 6/13/07, Simon Rees <[EMAIL PROTECTED]> wrote:
> > >
> > > SetHandler perl-script
> > > PerlHandler CGI::Application::Dispatch
> > > PerlSetVar CGIAPP_DISPATCH_PREFIX Newforms::MembersCGIApp::Dispatch
> > > PerlSetVar CGIAPP_DISPATCH_DEFAULT /public/front
> > > PerlSetVar CGIAPP_
Hi Mike
> On 6/13/07, Simon Rees <[EMAIL PROTECTED]> wrote:
> >
> > SetHandler perl-script
> > PerlHandler CGI::Application::Dispatch
> > PerlSetVar CGIAPP_DISPATCH_PREFIX Newforms::MembersCGIApp::Dispatch
> > PerlSetVar CGIAPP_DISPATCH_DEFAULT /public/front
> > PerlSetVar CGIAPP_DISPA
On 6/13/07, Simon Rees <[EMAIL PROTECTED]> wrote:
SetHandler perl-script
PerlHandler CGI::Application::Dispatch
PerlSetVar CGIAPP_DISPATCH_PREFIX Newforms::MembersCGIApp::Dispatch
PerlSetVar CGIAPP_DISPATCH_DEFAULT /public/front
PerlSetVar CGIAPP_DISPATCH_DEBUG 1
When I try to reque
Michael Peters wrote:
>
> Dan Horne wrote:
>
>> Just a side note - I
>> initially attempted to run Makefile.PL (out of habit, I guess) and it failed
>> due to the Apache::Test dependency. However, Build.PL worked fine and dandy
>
> Thanks for the catch. I've fixed this too and the final release
Dan Horne wrote:
> From: Michael Peters
>
>> Then grab the latest dev version from CPAN - 2.10_02
>> (uploaded about 10 minutes
>> ago) which should only use Apache::Test if you already have
>> it installed and won't list it as a pre-req. It will also
>> skip the mod_perl tests as well.
>>
>
From: Michael Peters
> Then grab the latest dev version from CPAN - 2.10_02
> (uploaded about 10 minutes
> ago) which should only use Apache::Test if you already have
> it installed and won't list it as a pre-req. It will also
> skip the mod_perl tests as well.
>
Hi Michael
Thanks for your
> From: Michael Peters
>
> ... grab the latest dev version from CPAN - 2.10_02
> (uploaded about 10 minutes
> ago) which should only use Apache::Test if you already have
> it installed and won't list it as a pre-req. It will also
> skip the mod_perl tests as well.
>
Thanks Michael
I'll let yo
Dan Horne wrote:
>> From: Michael Peters
>> Dan Horne wrote:
>>
>>> I received the following message when running the tests:
>>> [ error] You are using mod_perl response handlers [ error] but do
>>> not have a mod_perl capable Apache.
>> Someone in #cgiapp just reported the same thing. It work
> From: Michael Peters
> Dan Horne wrote:
>
> > I received the following message when running the tests:
>
> > [ error] You are using mod_perl response handlers [ error] but do
> > not have a mod_perl capable Apache.
>
> Someone in #cgiapp just reported the same thing. It works
> fine for me
Dan Horne wrote:
> I received the following message when running the tests:
> [ error] You are using mod_perl response handlers
> [ error] but do not have a mod_perl capable Apache.
Someone in #cgiapp just reported the same thing. It works fine for me so I'm not
sure of the exact issue. I di
> -Original Message-
> From: Michael Peters
> Sent: Friday, 12 January 2007 7:02 a.m.
> I've received feedback from 1 other FCGI user who said it
> solved his problem. Please try it out. The interface won't
> change between the dev release the next public release, so
> even if somet
Dan Horne wrote:
> Hi
>
> I currently use CGI::Application::Dispatch v1 with FastCGI, and it works
> very well for me. I'd like to start using v2 in order to take advantage of
> the URL matching capability, but understand that there are URL caching
> problems
> (http://www.mail-archive.com/cgiap
Shawn Sorichetti wrote:
> I'm setting up a new application and finally using version 2.x of
> CGI::Application::Dispatch. My dispatch table so far looks like this:
>
> table => [
> ':instance/app' => { app => 'Welcome', rm => 'welcome' },
> ':instance/app/module/:rm/:object' => { app =>
David Steinbrunner wrote:
> In an effort to figure out more about the reasoning of the caching I started
> looking over the docs more and found the PROTECTED METHODS section that
> talks about the _get_cache and _set_cache methods. At that point I had the
> bright idea of sub classing them so t
> From: David Steinbrunner
>
> Dan Horne wrote:
>
> > Hmm, I had a similar problem while back, where previous GET
> and POST
> > data would seem to reappear. Upgrading CGI (and hence
> CGI::Fast) made
> > it go away for me...
>
> The box I'm using was built recently and I made sure to
> upd
Dan Horne wrote:
> Hmm, I had a similar problem while back, where previous GET and POST data
> would seem to reappear. Upgrading CGI (and hence CGI::Fast) made it go away
> for me...
The box I'm using was built recently and I made sure to update used modules,
so that should not be an issue. Here
> From: David Steinbrunner On Behalf Of
> David Steinbrunner
> Sent: Saturday, 18 November 2006 11:54 a.m.
> Subject: [cgiapp] CGI::Application::Dispatch and FastCGI
>
> Hello all,
>
> Has any one before me Mixed Dispatch and FastCGI?
>
> It seems that the query object is getting cached. To el
Ron Savage wrote:
> Hi Michael
>
> The Synopsis has a sub called args_to_dispatch but it should be dispatch_args.
Thanks for catching that. It's fixed and will be in the next release (2.00)
--
Michael Peters
Developer
Plus Three, LP
--
Ron Savage wrote:
> Hi Michael
>
> I installed V 1.04 without error. Then I installed Test::LongString. Then...
>
> (1) Command: perl Build test
[snip]
> waiting 60 seconds for server to start:
> .
> waiting 60 seconds for server to star
> From: Michael Peters
> Sent: Friday, 4 November 2005 2:47 a.m.
>
> I have never used Persistent Perl so I won't be much help there, but
> here are some general suggestions:
> + Do you know where it's hanging? Try putting in lots of debug stuff
> to see if it's actually hanging in C::A::D or in
Dan Horne wrote:
> Hi
>
> I'm not sure if this is the correct place to raise this issue, but since
> some on the list use C::A and Persistent Perl, maybe they can help (the PP
> list seems dead).
>
> My problem is that over time, my instance script hangs when it uses
> Persistent Perl - it may
Hi Michael.
> So, if I understand you correctly, there are 2 reasons for this module.
>
> 1 - When you use C::A::Dispatch you can have links that actually go to a
> module/run_mode without explicitly specifying them because you can set
> the default in the application. And these links don't look l
Kensuke Kaneko wrote:
> Hello, everyone!
>
> I made a module named CGI::Application::Dispatch::BuildURI.
> This module resolve a relative URI path's problem when writing template
> files.
>
> When I use CGI::Application::Dispatch, I often confused by relative
> URI path difference.
> For exam
Hi Folks
Thanx for the responses.
Actually, I use registry scripts, but yes, the code will run under mod_perl, but
not as a native mod_perl handler.
Also, there was a problem with the version of Apache::Test, as discussed on the
mod_perl mailing list a few weeks ago, to do with Randy Kobes' Perl
On Fri, Mar 11, 2005 at 09:24:27AM -0500, Michael Peters wrote:
> It seems like Apache::Test is not working on your installation. Looking
> at the output from the test and you error log, it does not appear that
> it even reaches the C::A::Dispatch portions of the test.
FWIW, I've been using A::T
Ron Savage wrote:
Hi Michael
This gets into an infinite loop:
<-8><->
F:\perl-modules\CGI-Application-Dispatch-1.03>perl Build test
f:\Perl\bin\perl.exe -I F:\perl-modules\CGI-Application-Dispatch-1.03\blib\lib
-I F:\perl-modules\CG
I-Application-Dispatch-1.03\blib\arch t\TEST -clean
f:\Per
71 matches
Mail list logo
