Re: [Mason] Can't locate object method "new" via package "Apache::Request"
On Mon, 25 Aug 2003, K Old wrote: > On Mon, 2003-08-25 at 00:18, Randy Kobes wrote: > > On Sun, 24 Aug 2003, K Old wrote: [ ... ] > > > I did a "install HTML::Mason" from the CPAN command > > > line and all the dependencies were downloaded and some > > > didn't compile. The two that didn't are > > > Apache::Test-1.03 and libapreq-1.2. > > [ .. ] > > Regarding the failure of the tests in these two packages, > > what happens if you unpack, build, and test these as > > a non-root user, only becoming root to install them? > > There's some subtelties running the tests as root. > > Randy, > > Ok, yes, this worked...to a point! I pulled down fresh > copies of the modules from CPAN, unpacked, build and > tested with another user. All tests were successful with > Apache::Test with the normal user, but I had to go to root > for the tests for libapreq1.2 as my webserver needed the > root user to start FrontPage services. Is it possible to disable FrontPage just to see if the libapreq tests are OK when run as another user? > Doing the make test for > libapreq-1.2 all test fail and I get this in the t/logs/error_log: > > [Mon Aug 25 08:49:12 2003] [error] Can't load > '/home/admin/libapreq-1.2/blib/arch/auto/Apache/Cookie/Cookie.so' for > module Apache::Cookie: libapreq.so.1: cannot open shared object file: No > such file or directory at /usr/lib/perl5/5.6.1/i386-linux/DynaLoader.pm > line 206. [ ... ] > I've tried to install DynaLoader.pm from CPAN, but it says it's up to > date. That error message means that libapreq.so, which is required by Apache::Cookie, couldn't be loaded. Do you have a libapreq.so under /home/admin/libapreq-1.2/blib/? And if so, does it have the permissions set so that the user under which the web server is running as can load it? -- best regards, randy -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [Mason] Can't locate object method "new"via package "Apache::Request"
On Mon, 2003-08-25 at 14:45, Stas Bekman wrote: > K Old wrote: > > On Mon, 2003-08-25 at 13:13, Stas Bekman wrote: > > > >>K Old wrote: > >> > >>>On Mon, 2003-08-25 at 00:18, Randy Kobes wrote: > >>> > >>> > >>>>On Sun, 24 Aug 2003, K Old wrote: > >>>> > >>>> > >>>> > >>>>>Hello everyone, > >>>>> > >>>>>I've put HTML::Mason on a few servers now and have had problems with > >>>>>Apache::Request and Apache::Test on two of them. My most recent is > >>>>>having the problem and I'm about to go crazy if I don't figure out why > >>>>>installs keep having problems. > >>>>> > >>>>>Here's my setup: RH 7.2, Apache 1.3.27, mod_perl 1.26, Perl 5.6.1 - all > >>>>>installed from RPM's. > >>>>> > >>>>>I did a "install HTML::Mason" from the CPAN command line and all the > >>>>>dependencies were downloaded and some didn't compile. The two that > >>>>>didn't are Apache::Test-1.03 and libapreq-1.2. > >>>> > >>>>[ .. ] > >>>>Regarding the failure of the tests in these two packages, > >>>>what happens if you unpack, build, and test these as > >>>>a non-root user, only becoming root to install them? > >>>>There's some subtelties running the tests as root. > >>> > >>> > >>>Randy, > >>> > >>>Ok, yes, this worked...to a point! I pulled down fresh copies of the > >>>modules from CPAN, unpacked, build and tested with another user. All > >>>tests were successful with Apache::Test with the normal user, but I had > >>>to go to root for the tests for libapreq1.2 as my webserver needed the > >>>root user to start FrontPage services. Doing the make test for > >>>libapreq-1.2 all test fail and I get this in the t/logs/error_log: > >>> > >>>[Mon Aug 25 08:49:12 2003] [error] Can't load > >>>'/home/admin/libapreq-1.2/blib/arch/auto/Apache/Cookie/Cookie.so' for > >>>module Apache::Cookie: libapreq.so.1: cannot open shared object file: No > >>>such file or directory at /usr/lib/perl5/5.6.1/i386-linux/DynaLoader.pm > >>>line 206. > >>> at /usr/lib/perl5/site_perl/5.6.1/i386-linux/mod_perl.pm line 14 > >>>Compilation failed in require at > >>>/home/admin/libapreq-1.2/t/response/TestApReq/big_input.pm line 9. > >>>BEGIN failed--compilation aborted at > >>>/home/admin/libapreq-1.2/t/response/TestApReq/big_input.pm line 9. > >>>Compilation failed in require at (eval 4) line 3. > >> > >>That's a known linking problem. It has been fixed in the cvs, get the cvs > >>instructions from http://httpd.apache.org/apreq/. > >> > >>Joe, may be a new 1.x version should be released? > > > > > > Stas, > > > > I've downloaded the CVS, unpacked, built and tested with a not root > > user, and still received the same errors as before. > > > > Here's the syntax I'm using for build, etc: > > > > (CVS version) > > perl Makefile.PL > > make > > make test > > > > (Module from CPAN) > > perl Makefile.PL > > make > > make test > > > > then > > > > ./configure --with-apache-includes=/usr/include/apache > > make > > make install > > perl Makefile.PL > > make > > make test > > > > Is there anything I'm not doing right? > > > > I've tried to disable the FrontPage stuff so that the non root user > > should be able to start apache without the errors, but either by root or > > non root user I get the same error messages regarding Cookie.so and so > > forth. > > That probably means that my patches weren't applied. K Old, see > http://marc.theaimsgroup.com/?l=apreq-dev&m=105965131008577&w=2 > > Does it solve the problem for you? Stas, That did it! And to answer your question, no it doesn't look like your changes were committed. Thank you so much for your assistance with this! I really appreciate it! Kevin -- K Old <[EMAIL PROTECTED]> -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [Mason] Can't locate object method "new" via package"Apache::Request"
On Mon, 2003-08-25 at 00:18, Randy Kobes wrote: > On Sun, 24 Aug 2003, K Old wrote: > > > Hello everyone, > > > > I've put HTML::Mason on a few servers now and have had problems with > > Apache::Request and Apache::Test on two of them. My most recent is > > having the problem and I'm about to go crazy if I don't figure out why > > installs keep having problems. > > > > Here's my setup: RH 7.2, Apache 1.3.27, mod_perl 1.26, Perl 5.6.1 - all > > installed from RPM's. > > > > I did a "install HTML::Mason" from the CPAN command line and all the > > dependencies were downloaded and some didn't compile. The two that > > didn't are Apache::Test-1.03 and libapreq-1.2. > [ .. ] > Regarding the failure of the tests in these two packages, > what happens if you unpack, build, and test these as > a non-root user, only becoming root to install them? > There's some subtelties running the tests as root. Randy, Ok, yes, this worked...to a point! I pulled down fresh copies of the modules from CPAN, unpacked, build and tested with another user. All tests were successful with Apache::Test with the normal user, but I had to go to root for the tests for libapreq1.2 as my webserver needed the root user to start FrontPage services. Doing the make test for libapreq-1.2 all test fail and I get this in the t/logs/error_log: [Mon Aug 25 08:49:12 2003] [error] Can't load '/home/admin/libapreq-1.2/blib/arch/auto/Apache/Cookie/Cookie.so' for module Apache::Cookie: libapreq.so.1: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.6.1/i386-linux/DynaLoader.pm line 206. at /usr/lib/perl5/site_perl/5.6.1/i386-linux/mod_perl.pm line 14 Compilation failed in require at /home/admin/libapreq-1.2/t/response/TestApReq/big_input.pm line 9. BEGIN failed--compilation aborted at /home/admin/libapreq-1.2/t/response/TestApReq/big_input.pm line 9. Compilation failed in require at (eval 4) line 3. [Mon Aug 25 08:49:12 2003] [error] Undefined subroutine &TestApReq::big_input::handler called. [Mon Aug 25 08:49:12 2003] [error] Undefined subroutine &TestApReq::big_input::handler called. I've tried to install DynaLoader.pm from CPAN, but it says it's up to date. Any other suggests! Thanks for your help so far! Kevin -- K Old <[EMAIL PROTECTED]> -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
RE: Can't locate object method "new" via package "Apache::Request"
Ok, in the libapreq module I did the "configure" ./configure --with-apache-includes=/usr/includes/apache make make install Everything compiled just fine. Then did perl Makefile.PL && make && make test && make install All of the tests still failed and the t/logs/error_log still reported: [Sun Aug 24 23:01:32 2003] [info] Created shared memory segment #5275663 [Sun Aug 24 23:01:32 2003] [info] allocated semaphore #3768340 [Sun Aug 24 23:01:33 2003] [info] Created shared memory segment #5373967 [Sun Aug 24 23:01:33 2003] [info] allocated semaphore #3833876 [Sun Aug 24 23:01:33 2003] [info] created shared memory segment #5439505 Any advice how I proceed from here? Thanks Kevin On Sun, 2003-08-24 at 22:49, S.B.S wrote: > I ran into the same problem. What I had to do was compile libapreq as a > shared library first. That solved things nicely. > > HTH. > > Regards, > S. G. -- K Old <[EMAIL PROTECTED]> -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [Mason] Can't locate object method "new" via package "Apache::Request"
On Sun, 24 Aug 2003, K Old wrote: > Hello everyone, > > I've put HTML::Mason on a few servers now and have had problems with > Apache::Request and Apache::Test on two of them. My most recent is > having the problem and I'm about to go crazy if I don't figure out why > installs keep having problems. > > Here's my setup: RH 7.2, Apache 1.3.27, mod_perl 1.26, Perl 5.6.1 - all > installed from RPM's. > > I did a "install HTML::Mason" from the CPAN command line and all the > dependencies were downloaded and some didn't compile. The two that > didn't are Apache::Test-1.03 and libapreq-1.2. [ .. ] Regarding the failure of the tests in these two packages, what happens if you unpack, build, and test these as a non-root user, only becoming root to install them? There's some subtelties running the tests as root. -- best regards, randy kobes -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
RE: Can't locate object method "new" via package "Apache::Request"
I ran into the same problem. What I had to do was compile libapreq as a shared library first. That solved things nicely. HTH. Regards, S. G. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Can't locate object method "new" via package "Apache::Request"
Hello everyone, I've put HTML::Mason on a few servers now and have had problems with Apache::Request and Apache::Test on two of them. My most recent is having the problem and I'm about to go crazy if I don't figure out why installs keep having problems. Here's my setup: RH 7.2, Apache 1.3.27, mod_perl 1.26, Perl 5.6.1 - all installed from RPM's. I did a "install HTML::Mason" from the CPAN command line and all the dependencies were downloaded and some didn't compile. The two that didn't are Apache::Test-1.03 and libapreq-1.2. So, for Apache::Test I proceed to "make clean" and then do: perl Makefile.PL make make test /usr/bin/perl -Iblib/arch -Iblib/lib \ t/TEST -clean *** setting ulimit to allow core files ulimit -c unlimited; t/TEST -clean APACHE_USER= APXS= APACHE_PORT= APACHE_GROUP= APACHE= \ /usr/bin/perl -Iblib/arch -Iblib/lib \ t/TEST -verbose=0 *** setting ulimit to allow core files ulimit -c unlimited; t/TEST -verbose=0 *** root mode: changing the fs ownership to 'nobody' (99:99) /usr/sbin/httpd -X -d /root/.cpan/build/Apache-Test-1.03/t -f /root/.cpan/build/Apache-Test-1.03/t/conf/httpd.conf -DAPACHE1 using Apache/1.3.27 waiting for server to start: . waiting for server to start: ok (waited 0 secs) server localhost.localdomain:8529 started ping...ok requestFAILED tests 1, 5, 8-9 Failed 4/9 tests, 55.56% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- request.t 94 44.44% 1 5 8-9 *** server localhost.localdomain:8529 shutdown !!! error running tests (please examine t/logs/error_log) make: *** [run_tests] Error 1 [Sun Aug 24 21:16:49 2003] [info] Created shared memory segment #4259853 [Sun Aug 24 21:16:49 2003] [info] allocated semaphore #3112976 [Sun Aug 24 21:16:50 2003] [info] Created shared memory segment #4358157 [Sun Aug 24 21:16:50 2003] [info] allocated semaphore #3178512 [Sun Aug 24 21:16:50 2003] [info] created shared memory segment #4423695 I then did a make install and it installed the files, but they are broken. At any rate, I tried libapreq with the following: make clean perl Makefile.PL -httpd /usr/sbin/httpd generating script t/TEST Checking if your kit is complete... Looks good Writing Makefile for libapreq mkdir ../blib mkdir ../blib/arch mkdir ../blib/arch/auto mkdir ../blib/arch/auto/libapreq Warning: -L../blib/arch/auto/libapreq changed to -L/root/.cpan/build/libapreq-1.2/Request/../blib/arch/auto/libapreq Writing Makefile for Apache::Request Warning: -L../blib/arch/auto/libapreq changed to -L/root/.cpan/build/libapreq-1.2/Cookie/../blib/arch/auto/libapreq Writing Makefile for Apache::Cookie Writing Makefile for libapreq make make test make[1]: Entering directory `/root/.cpan/build/libapreq-1.2/c' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.2/c' make[1]: Entering directory `/root/.cpan/build/libapreq-1.2/Request' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.2/Request' make[1]: Entering directory `/root/.cpan/build/libapreq-1.2/Cookie' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.2/Cookie' /usr/bin/perl -Iblib/arch -Iblib/lib \ t/TEST -clean *** setting ulimit to allow core files ulimit -c unlimited; t/TEST -clean APACHE_USER= APXS= APACHE_PORT= APACHE_GROUP= APACHE= \ /usr/bin/perl -Iblib/arch -Iblib/lib \ t/TEST -verbose=0 *** setting ulimit to allow core files ulimit -c unlimited; t/TEST -verbose=0 *** root mode: changing the fs ownership to 'nobody' (99:99) /usr/sbin/httpd -X -d /root/.cpan/build/libapreq-1.2/t -f /root/.cpan/build/libapreq-1.2/t/conf/httpd.conf -DAPACHE1 using Apache/1.3.27 waiting for server to start: . waiting for server to start: ok (waited 0 secs) server localhost.localdomain:8529 started apreq/big_inputFAILED tests 1-21 Failed 21/21 tests, 0.00% okay apreq/cookie...FAILED test 1 Failed 1/1 tests, 0.00% okay apreq/inherit..FAILED test 1 Failed 1/1 tests, 0.00% okay apreq/request..FAILED tests 1-2 Failed 2/2 tests, 0.00% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- apreq/big_input.t 21 21 100.00% 1-21 apreq/cookie.t 11 100.00% 1 apreq/inherit.t 11 100.00% 1 apreq/request.t 22 100.00% 1-2 *** server localhost.localdomain:8529 shutdown !!! error running tests (please examine t/logs/error_log) make: *** [run_tests] Error 1 [Sun Aug 24 21:21:59
Re: Trouble with Apache::Request
On Fri, 1 Aug 2003, Jie Gao wrote: > Hi All, > > perl-5.8.0 + mp1.99_10. > --- > > I am having problem trying to get /perl-status work. > > It bombs out in Status.pm at the following location: > > ------ > if (eval {require Apache::Request}) { > $newQ ||= sub { Apache::Request->new(@_) }; > } > elsif (eval {require CGI}) { > $newQ ||= sub { CGI->new; }; > } > else { > die "Need CGI.pm or Apache::Request to operate"; > } > -------------- > > But shouldn't "Apache::Request" be "Apache::RequestRec"? Apache::Request is part of the libapreq package, a port of which to Apache2 is still being developed. best regards, randy kobes
Re: Trouble with Apache::Request
Hi All, perl-5.8.0 + mp1.99_10. --- I am having problem trying to get /perl-status work. It bombs out in Status.pm at the following location: -- if (eval {require Apache::Request}) { $newQ ||= sub { Apache::Request->new(@_) }; } elsif (eval {require CGI}) { $newQ ||= sub { CGI->new; }; } else { die "Need CGI.pm or Apache::Request to operate"; } -- But shouldn't "Apache::Request" be "Apache::RequestRec"? Sincerely, Jie
Re: Trouble with Apache::Request
Glenn E. Bailey III wrote: I had this exact same issue yesterday. I noticed that is was installing the libapreq.so.1 in /usr/local/lib and /usr/local/lib wasn't in my /etc/ld.so.conf file. Just add /usr/local/lib to your /etc/ld.so.conf file and then run "ldconfig" .. Worked for me and I was messing with the darn thing for about 3 hours. It shouldn't have installed it in first place. actually there are a few more patches on win32 that will go in soon. A new release will make those problems go away. . Glenn E. Bailey III . Sprocket Data, Inc. . http://www.sprocketdata.com : -Original Message- : From: Stas Bekman [mailto:[EMAIL PROTECTED] : Sent: Thursday, July 31, 2003 6:48 AM : To: K Old : Cc: ModPerl List : Subject: Re: Trouble with Apache::Request : : : >>On 6 Jun 2003, K Old wrote: : : [...] : : > Well, here are the errors I'm getting: : > : > When I *force* and install of Apache::Request and a script calls : > Apache::Request, this is in the error_log: [Fri Jun 6 : 17:27:31 2003] : > [error] Can't locate object method "new" via package : "Apache::Request" : > at : > : /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache/Request. : > pm : > line 22. : > : > This is from doing a make test when trying to install : Apache::Request : > manually: : > : > Syntax error on line 31 of : > /root/.cpan/build/libapreq-1.1/t/httpd.conf: : > Can't load : > : '/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/ : Request.so' for module Apache::Request: libapreq.so.1: cannot : open shared object file: No such file or directory at : /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229. : > at : /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/mod_perl.pm : > line 14 : > Compilation failed in require at (eval 16) line 3. : : This patch resolves this problem: : http://marc.theaimsgroup.com/?l=apreq-dev&m=105965131008577&w= 2 it should go in in the next release. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RE: Trouble with Apache::Request
I had this exact same issue yesterday. I noticed that is was installing the libapreq.so.1 in /usr/local/lib and /usr/local/lib wasn't in my /etc/ld.so.conf file. Just add /usr/local/lib to your /etc/ld.so.conf file and then run "ldconfig" .. Worked for me and I was messing with the darn thing for about 3 hours. . Glenn E. Bailey III . Sprocket Data, Inc. . http://www.sprocketdata.com : -Original Message- : From: Stas Bekman [mailto:[EMAIL PROTECTED] : Sent: Thursday, July 31, 2003 6:48 AM : To: K Old : Cc: ModPerl List : Subject: Re: Trouble with Apache::Request : : : >>On 6 Jun 2003, K Old wrote: : : [...] : : > Well, here are the errors I'm getting: : > : > When I *force* and install of Apache::Request and a script calls : > Apache::Request, this is in the error_log: [Fri Jun 6 : 17:27:31 2003] : > [error] Can't locate object method "new" via package : "Apache::Request" : > at : > : /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache/Request. : > pm : > line 22. : > : > This is from doing a make test when trying to install : Apache::Request : > manually: : > : > Syntax error on line 31 of : > /root/.cpan/build/libapreq-1.1/t/httpd.conf: : > Can't load : > : '/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/ : Request.so' for module Apache::Request: libapreq.so.1: cannot : open shared object file: No such file or directory at : /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229. : > at : /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/mod_perl.pm : > line 14 : > Compilation failed in require at (eval 16) line 3. : : This patch resolves this problem: : http://marc.theaimsgroup.com/?l=apreq-dev&m=105965131008577&w= 2 it should go in in the next release. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Trouble with Apache::Request
On 6 Jun 2003, K Old wrote: [...] Well, here are the errors I'm getting: When I *force* and install of Apache::Request and a script calls Apache::Request, this is in the error_log: [Fri Jun 6 17:27:31 2003] [error] Can't locate object method "new" via package "Apache::Request" at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache/Request.pm line 22. This is from doing a make test when trying to install Apache::Request manually: Syntax error on line 31 of /root/.cpan/build/libapreq-1.1/t/httpd.conf: Can't load '/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/Request.so' for module Apache::Request: libapreq.so.1: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229. at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/mod_perl.pm line 14 Compilation failed in require at (eval 16) line 3. This patch resolves this problem: http://marc.theaimsgroup.com/?l=apreq-dev&m=105965131008577&w=2 it should go in in the next release. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Question about Apache::Request and query strings
Tom Gazzini wrote: I have a perl function which, amongst other things, needs to redirect the request to another page. It also needs to pass all the query parameters of the original request (both GET and POST) to the redirected page, and also add one parameter of it's own (an error message). Sounds simple enough, but I'm having problems with the passing paramters bit. Here's what I have: sub show_error { my ($r, $error) = @_; # $r is an Apache:Request object passed by the caller my $uri = URI->new($url); foreach my $p (@params) { $uri->query_form($p => $r->param($p)); } $uri->query_form(error => $error); $r->internal_redirect($uri->canonical); } But this doesn't work. The '?error=' query string gets passed, but the orginal request query strings don't. What am I doing wrong? And is there an easier way? This example may help: http://perl.apache.org/docs/1.0/guide/snippets.html#Reusing_Data_from_POST_request __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::Request for CGI? (was: Re: A::Registry vs.mod_perlhandler philosophy)
On Wed, 2003-07-02 at 20:38, Andrew Ho wrote: > I totally agree with the fact that Apache::Registry can introduce many > hard-to-debug-problems. I've had enough headaches debugging some of these > issues myself. It's unclear to me, though, that there are unimaginably > cool things you can get to in a "real" content handler that you can't get > to from an Apache::Registry script I would phrase it differently and say that there are nice things you can do when you embrace the fact that you're in a persistent environment. You can do a lot of things in ways that are compatible with both CGI and mod_perl, by checking the environment and acting appropriately, but it can be a pain when you want to take advantage of cleanup handlers, preloaded data, persistent connections, etc. You can do all this from A::R, but once you've decided to write something that is not going to work under CGI I can't see any reason to use A::R anymore. At that point, it's just an artificial construct that adds complexity to your system. > I have found that often the Apache::Registry functionality of not having > to restart servers when simple scripts change is worth the potential of > bugs tickled by the Apache::Registry sub-wrap approach. People often say this. I just don't see it. Apache::Reload works just as well. My dev server restarts in about a second, so I always restart it when I make a change just to feel confident that I'm not seeing any residual effects from previous code. The whole reload thing is not perfect anyway, and people have had problems with A::R's reload when working with code that has closures in it. My opinion is that you should use A::R if you need CGI (or SpeedyCGI, etc.) compatibility, but use handlers otherwise. - Perrin
Re: Apache::Request for CGI? (was: Re: A::Registry vs. mod_perlhandlerphilosophy)
It's unclear to me, though, that there are unimaginably cool things you can get to in a "real" content handler that you can't get to from an Apache::Registry script--which seems to be the assertion. well, if you consider that you still get access to $r and all its treasures from Apache::Registry, then that's mostly true. > I > mean, even from the "lowest common denominator" CGI you can get all parts > of the incoming HTTP request, plus output arbitrary headers. it's when you use Apache::Registry as a wrapper for your legacy CGI scripts that the difference really begins to show. consider something like this http://www.perl.com/pub/a/2002/02/20/css.html while most templating systems don't have this issue with HTML entities, using the mod_perl API gives you ways of handling tasks like CSS protection behind the scenes. and I think that's unimaginably cool. other cool stuff comes at the end of this talk, http://www.modperlcookbook.org/~geoff/slides/ApacheCon/2002/oo-mod_perl-printable.ppt.gz which touches on Apache::Registry-as-legacy-CGI-wrapper limitations see also http://www.modperlcookbook.org/~geoff/modules/experimental/Apache-CachePOSTRegistry-0.01.tar.gz which handles the issue of merging legacy CGI Registry scripts with POST data issues and http://www.modperlcookbook.org/~geoff/modules/experimental/Apache-HEADRegistry-0.01.tar.gz which addresses the fact that Registry does not properly handle HEAD requests. given all of that but not wanting to speak for anyone else, I think that once you buy into the-mod_perl-API-is-better approach, there are really few reasons to use Registry over content handlers, as Registry adds an additional but unnecessary level of complexity and indirection. --Geoff
Re: Apache::Request for CGI? (was: Re: A::Registry vs. mod_perlhandlerphilosophy)
Hello, GY>mod_perl allows you to let your content handlers to focus on content - GY>all other parts of your application (authentication, session management, GY>proxying, URL rewriting tricks, etc) can programmed at the server level GY>via other parts of the request cycle. I think the question isn't "why is Apache::Registry not sufficient to handle all functions within an HTTP request" but "why is it bad to use Apache::Request specifically for the content generation phase?" Perrin had some good practical reasons for this--caused by the generated-namespace, sub-wrapped, eval'ed nature of Apache::Registry. I totally agree with the fact that Apache::Registry can introduce many hard-to-debug-problems. I've had enough headaches debugging some of these issues myself. It's unclear to me, though, that there are unimaginably cool things you can get to in a "real" content handler that you can't get to from an Apache::Registry script--which seems to be the assertion. I mean, even from the "lowest common denominator" CGI you can get all parts of the incoming HTTP request, plus output arbitrary headers. I have found that often the Apache::Registry functionality of not having to restart servers when simple scripts change is worth the potential of bugs tickled by the Apache::Registry sub-wrap approach. I think it's a fine tool for simple content generation scripts and that it doesn't limit you at all in that aspect. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer1-800-555-TELL Voice 650-930-9062 Tellme Networks, Inc. Fax 650-930-9101 --
Re: Apache::Request for CGI? (was: Re: A::Registry vs. mod_perlhandlerphilosophy)
Jesse Erlbaum wrote: Philippe -- Check out the guide: Check out the books: Check out the success stories: Is that your answer? I was hoping for specific examples, not hand-waving. I like to think that Part III (Chapters 11-17) of the mod_perl Developer's Cookbook does some of that. authentication is a good example of how mod_perl enables life outside of CGI scripting. if you require authentication in your application, auth handlers allow you to entirely remove authentication from your content handlers. mod_perl allows you to let your content handlers to focus on content - all other parts of your application (authentication, session management, proxying, URL rewriting tricks, etc) can programmed at the server level via other parts of the request cycle. I'm talking about this at a very basic level at OSCon this year (as I did last year), but you might be interested in my slides from YAPC2002 to get a general feel for it (and ApacheCon if you want to see the more twisted side of what mod_perl opens up). http://www.modperlcookbook.org/~geoff/slides/ HTH --Geoff
RE: Apache::Request for CGI? (was: Re: A::Registry vs. mod_perlhandler philosophy)
Philippe -- > Check out the guide: > Check out the books: > Check out the success stories: Is that your answer? I was hoping for specific examples, not hand-waving. -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
RE: Apache::Request for CGI? (was: Re: A::Registry vs. mod_perlhandler philosophy)
On Wed, 2003-07-02 at 22:36, Jesse Erlbaum wrote: > Hi Joe -- > > > +1. Scripting _inside_ the server opens up possibilities that > > are unimaginable to folks who are content confining themselves > > to the lowest common denominator (CGI). > > Perhaps you could bullet-point a few of these possibilities for those of > us who are confined by our lack of imagination? Check out the guide: http://perl.apache.org/guide/ Check out the books: http://perl.apache.org/docs/offsite/books.html Check out the success stories: http://perl.apache.org/outstanding/success_stories/index.html > > TTYL, > > -Jesse- > > > -- > > Jesse Erlbaum > The Erlbaum Group > [EMAIL PROTECTED] > Phone: 212-684-6161 > Fax: 212-684-6226 > > > > signature.asc Description: This is a digitally signed message part
RE: Apache::Request for CGI? (was: Re: A::Registry vs. mod_perl handler philosophy)
Hi Joe -- > +1. Scripting _inside_ the server opens up possibilities that > are unimaginable to folks who are content confining themselves > to the lowest common denominator (CGI). Perhaps you could bullet-point a few of these possibilities for those of us who are confined by our lack of imagination? TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
Apache::Request for CGI? (was: Re: A::Registry vs. mod_perl handler philosophy)
Perrin Harkins <[EMAIL PROTECTED]> writes: [...] > I'm late to the party, but here's an old post of mine that sums up my > opinion: > > http://marc.theaimsgroup.com/?l=apache-modperl&m=95440118003848&w=2 +1. Scripting _inside_ the server opens up possibilities that are unimaginable to folks who are content confining themselves to the lowest common denominator (CGI). That said, apreq-dev is looking for someone to adopt and develop the CGI port of libapreq-2/Apache::Request. I'm shooting for a developer release of libapreq-2 before OSCON, and it'd be _really_ cool if we had a functional CGI port available. -- Joe Schaefer
Re: Question about Apache::Request and query strings
Tom Where's @params coming from ? Are you sure it's not empty ? Swen |-+> | | "Tom Gazzini"| | | <[EMAIL PROTECTED]| | | uk> | | || | | 06/26/2003 04:42 | | | PM | | || |-+> >--| | | | To: <[EMAIL PROTECTED]> | | cc: | | Subject: Question about Apache::Request and query strings | | | | | >--| I have a perl function which, amongst other things, needs to redirect the request to another page. It also needs to pass all the query parameters of the original request (both GET and POST) to the redirected page, and also add one parameter of it's own (an error message). Sounds simple enough, but I'm having problems with the passing paramters bit. Here's what I have: sub show_error { my ($r, $error) = @_; # $r is an Apache:Request object passed by the caller my $uri = URI->new($url); foreach my $p (@params) { $uri->query_form($p => $r->param($p)); } $uri->query_form(error => $error); $r->internal_redirect($uri->canonical); } But this doesn't work. The '?error=' query string gets passed, but the orginal request query strings don't. What am I doing wrong? And is there an easier way? Thanks, Tom
Question about Apache::Request and query strings
I have a perl function which, amongst other things, needs to redirect the request to another page. It also needs to pass all the query parameters of the original request (both GET and POST) to the redirected page, and also add one parameter of it's own (an error message). Sounds simple enough, but I'm having problems with the passing paramters bit. Here's what I have: sub show_error { my ($r, $error) = @_; # $r is an Apache:Request object passed by the caller my $uri = URI->new($url); foreach my $p (@params) { $uri->query_form($p => $r->param($p)); } $uri->query_form(error => $error); $r->internal_redirect($uri->canonical); } But this doesn't work. The '?error=' query string gets passed, but the orginal request query strings don't. What am I doing wrong? And is there an easier way? Thanks, Tom
Re: apache::request parse() doesn't capture abort error
"Hector Pizarro" <[EMAIL PROTECTED]> writes: [...] > If the user closes the popup in the middle of an upload, Apache::Request > parse() isn't throwing any error, and all the following code in my module > savesthe file incomplete in the system, which of course is garbage data. > > Is this a bug, an incomplete feature, or is my configuration? It's probably a bug in c/apache_multipart_buffer.c. We may not do error-checking well enough on fill_buffer(). > If parse is supposed to return an error code, which one is that? 206 = > HTTP_PARTIAL_CONTENT? No, that's not an error code. Since the error here seems to arise from ap_get_client_block, $r->status should probably be -1. > Ok, now let's suppose that this error is fixed. With a patch, I hope ;-). > I want to do several uploads fromthe same popup at once, so I have 5 > file boxes in the form. If the user closesthe popup before the process > ends, i'd like to save only the completed files, how could I check > which files are correctly uploaded, and which ones are incomplete? You could just ignore the final upload object, which has no "-> next" pointer: for (my $u = $req->upload; $u && $u->next; $u = $u->next) { # do something with $u } -- Joe Schaefer
apache::request parse() doesn't capture abort error
Hello, first this is my configuration, all were installed by hand: - apache 1.3.27 - libapreq-1.1 - mod_perl 1.27 the users of this project can upload big files to the website (videos mostly). SoI use an html popup where a mod_perl handler receives the data, let's suppose its 100Mb. If the user closes the popup in the middle of an upload, Apache::Request parse() isn't throwing any error, and all the following code in my module savesthe file incomplete in the system, which of course is garbage data. Is this a bug, an incomplete feature, or is my configuration? If parse is supposed to return an error code, which one is that? 206 = HTTP_PARTIAL_CONTENT? Ok, now let's suppose that this error is fixed. I want to do several uploads fromthe same popup at once, so I have 5 file boxes in the form. If the user closesthe popup before the process ends, i'd like to save only the completed files, how could I check which files are correctly uploaded, and which ones are incomplete? Any help would be great people, thanks. -- Hector Pizarro Amautatech
an update on Apache::Request 2.0 progress
BTW, Apache::Request's 2.0 port is moving forward very fast thanks to Joe Schaefer's efforts. He is looking for help, at least with testing the perl glue. If you are interested to help, join the apreq-dev list: http://httpd.apache.org/apreq/ __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Trouble with Apache::Request
On Sun, 8 Jun 2003, K Old wrote: > On Sun, 2003-06-08 at 01:50, Randy Kobes wrote: > > On Fri, 7 Jun 2003, K Old wrote: > > [ .. ] > > > Stas, thanks for your reply. I downloaded the CVS source and > > > it still failed all tests. Below is the output from make test > > > and the output from perl -V. Any help is appreciated! > > > > Another thing that may be worth trying - if you've installed > > libapreq, try going back to the mod_perl sources and running > > those tests again. Do the modules/request.t and modules/cookie.t > > tests pass, or if not, do you receive the same errors? > > Well, I've recompile a fresh version of Perl 5.8.0 (without threads), > Apache, mod_perl and PHP and still no luckon that box. I have > another Mandrake 9.0 box and tried to compile the new libapreq that Stas > pointed to from CVS and got the following errors Any suggestions? > > I did: > > perl Makefile.PL -httpd /usr/sbin/httpd && make test > > And got: > > In file included from apache_request.c:59: > apache_request.h:5:19: httpd.h: No such file or directory [ .. ] Is /usr/sbin/httpd is a symbolic link to a real httpd, which could be something like /usr/local/httpd/bin/httpd? And is this httpd the one you compiled? If so, try giving the full path to this httpd as the Makefile.PL argument (there should be a /usr/local/httpd/include/ directory which has the header (.h) files that couldn't be found). -- best regards, randy
Re: Trouble with Apache::Request
On Sun, 2003-06-08 at 01:50, Randy Kobes wrote: > On Fri, 7 Jun 2003, K Old wrote: > [ .. ] > > Stas, thanks for your reply. I downloaded the CVS source and > > it still failed all tests. Below is the output from make test > > and the output from perl -V. Any help is appreciated! > > Another thing that may be worth trying - if you've installed > libapreq, try going back to the mod_perl sources and running > those tests again. Do the modules/request.t and modules/cookie.t > tests pass, or if not, do you receive the same errors? Well, I've recompile a fresh version of Perl 5.8.0 (without threads), Apache, mod_perl and PHP and still no luckon that box. I have another Mandrake 9.0 box and tried to compile the new libapreq that Stas pointed to from CVS and got the following errors Any suggestions? I did: perl Makefile.PL -httpd /usr/sbin/httpd && make test And got: In file included from apache_request.c:59: apache_request.h:5:19: httpd.h: No such file or directory apache_request.h:6:25: http_config.h: No such file or directory apache_request.h:7:23: http_core.h: No such file or directory apache_request.h:8:22: http_log.h: No such file or directory apache_request.h:9:23: http_main.h: No such file or directory apache_request.h:10:27: http_protocol.h: No such file or directory apache_request.h:11:25: util_script.h: No such file or dmake[1]: Leaving directory `/root/tmp/httpd-apreq/c' pache_request.h:38: parse error before "table" apache_request.h:38: warning: no semicolon at end of struct or union apache_request.h:47: parse error before '*' token apache_request.h:47: warning: data definition has no type or storage class apache_request.h:49: parse error before '}' token apache_request.h:49: warning: data definition has no type or storage class apache_request.h:56: parse error before "table" apache_request.h:56: warning: no semicolon at end of struct or union apache_request.h:57: warning: data definition has no type or storage class apache_request.h:59: parse error before '*' token apache_request.h:59: warning: data definition has no type or storage class apache_request.h:60: parse error before '}' token apache_request.h:90: parse error before '*' token apache_request.h:90: parse error before '*' token apache_request.h:90: warning: data definition has no type or storage class apache_request.h:91: parse error before '*' token apache_request.h:92: parse error before '*' token apache_request.h:93: parse error before '*' token apache_request.h:94: parse error before '*' token apache_request.h:95: parse error before '*' token apache_request.h:96: parse error before '*' token apache_request.h:96: parse error before '*' token apache_request.h:96: warning: data definition has no type or storage class apache_request.h:97: parse error before '*' token apache_request.h:98: parse error before '*' token apache_request.h:101: parse error before '*' token apache_request.h:101: parse error before '*' token apache_request.h:101: warning: data definition has no type or storage class apache_request.h:102: parse error before '*' token apache_request.h:102: parse error before '*' token apache_request.h:102: warning: data definition has no type or storage class apache_request.h:104: parse error before '*' token apache_request.h:104: parse error before '*' token apache_request.h:104: warning: data definition has no type or storage class apache_request.h:105: parse error before '*' token apache_request.h:124: parse error before '*' token apache_request.h:127: parse error before '*' token In file included from apache_request.c:60: apache_multipart_buffer.h:16: parse error before "request_rec" apache_multipart_buffer.h:16: warning: no semicolon at end of struct or union apache_multipart_buffer.h:29: parse error before '}' token apache_multipart_buffer.h:29: warning: data definition has no type or storage class apache_multipart_buffer.h:31: parse error before '*' token apache_multipart_buffer.h:32: parse error before "request_rec" apache_multipart_buffer.h:32: warning: data definition has no type or storage class apache_multipart_buffer.h:33: parse error before '*' token apache_multipart_buffer.h:33: parse error before '*' token apache_multipart_buffer.h:33: warning: data definition has no type or storage class apache_multipart_buffer.h:34: parse error before '*' token apache_multipart_buffer.h:35: parse error before '*' token apache_multipart_buffer.h:36: parse error before '*' token apache_request.c:61: parse error before '*' token apache_request.c:69: parse error before '*' token apache_request.c: In function `util_read': apache_request.c:71: `request_rec' undeclared (first use in this function) apache_request.c:71: (Each undeclared identifier is reported only once apache_request.c:71: for each function it appears in.) apache_request.c:71: request for member `r' in something not a structure or union apache_request.c:72: `OK' undeclared (first use in this function) apache_request.c:74: `REQUEST_CHUNKED_ERROR' undeclared
Re: Trouble with Apache::Request
On Fri, 7 Jun 2003, K Old wrote: [ .. ] > Stas, thanks for your reply. I downloaded the CVS source and > it still failed all tests. Below is the output from make test > and the output from perl -V. Any help is appreciated! Another thing that may be worth trying - if you've installed libapreq, try going back to the mod_perl sources and running those tests again. Do the modules/request.t and modules/cookie.t tests pass, or if not, do you receive the same errors? -- best regards, randy
RE: Trouble with Apache::Request
Hi there, (Replying to off-list post just this once:} On 6 Jun 2003, K Old wrote: > Mandrake 9.0 (and several other linux distros) come out of the box with > Perl 5.8.0 built with threads. Ah. For some reason I was thinking you'd built the Perl yourself. > I'm guessing that having Perl compiled with threads might be what's > causing the problem So are you telling me you built Apache and mod_perl but you didn't build the Perl? That could be a problem. The standard advice is that the same compiler must be used to build Perl and mod_perl. > Just this afternoon I build Apache::Request without any problems on > an RH 7.3 box with Perl 5.6.1 compiled without threads. Nothing wrong with 5.6.1 if you can use that. 73, Ged.
Re: Trouble with Apache::Request
[ CC'ing the apreq-dev list. In the future please post apreq build problems questions to the apreq-dev list: http://httpd.apache.org/apreq/ ] K Old, please try the httpd-apreq cvs version: I just did: % cd httpd-apreq % perl-5.8.0-ithread Makefile.PL -httpd /home/httpd/httpd_perl/bin/httpd && make test ... All tests successful. This version will be soon released on CPAN, it wasn't released yet due to some polishing of Apache::Test that is now used by Apache::Request for its test suite. Here is how to get the cvs version: % cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic login CVS password: anonymous % cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic co httpd-apreq % cd httpd-apreq % cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic co \ -d Apache-Test httpd-test/perl-framework/Apache-Test notice that in the example above, you need to adjust a path to your httpd and of course the path to perl, perl-5.8.0-ithread in my case is a symlink to perl-5.8.0 built with threads. If your problem still persists please post the output of your 'perl -V' that you have used to build Apache::Request __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RE: Trouble with Apache::Request
Hi Ged, On Fri, 2003-06-06 at 13:55, Ged Haywood wrote: > Hi there, > > On 6 Jun 2003, K Old wrote: > > > No, I didn't build a threaded Perl, it seems to be the popular thing > > among any linux distro these days to build it with threads. > > > > I'll build a version without threads just to see if it works > > Want to run that by me again?? > Mandrake 9.0 (and several other linux distros) come out of the box with Perl 5.8.0 built with threads. I'm guessing that having Perl compiled with threads might be what's causing the problem in getting Apache::Request installed. > > > I'm having trouble getting Apache::Request installed on my Mandrake 9.0 > [snip] > > > make test. I can force the install, but the same error comes up when I > > > try to load Apache::Request as a PerlModule in httpd.conf or when Alzabo > > > calls it. > > Is it *exactly* the same error? Well, here are the errors I'm getting: When I *force* and install of Apache::Request and a script calls Apache::Request, this is in the error_log: [Fri Jun 6 17:27:31 2003] [error] Can't locate object method "new" via package "Apache::Request" at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache/Request.pm line 22. This is from doing a make test when trying to install Apache::Request manually: Syntax error on line 31 of /root/.cpan/build/libapreq-1.1/t/httpd.conf: Can't load '/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/Request.so' for module Apache::Request: libapreq.so.1: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229. at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/mod_perl.pm line 14 Compilation failed in require at (eval 16) line 3. Still with the forced install of Apache::Request, if I try to call it from httpd.conf via PerlModule Apache::Request, I get this error. Syntax error on line 590 of /usr/local/apache/conf/httpd.conf: Can't load '/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Apache/Request/Request.so' for module Apache::Request: libapreq.so.1: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229. at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/mod_perl.pm line 14 Compilation failed in require at (eval 4) line 3. > > > > Any chance I should build perl without the threads? I've heard that can > > > be the cause of a lot of problems. > > Just Perl 5.8.0 can cause problems... do you have any others kicking around? > I'm thinking of 5.7.2 for example (ducks in case Stas throws something :) > which has done me good service. Wouldn't recommend 5.6.anything. I'm starting to agree. Just this afternoon I build Apache::Request without any problems on an RH 7.3 box with Perl 5.6.1 compiled without threads. Anyone else have Apache::Request running under Perl 5.8.0 with threads enabled? > > [snip] > > > t/httpd -f `pwd`/t/httpd.conf > > > Syntax error on line 31 of /root/.cpan/build/libapreq-1.1/t/httpd.conf: > > > Can't load > > > '/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/Request.so' \ > > > for module Apache::Request: libapreq.so.1: cannot open shared object file: \ > > > No such file or directory > [snip] > > Is there in fact no such file or directory? > The file Requests.so does exist and it is in the location being referenced. The permissions are 755. > I don't like that it's even looking in there... Are you building it all > as root? Bad idea generally, although -MCPAN does rather encourage it. Yeah, I hear ya on the CPAN thingI am building it as root, but have tried it as a regular user and get the same errors Any ideas? Thanks for your help, Kevin -- K Old <[EMAIL PROTECTED]>
Re: Trouble with Apache::Request
On Fri, 6 Jun 2003, K Old wrote: > Hello everyone, > > I'm having trouble getting Apache::Request installed on my > Mandrake 9.0 system. Let me first say that I'm not using the > Apache that came with Mandrake 9.0. I downloaded Apache > 1.3.27, mod_perl 1.27 and PHP 4.3.1 sources and compiled and > installed them. Everything works fine with Apache, mod_perl > and PHP, except when I need to use Apache::Request (trying to > use Alzabo browser interface). BTW, the version of Perl is > 5.8.0. > > When trying to build Apache::Request, here's what I get when I > do the make test. I can force the install, but the same error > comes up when I try to load Apache::Request as a PerlModule in > httpd.conf or when Alzabo calls it. > > I've scoured mailing list, Google groups and books and can't find any > help. > > Any chance I should build perl without the threads? I've heard that can > be the cause of a lot of problems. [ .. ] > t/httpd -f `pwd`/t/httpd.conf Syntax error on line 31 of > /root/.cpan/build/libapreq-1.1/t/httpd.conf: Can't load > '/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/Request.so' > for module Apache::Request: libapreq.so.1: cannot open shared > object file: No such file or directory at > /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line > 229. > at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/mod_perl.pm > line 14 > Compilation failed in require at (eval 16) line 3. > > Any help is greatly appreciated! If there's more than one Apache on your system, it may be that libapreq found the wrong one. Does it help any if you specify explicitly the desired Apache at the 'perl Makefile.PL' stage, as discussed in the install file of the distribution? -- best regards, randy kobes
RE: Trouble with Apache::Request
Hi there, On 6 Jun 2003, K Old wrote: > No, I didn't build a threaded Perl, it seems to be the popular thing > among any linux distro these days to build it with threads. > > I'll build a version without threads just to see if it works Want to run that by me again?? > > I'm having trouble getting Apache::Request installed on my Mandrake 9.0 [snip] > > make test. I can force the install, but the same error comes up when I > > try to load Apache::Request as a PerlModule in httpd.conf or when Alzabo > > calls it. Is it *exactly* the same error? > > Any chance I should build perl without the threads? I've heard that can > > be the cause of a lot of problems. Just Perl 5.8.0 can cause problems... do you have any others kicking around? I'm thinking of 5.7.2 for example (ducks in case Stas throws something :) which has done me good service. Wouldn't recommend 5.6.anything. [snip] > > t/httpd -f `pwd`/t/httpd.conf > > Syntax error on line 31 of /root/.cpan/build/libapreq-1.1/t/httpd.conf: > > Can't load > > '/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/Request.so' \ > > for module Apache::Request: libapreq.so.1: cannot open shared object file: \ > > No such file or directory [snip] Is there in fact no such file or directory? I don't like that it's even looking in there... Are you building it all as root? Bad idea generally, although -MCPAN does rather encourage it. 73, Ged.
RE: Trouble with Apache::Request
Kitch, No, I didn't build a threaded Perl, it seems to be the popular thing among any linux distro these days to build it with threads. I'll build a version without threads just to see if it works, as I'm out of things to try. Thanks, Kevin On Fri, 2003-06-06 at 12:39, Kitch, David wrote: > Did you do a threaded build of Perl 5.8.0? > You might try a non-threaded Perl build. > > Regards, > Kitch > [EMAIL PROTECTED] > > -Original Message- > From: K Old [mailto:[EMAIL PROTECTED] > Sent: Friday, June 06, 2003 11:27 AM > To: ModPerl List > Subject: Trouble with Apache::Request > > > Hello everyone, > > I'm having trouble getting Apache::Request installed on my Mandrake 9.0 > system. Let me first say that I'm not using the Apache that came with > Mandrake 9.0. I downloaded Apache 1.3.27, mod_perl 1.27 and PHP 4.3.1 > sources and compiled and installed them. Everything works fine with > Apache, mod_perl and PHP, except when I need to use Apache::Request > (trying to use Alzabo browser interface). BTW, the version of Perl is > 5.8.0. > > When trying to build Apache::Request, here's what I get when I do the > make test. I can force the install, but the same error comes up when I > try to load Apache::Request as a PerlModule in httpd.conf or when Alzabo > calls it. > > I've scoured mailing list, Google groups and books and can't find any > help. > > Any chance I should build perl without the threads? I've heard that can > be the cause of a lot of problems. > > make[1]: Entering directory `/root/.cpan/build/libapreq-1.1/c' > make[1]: Leaving directory `/root/.cpan/build/libapreq-1.1/c' > make[1]: Entering directory `/root/.cpan/build/libapreq-1.1/Request' > make[1]: Leaving directory `/root/.cpan/build/libapreq-1.1/Request' > make[1]: Entering directory `/root/.cpan/build/libapreq-1.1/Cookie' > make[1]: Leaving directory `/root/.cpan/build/libapreq-1.1/Cookie' > t/httpd -f `pwd`/t/httpd.conf > Syntax error on line 31 of /root/.cpan/build/libapreq-1.1/t/httpd.conf: > Can't load > '/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/Request.so > ' for module Apache::Request: libapreq.so.1: cannot open shared object > file: No such file or directory at > /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229. at > /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/mod_perl.pm > line 14 > Compilation failed in require at (eval 16) line 3. > > Any help is greatly appreciated!
RE: Trouble with Apache::Request
Did you do a threaded build of Perl 5.8.0? You might try a non-threaded Perl build. Regards, Kitch [EMAIL PROTECTED] -Original Message- From: K Old [mailto:[EMAIL PROTECTED] Sent: Friday, June 06, 2003 11:27 AM To: ModPerl List Subject: Trouble with Apache::Request Hello everyone, I'm having trouble getting Apache::Request installed on my Mandrake 9.0 system. Let me first say that I'm not using the Apache that came with Mandrake 9.0. I downloaded Apache 1.3.27, mod_perl 1.27 and PHP 4.3.1 sources and compiled and installed them. Everything works fine with Apache, mod_perl and PHP, except when I need to use Apache::Request (trying to use Alzabo browser interface). BTW, the version of Perl is 5.8.0. When trying to build Apache::Request, here's what I get when I do the make test. I can force the install, but the same error comes up when I try to load Apache::Request as a PerlModule in httpd.conf or when Alzabo calls it. I've scoured mailing list, Google groups and books and can't find any help. Any chance I should build perl without the threads? I've heard that can be the cause of a lot of problems. make[1]: Entering directory `/root/.cpan/build/libapreq-1.1/c' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.1/c' make[1]: Entering directory `/root/.cpan/build/libapreq-1.1/Request' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.1/Request' make[1]: Entering directory `/root/.cpan/build/libapreq-1.1/Cookie' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.1/Cookie' t/httpd -f `pwd`/t/httpd.conf Syntax error on line 31 of /root/.cpan/build/libapreq-1.1/t/httpd.conf: Can't load '/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/Request.so ' for module Apache::Request: libapreq.so.1: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229. at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/mod_perl.pm line 14 Compilation failed in require at (eval 16) line 3. Any help is greatly appreciated! -- K Old <[EMAIL PROTECTED]>
Trouble with Apache::Request
Hello everyone, I'm having trouble getting Apache::Request installed on my Mandrake 9.0 system. Let me first say that I'm not using the Apache that came with Mandrake 9.0. I downloaded Apache 1.3.27, mod_perl 1.27 and PHP 4.3.1 sources and compiled and installed them. Everything works fine with Apache, mod_perl and PHP, except when I need to use Apache::Request (trying to use Alzabo browser interface). BTW, the version of Perl is 5.8.0. When trying to build Apache::Request, here's what I get when I do the make test. I can force the install, but the same error comes up when I try to load Apache::Request as a PerlModule in httpd.conf or when Alzabo calls it. I've scoured mailing list, Google groups and books and can't find any help. Any chance I should build perl without the threads? I've heard that can be the cause of a lot of problems. make[1]: Entering directory `/root/.cpan/build/libapreq-1.1/c' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.1/c' make[1]: Entering directory `/root/.cpan/build/libapreq-1.1/Request' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.1/Request' make[1]: Entering directory `/root/.cpan/build/libapreq-1.1/Cookie' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.1/Cookie' t/httpd -f `pwd`/t/httpd.conf Syntax error on line 31 of /root/.cpan/build/libapreq-1.1/t/httpd.conf: Can't load '/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/Request.so' for module Apache::Request: libapreq.so.1: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229. at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/mod_perl.pm line 14 Compilation failed in require at (eval 16) line 3. Any help is greatly appreciated! -- K Old <[EMAIL PROTECTED]>
Subclassed Apache::Request Objects and their creation/destruction
All,I'm looking for some help with understanding how the Apache::Request objectsare created and destroyed.I have the following params set in my httpd.confKeepAlive OffPerlChildInitHandler Bficient::Apache::DBloadWhich as I understand it should mean that an apache::Request object iscreated for each request, and is destroyed at the end of a request.So if I add 'CREATION and DESTROY' warnings to my Apache::Request code tolog when a request is being created and destroyed I should see the objectsbeing created and destroyed as they are used.This would lead me to believe that when I stop apache, the only DESTROYmessages I should see are those belonging to the childInitHandler, e.g. Ishould see my database handles being destroyed.I'm just trying to get an understanding of what 'should' happen, so that Ican work out If I have a problem with my code.I have subclassed Apache::Request and I'm seeing my subclassedApache::Request objects being'DESTROYED' under an apache stop. AS WELL as after the Request completes,e.g.after the request completes I see this:-$VAR1 = bless( { 'r' => bless( do{\(my $o = 145326836)}, 'Apache::Request' ) }, 'Bficient::Apache::Request' );DESTROYING Bficient::Apache::RequestBut when I stop apache I see this:-$VAR1 = bless( { 'r' => undef }, 'Bficient::Apache::Request' );DESTROYING Bficient::Apache::RequestThis doesn't look 'right', but I'm not sure.Attached is my Bficient::Apache::Request object, If that helps.Any help, or pointers would be greatly appreciated,kind regardsMarty # #Module to sublass Apache to provide Custom Authorisation mechanisms #Using the Apache::Session objects for each user. # package Bficient::Apache::Request; use Bficient::Conf; use lib qw(Bficient::Conf::PERL_LIB_DIR); use Apache::Constants qw(OK REDIRECT SERVER_ERROR DECLINED FORBIDDEN); use Apache::Cookie; use Carp; use Apache::Reload; use Apache::Request; use Bficient::Maketext; use Data::Dumper; use base 'Exporter'; use Bficient::DBI; use Bficient::Apache::DBload qw($bdbh); use MIME::Base64 qw(encode_base64 decode_base64); use strict; @Bficient::Apache::Request::ISA = qw(Apache::Request); my $lh; sub new { my ($class, $r) = @_; #unless ($r) #{ #print STDERR "making a new Request object\n"; #$r = Apache::Request->new; #} my $self = bless {r => Apache::Request->new($r)}, $class; my @params=$self->param(); print STDERR "Here's the Parameters for $class\n"; print STDERR Dumper(@params); my $lang_id=$self->param('lang_id'); if ($lang_id) { #print STDERR "Using language_id of $lang_id\n"; $lh=Bficient::Maketext->get_handle($class,$lang_id); } else { #print STDERR "Using Default language_id of Bficient::Conf::DEFAULT_LANGUAGE_ID\nXX\n"; $lh=Bficient::Maketext->get_handle($class,Bficient::Conf::DEFAULT_LANGUAGE_ID); } #print STDERR "Creating ".ref($self)."\n"; #$self->interpret_uri; return $self; } sub DESTROY { my $self=shift; print STDERR Dumper($self); print STDERR "DESTROYING ".ref($self)."\n"; #$self->SUPER->DESTROY(); } sub current_db_id { my $self=shift; my $db_id; if($self->param('db_id')) { $db_id=$self->param('db_id'); die $self->lh->maketext("Empty database ID string Used in Parameters\n") unless $db_id; } else { my $current_plugin=$self->current_plugin; #print STDERR Dumper($current_plugin); my $current_plugin_id=$current_plugin->id; #print STDERR "PluginID='$current_plugin_id'\n"; my $database=Bficient::Database->new({_load_default_plugin_database=>$current_plugin_id,dbh=>$bdbh,lang_id=>$self->lang_id}); $db_id=$database->id; } return $db_id; } #sub make_plugin_html #{ #my $self=shift; #my $tt_href=shift; # #my $html=''; # #my $db_id=$self->current_db_id; # #my $tt_file = Bficient::Conf::FRAMEWORK_TOPBAR_TEMPLATE; #$tt_file=~s/\/\//\//; #my $template = Template->new(Bficient::Conf::TT2_CONFIG); #my @[EMAIL PROTECTED]::Plugin->all({dbh=>$bdbh})}; ##print STDERR Dumper (@plugins); #my @non_admin=(); #foreach my $plugin (@plugins) #{ #if ($plugin->Name eq Bficient::Conf::ADMIN_PLUGIN_NAME ) #{ #$tt_href->{admin_plugin}=$plugin; #} #else #{ #push @non_admin, $plugin; #} #} # #$tt_href->{r}=$self; #$tt_href->[EMAIL PROTECTED]; #$tt_href->{plugin_count}=scalar(@non_a
Re: Apache::Request
Ewald Geschwinde wrote: I have read that the param Method had been deprecated $r->param('value'): How do I get now the variables from a submitted form ?? now? when? nothing has changed with Apache::Request. No April Fools jokes here. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Apache::Request
I have read that the param Method had been deprecated $r->param('value'): How do I get now the variables from a submitted form ?? regards Ewald
Re: the deprecation of Apache->request in mp2
Hello, NT>I sure hope not! I second John Siracusa's post on this. Keep the HTML NT>generation well away from request parsing, please! I personally am 100% in the camp of keeping HTML generation separate from quest parsing, but I do recognize the advantage of having API level compatibility between Apache::Request and CGI, so that you could switch from one to another easily. I think this would be a big win for mod_perl overall from the "port your scripts quickly" point of view. I think a good compromise would be to keep the HTML generation code in an entirely separate module, like Apache::Request::HTML or something. That class could augment Apache::Request with new methods. (This is somewhat similar to how Apache::File and Apache::Log augment the Apache class with new methods.) This seems to satisfy both sides, and accomplish the laudable goal of making CGI and Apache::Request API compatible without bloating up the normal use of Apache::Request. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer1-800-555-TELL Voice 650-930-9062 Tellme Networks, Inc. Fax 650-930-9101 --
Re: the deprecation of Apache->request in mp2
On Tue, 25 Mar 2003, Stas Bekman wrote: > Lincoln Stein wrote: > >>How about making CGI.pm a subclass of $r? (optionally of course, by > >>dynamically changing @ISA), so instead of returning $q it'll return $r, > >>after re-blessing it. > > > > > > Sounds interesting. What would be the advantage of that? > > The advantage is that > - you don't have to keep around two instances: $r and $q. > - assuming that CGI.pm-specific code is not used one can transparently switch > between Apache::Request and CGI.pm, by just changing: > > $r = Apache::Request->new($r); > $r = CGI->new($r); > > And of course Apache::Request is a subclass of Apache ($r) and it works pretty > well. > > In the future I can see someone extending Apache::Request to handle CGI.pm's > HTML generation in C, so the two could be replace each other. I sure hope not! I second John Siracusa's post on this. Keep the HTML generation well away from request parsing, please! - nick -- Nick Tonkin {|8^)>
Re: the deprecation of Apache->request in mp2
I suppose there might be name clashes, but I'll look into doing that. Lincoln On Monday 24 March 2003 07:08 pm, Stas Bekman wrote: > Lincoln Stein wrote: > >>How about making CGI.pm a subclass of $r? (optionally of course, by > >>dynamically changing @ISA), so instead of returning $q it'll return $r, > >>after re-blessing it. > > > > Sounds interesting. What would be the advantage of that? > > The advantage is that > - you don't have to keep around two instances: $r and $q. > - assuming that CGI.pm-specific code is not used one can transparently > switch between Apache::Request and CGI.pm, by just changing: > > $r = Apache::Request->new($r); > $r = CGI->new($r); > > And of course Apache::Request is a subclass of Apache ($r) and it works > pretty well. > > In the future I can see someone extending Apache::Request to handle > CGI.pm's HTML generation in C, so the two could be replace each other. > > __ > Stas BekmanJAm_pH --> Just Another mod_perl Hacker > http://stason.org/ mod_perl Guide ---> http://perl.apache.org > mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com > http://modperlbook.org http://apache.org http://ticketmaster.com -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY
Re: the deprecation of Apache->request in mp2
On 3/24/03 7:08 PM, Stas Bekman wrote: > In the future I can see someone extending Apache::Request to handle CGI.pm's > HTML generation in C, so the two could be replace each other. I've always thought that HTML generation does not belong in CGI.pm, so I don't see duplicating that functionality in an extended $r as a useful goal. Better to separate the HTML stuff (preferably into HTML widget objects, IMO) from request parsing and response formulation and delivery. -John
Re: the deprecation of Apache->request in mp2
Lincoln Stein wrote: How about making CGI.pm a subclass of $r? (optionally of course, by dynamically changing @ISA), so instead of returning $q it'll return $r, after re-blessing it. Sounds interesting. What would be the advantage of that? The advantage is that - you don't have to keep around two instances: $r and $q. - assuming that CGI.pm-specific code is not used one can transparently switch between Apache::Request and CGI.pm, by just changing: $r = Apache::Request->new($r); $r = CGI->new($r); And of course Apache::Request is a subclass of Apache ($r) and it works pretty well. In the future I can see someone extending Apache::Request to handle CGI.pm's HTML generation in C, so the two could be replace each other. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: the deprecation of Apache->request in mp2
> How about making CGI.pm a subclass of $r? (optionally of course, by > dynamically changing @ISA), so instead of returning $q it'll return $r, > after re-blessing it. Sounds interesting. What would be the advantage of that? Lincoln > > > The other issue is that it will only work with the OO form of CGI, which > > many people (including myself) don't use. > > You can still have an accessor function to set $r: > > use CGI; > CGI->r($r); > > > I would prefer a more transparent way to obtain the current request. Is > > there no low-overhead way of getting at this? > > Not, under threaded mpm. Since the code should work the same with threaded > and non-threaded mpm, it's a problem for any 2.0 code. The problem with > Apache->request is that it involves storing and retrieving data from the > TLS (thread local storage), which is slow. So while the functionality is > there, sites that are looking for high performance will want to pass $r, > rather than rely on Apache->request. > > Of course one can argue, that sites looking for high performance should use > Apache::Request (which is not quite there yet, for 2.0). So if this > argument is valid and you don't feel like changing the API, that's cool > too. May be in the future. > > __ > Stas BekmanJAm_pH --> Just Another mod_perl Hacker > http://stason.org/ mod_perl Guide ---> http://perl.apache.org > mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com > http://modperlbook.org http://apache.org http://ticketmaster.com -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY
Re: the deprecation of Apache->request in mp2
Lincoln Stein wrote: I can do this (changing the new() call to accept $r). My understanding is that client code will need to be changed to take advantage of this, right? That's correct. $r should be explicitly passed. However the CGI-side code doesn't have to specific to mod_perl 2.0. CGI should be able to do that with either version of mod_perl. In this case the user code can be ported to work with both versions of mod_perl. How about making CGI.pm a subclass of $r? (optionally of course, by dynamically changing @ISA), so instead of returning $q it'll return $r, after re-blessing it. The other issue is that it will only work with the OO form of CGI, which many people (including myself) don't use. You can still have an accessor function to set $r: use CGI; CGI->r($r); I would prefer a more transparent way to obtain the current request. Is there no low-overhead way of getting at this? Not, under threaded mpm. Since the code should work the same with threaded and non-threaded mpm, it's a problem for any 2.0 code. The problem with Apache->request is that it involves storing and retrieving data from the TLS (thread local storage), which is slow. So while the functionality is there, sites that are looking for high performance will want to pass $r, rather than rely on Apache->request. Of course one can argue, that sites looking for high performance should use Apache::Request (which is not quite there yet, for 2.0). So if this argument is valid and you don't feel like changing the API, that's cool too. May be in the future. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: the deprecation of Apache->request in mp2
I can do this (changing the new() call to accept $r). My understanding is that client code will need to be changed to take advantage of this, right? The other issue is that it will only work with the OO form of CGI, which many people (including myself) don't use. I would prefer a more transparent way to obtain the current request. Is there no low-overhead way of getting at this? Lincoln On Thursday 13 March 2003 07:00 pm, Stas Bekman wrote: > One more issue with CGI.pm and mp2, and other modules as well. > > CGI.pm is using Apache->request. The setting/retrieval of the global > request record under threads is expensive, so the use of Apache->request is > deprecated in mp2. > > If CGI.pm can be changed to optionally accept $r (as an argument to new(), > plus a special accessor to set later) and use it instead, this will improve > the performance if Apache->request is not set. > > Notice that it's the enabling of 'PerlOptions +GlobalRequest' (it's on by > default with 'SetHandler perl-script') that is half of the performance hit > (store), and the actual use of Apache->request (get) is the second half. > > See: > http://perl.apache.org/docs/2.0/user/compat/compat.html#C_Apache_E_gt_reque >st_ http://perl.apache.org/docs/2.0/user/config/config.html#C_GlobalRequest_ > > __ > Stas BekmanJAm_pH --> Just Another mod_perl Hacker > http://stason.org/ mod_perl Guide ---> http://perl.apache.org > mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com > http://modperlbook.org http://apache.org http://ticketmaster.com -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY
Re: Apache::Request: analyse output.
Andrew Alakozow wrote: Hello, I use Apache::FakeRequest to test perl handlers without firing up Apache. Testting is supposed to be done by matching output of handlers with some regexps. But the print method of Apache::Request prints to STDOUT, so to get output I applied following patch to it: 10c10,17 < sub print { shift; CORE::print(@_) } --- sub print { my $self = shift; if (exists $$self{fr_output}) { $$self{fr_output} .= join ('', @_); } else { CORE::print(@_) } } Now, if fr_output "method" is defined all output comes there. my $request = Apache::FakeRequest->new(fr_output => '', ...); If it's "right thing" may be this patch should go to CPAN, and if it's not "right", I'll be glad to hear how to do it right. You can use IO::String for this purpose: http://perl.apache.org/docs/1.0/guide/porting.html#Redirecting_STDOUT_into_a_Scalar __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Apache::Request: analyse output.
Hello, I use Apache::FakeRequest to test perl handlers without firing up Apache. Testting is supposed to be done by matching output of handlers with some regexps. But the print method of Apache::Request prints to STDOUT, so to get output I applied following patch to it: 10c10,17 < sub print { shift; CORE::print(@_) } --- > sub print { > my $self = shift; > > if (exists $$self{fr_output}) { > $$self{fr_output} .= join ('', @_); > } else { CORE::print(@_) } > > } Now, if fr_output "method" is defined all output comes there. my $request = Apache::FakeRequest->new(fr_output => '', ...); If it's "right thing" may be this patch should go to CPAN, and if it's not "right", I'll be glad to hear how to do it right. Thanks. aa29
the deprecation of Apache->request in mp2
One more issue with CGI.pm and mp2, and other modules as well. CGI.pm is using Apache->request. The setting/retrieval of the global request record under threads is expensive, so the use of Apache->request is deprecated in mp2. If CGI.pm can be changed to optionally accept $r (as an argument to new(), plus a special accessor to set later) and use it instead, this will improve the performance if Apache->request is not set. Notice that it's the enabling of 'PerlOptions +GlobalRequest' (it's on by default with 'SetHandler perl-script') that is half of the performance hit (store), and the actual use of Apache->request (get) is the second half. See: http://perl.apache.org/docs/2.0/user/compat/compat.html#C_Apache_E_gt_request_ http://perl.apache.org/docs/2.0/user/config/config.html#C_GlobalRequest_ __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::Request incompatible with CGI ?
dorian wrote: > aiya. libapreq 0.31 is the one that likes to append whatever it is that one just uploaded > to it to its heap until it starves your machine of memory, if i recall correctly. it was > fixed in 0.31_03 i believe but it looks like 1.1 was released last week. I have found 1.1 on CPAN and this seems to fix my problems. I'm not sure why I didn't find the newer version first off (I only made this change in the last few days and downloaded Apache::Request). Thanks for everyone's help ! Rob Lambden
Re: Apache::Request incompatible with CGI ?
> I downloaded Apache::Request from CPAN and I have version 0.31. My C > compiler is gcc 2.96 aiya. libapreq 0.31 is the one that likes to append whatever it is that one just uploaded to it to its heap until it starves your machine of memory, if i recall correctly. it was fixed in 0.31_03 i believe but it looks like 1.1 was released last week. .dorian
Apache::Request incompatible with CGI ?
(Originally posted as Apache::Registry incompatible with CGI? by mistake - sorry !) Hi, I have written a request handler in Perl. I recently changed some code in this to convert from using CGI within mod_perl to using Apache::Request. The old code was ... $DB->{ApacheReq} = shift; : $DB->{Page} = CGI::new(); : The new code is ... : $DB->{ApacheReq}= Apache::Request->new(shift); : $DB->SetupPageArguments(); : sub SetupPageArguments() { my ($DB, $nLoop, @Query, $Key, $Value); $DB=shift; @{$DB->{Page}->{'.parameters'}}=$DB->{ApacheReq}->param(); for($nLoop=0; $nLoop<=$#{$DB->{Page}->{'.parameters'}}; $nLoop++) { if(!defined($DB->{ApacheReq}->param($DB->{Page}->{'.parameters'}[$nLoop] ))) { $DB->{Page}->{$DB->{Page}->{'.parameters'}[$nLoop]}[0]=''; } else { @{$DB->{Page}->{$DB->{Page}->{'.parameters'}[$nLoop]}}=$DB->{ApacheReq}- >param($DB->{Page}->{'.parameters'}[$nLoop]); } } } My handler then referes to the '.parameters' field and the arrays of values. For most posts this works fine. However, when I send a large block of data in with the request I have found that portions of the middle are left out. Putting the old code back means that the whole of the text is seen. I am using a client program written in C++ to send the requests in. All requests are sent as a multipart message, with each form field having one part within the message. On the particular instance I have been looking at the overall content size for the request (excluding the header) in my application is set to 21555. (I have not set the flag to limit post size as you can see from the above). The end of the request appears as follows (This request happens to conatin Javascript, but the content should be irrelevant as it has not been processed by anything at this stage) ... : : : function NewProductExtension(Id, ExtensionId, Description, MinRequired, MaxRequired, Visible, WarnLessThan, WarnGreaterThan, LessThanWarning, GreaterThanWarning, Width, Units)\n{\n new ProductExtension(Id, ExtensionId, Description, MinRequired, MaxRequired, Visible, WarnLessThan, WarnGreaterTha<*>ion CheckProductExtensions() { var nLoop; var Rc=new String(''); for(nLoop=0; nLoopProducts[nLoop].Extensions.length) { Rc=Rc+(Products[nLoop].ProductId+','); } } Rc=Rc.substr(0, Rc.length-1); return(Rc); } where <*> denotes the portion that is missing (about 100 lines or so) I also sometimes see spurious data added after the request. My server is running linux 2.4.18 on a two-way Intel box. I have Apache 1.3.26 / mod_perl 1.27 I downloaded Apache::Request from CPAN and I have version 0.31. My C compiler is gcc 2.96 I have not been able to run a LAN trace to see what's being sent, but since it is OK with CGI.pm I assume that I am sending what my client says I'm sending. Unfortunately I do not understand how the C / Perl and XS files all stitch together so my attempts to look at the code have not been fruitful. I have adopted some code that works neatly under the Apache::Request but will have to be fudged to work with CGI so I am keen to get this working. Can anyone help ? Rob Lambden
Re: [mp2] Apache::Request
On Fri, 31 Jan 2003, Lee Goddard wrote: > Does anyone know when this module might be released? No, no one does. They are working on it. Use CGI.pm instead or revert to mod_perl/apache version 1 until it is done. - nick Nick Tonkin {|8^)>
[mp2] Apache::Request
-BEGIN PGP SIGNED MESSAGE- Hash: MD5 Does anyone know when this module might be released? tia lee Lee Goddard mailto:[EMAIL PROTECTED] "What do people like to drink here, then?" The landlord looked sideways at his customers, a clever trick given that they were directly in front of him. - - Mort goes out for a drink (Terry Pratchett, Mort) -BEGIN PGP SIGNATURE- Version: 2.6 iQCVAwUAPjqOSadrfekeF/QBAQFAxAQAhMyxXG/Tn/xoXY0+FzpAKBtuyymyQXz1 nnQXo3+nxopl6llRGTWF9gbi/euiqeQm2iHXx+ifgulbA2p3CJt2MKL/OsQ33Ygp M6tIRz9TvXdPIZGT/HGZ2ToPnO2c5O9EH5ZVmmMhnbWAmwJK+gBWAA6wgSVasLPX fFFRUWZKKRI= =Bpad -END PGP SIGNATURE-
Re: mp2.0 Apache::Request
Steve wrote: In the documentation of nodperl-2.0, I cannot find any references to libapreq and $r->param. Because it's not there yet. correct me if I'm wrong anyone,but I don't think Apache::Request has been ported to modperl2 yet.. True. The C porting of libapreq is almost complete. The Perl glue will come next. (A few months?) for now I'm using cgi Steve probably means CGI.pm ;0) Though make sure that you use the latest version if you want to run it under mod_perl 2.0. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mp2.0 Apache::Request
> In the documentation of nodperl-2.0, I cannot find any references to > libapreq and $r->param. correct me if I'm wrong anyone,but I don't think Apache::Request has been ported to modperl2 yet.. for now I'm using cgi
mp2.0 Apache::Request
Hi. I use apache-1.3.26, modperl-1.27 and Embperl-1.3 with libapreq-1.0 and I have a routine in perl that processes the data passed from a form (from the Modperl Cookbook): use Apache::Request; my $r = Apache::Request->instance(Apache->request); foreach $param ($r->param) { . } In the documentation of nodperl-2.0, I cannot find any references to libapreq and $r->param. Does anybody know how I can process the data in modperl-2.0? Thanks. R. Amer Polythecnic University of Catalonia
Re: passing Apache::Request object
Marc Lambrichs wrote: Hi All, I want to save my Apache::Request object in an PerlInitHandler called Initialization and later on during the life cycle of the request call a Initialization->get_request() method to use it again. perldoc Apache::Request: instance The instance() class method allows Apache::Request to be a singleton. This means that whenever you call Apache::Request->instance() within a single request you always get the same Apache::Request object back. This solves the problem with creating the Apache::Request object twice within the same request - the symptoms being that the second Apache::Request object will not contain the form parameters because they have already been read and parsed. my $apr = Apache::Request->instance($r, DISABLE_UPLOADS => 1); [... more in the manpage ...] __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
passing Apache::Request object
Hi All, I want to save my Apache::Request object in an PerlInitHandler called Initialization and later on during the life cycle of the request call a Initialization->get_request() method to use it again. How can I do this in a safe manner? If you're wondering, why I would want to do this, take a look at Perrin Harkins perl.com article about etoys. Cheers, Marc
Re: Migrating from CGI.pm to Apache::Request question.
Jesse Erlbaum wrote: Hi Coexec -- I am experienced with using the CGI.pm, and now I want to rewrite all of my CGI's using mod_perl and Apache::Request. Maybe a silly question: What are you hoping to gain by doing this? Speed. Apache::Request's guts are implemented in C, CGI.pm is Perl. If you do a lot of processing the speed improvement is significant. See: http://perl.apache.org/docs/1.0/guide/performance.html#Apache__args_vs__Apache__Request__param_vs__CGI__param _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
RE: Migrating from CGI.pm to Apache::Request question.
Hi Coexec -- > I am experienced with using the CGI.pm, and now I want > to rewrite all of my CGI's using mod_perl and > Apache::Request. Maybe a silly question: What are you hoping to gain by doing this? If you're already using Apache::Registry, then your CGI.pm apps are ALREADY running as mod_perl modules. The move from CGI.pm to Apache::Request, in this case, is not likely to give you any real speed advantage. As you've pointed out, Apache::Request is only a partial replacement for CGI.pm. Ken suggested that you could continue to use CGI.pm in addition to Apache::Request if you need the functionality. If you choose to do so you will be using even MORE code than CGI.pm alone. More code means more memory, at very least -- not to mention the complexity of the system. Finally, you have to throw away all that time you spent learning the finer points of CGI.pm, and spend time learning the finer points of Apache::Request. Multiply that by the number of developers you have. I see that a few people have been doing this over the years, but I still don't see the advantage. Other than the Siren call of "don't use CGI.pm -- it's evil", I can't imagine that Apache::Request has any really compelling advantages. Personally, I use CGI.pm (via CGI::Application) for my applications and straight mod_perl handlers for low-level functionality such as authentication, authorization and custom logging. This allows the majority of my developers, who are engaged in writing application code (the vast majority of the work on the typical project), to leverage their expertise. More advanced mod_perl hacks work on the "heavy lifting" handlers, which are few and far between. On a related topic, I strongly agree with Ken that you should move your HTML generation into a templating system. HTML::Template is my personal preference. I use H::T in conjunction with CGI::Application to implement all my web apps. FWIW, CGI::Application works equally well with Template Toolkit, if that's your preference. Warmest regards, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
Re: Migrating from CGI.pm to Apache::Request question.
On Tue, 19 Nov 2002, Coexec wrote: > Date: Tue, 19 Nov 2002 15:40:37 -0800 (PST) > From: Coexec <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Migrating from CGI.pm to Apache::Request question. > > Hello all, I have been searching through the mailing > list archives for the answer to my question, but I > have not found it. > > I am experienced with using the CGI.pm, and now I want > to rewrite all of my CGI's using mod_perl and > Apache::Request. According to everything that I have > been reading, the Apache::Request module handles only > GET, POST and Cookie data, and no HTML. Basically, my > question is, what is the most commonly used module for > generating HTML like the CGI.pm does ? > > Thanks There are so many different ways to handle HTML generation that it will make your head spin. You're always welcome to continue using CGI.pm's methods for generating HTML, but that usually couples the logic and presentation of your application so tightly that it makes for less-than-maintainable code -- less than what, however, remains the question. Many people like to use templating systems (HTML::Template, Template::Toolkit), some like to use more all-inclusive packages (Mason, Apache::ASP, Embperl), some people just use "print" statements (arguably the worst choice). Asking what is the most common way people on this list won't likely generate a consensus; ask 10 people how they do this and you'll probably get 10 different answers. As for me, I'm quite partial to Template::Toolkit. You'll have to decide what works best for you. No need to use a sledgehammer to drive a finishing nail. Use whatever tool is the simplest to use for your situation, but no simpler. :-) ky
Migrating from CGI.pm to Apache::Request question.
Hello all, I have been searching through the mailing list archives for the answer to my question, but I have not found it. I am experienced with using the CGI.pm, and now I want to rewrite all of my CGI's using mod_perl and Apache::Request. According to everything that I have been reading, the Apache::Request module handles only GET, POST and Cookie data, and no HTML. Basically, my question is, what is the most commonly used module for generating HTML like the CGI.pm does ? Thanks __ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.yahoo.com
Re: Apache::Request + Apache::Filter
Hello, We use this patch (on Apache::Filter 1.019) and it works ok. It won't get you up and running with Apache::Registry, but it will do if you can initialize the filter yourself. Add this to Filter.pm: sub Apache::Request::filter_register { my $r= shift; @ISA = qw(Apache::Request); Apache::filter_register ($r); } Here is the usage in your own code (this is slightly subtle): my $old_r = Apache->request(); my $filtered_r = Apache::Request->instance($old_r)->filter_register(); That should do the trick. There is probably a cleaner way to do it, but this has worked for us. John On Tuesday, November 12, 2002, at 02:22 PM, Richard Clarke wrote: List, Can anyone tell me if a module exists that combines these two modules so that, for example, when using Apache::Dispatch one can create an instance of Apache::Request in the handler without clobbering the overridden methods sent as part of the Apache::Filter object. Before I try and do this I wondered if it had already been done? Apache::RequestFilter would make sense to me but something like this doesn't seem to exist on CPAN. Ric
Apache::Request + Apache::Filter
List, Can anyone tell me if a module exists that combines these two modules so that, for example, when using Apache::Dispatch one can create an instance of Apache::Request in the handler without clobbering the overridden methods sent as part of the Apache::Filter object. Before I try and do this I wondered if it had already been done? Apache::RequestFilter would make sense to me but something like this doesn't seem to exist on CPAN. Ric
RE: Can't locate object method "new" via package "Apache::Request" (via Mason)...SOLVED
It's hard to generalize because in some cases the shared object file may actually not be installed. However, there should probably be something in the documentation that tells the user to make sure that the LD_LIBRARY_PATH variable and/or the /etc/ld.so.conf file include the usual default installation paths for required packages. -DeAngelo -Original Message- From: Perrin Harkins [mailto:perrin@;elem.com] Sent: Friday, November 08, 2002 1:10 PM To: DeAngelo Lampkin Cc: mod_perl Mailing List Subject: Re: Can't locate object method "new" via package "Apache::Request" (via Mason)...SOLVED DeAngelo Lampkin wrote: > And of course the other reason is that if the solution to the problem > was so obvious from the error message, somebody would have posted a > solution before I figured it out (with help from you guys). There is documentation related to this problem in the troubleshooting section, and if you'd like to generalize it a little so it will be easier for others to find when looking at this type of message, your help would be welcome. The current documentation is here: http://perl.apache.org/docs/1.0/guide/troubleshooting.html#install_driver_Oracle__failed__Can_t_load__DBD_Oracle_Oracle_so__for_module_DBD__Oracle - Perrin
Re: Can't locate object method "new" via package "Apache::Request"(via Mason)...SOLVED
DeAngelo Lampkin wrote: And of course the other reason is that if the solution to the problem was so obvious from the error message, somebody would have posted a solution before I figured it out (with help from you guys). There is documentation related to this problem in the troubleshooting section, and if you'd like to generalize it a little so it will be easier for others to find when looking at this type of message, your help would be welcome. The current documentation is here: http://perl.apache.org/docs/1.0/guide/troubleshooting.html#install_driver_Oracle__failed__Can_t_load__DBD_Oracle_Oracle_so__for_module_DBD__Oracle - Perrin
RE: Can't locate object method "new" via package "Apache::Request" (via Mason)...SOLVED
Cool. Will do. -Original Message- From: Tim Tompkins [mailto:timt@;arttoday.com] Sent: Thursday, November 07, 2002 12:27 PM To: DeAngelo Lampkin; [EMAIL PROTECTED] Subject: Re: Can't locate object method "new" via package "Apache::Request" (via Mason)...SOLVED > As a quick follow-up, the "PerlModule Apache::Request" line is NOT > needed in the httpd.conf file for Mason to work. However, it was a very > valuable debugging tool. That wasn't really the purpose, though. The purpose was to pre-load the module in the parent apache process for efficiency. My suggestion did come about because it appeared that Apache::Request wasn't being loaded at all. I'm not exacly sure how that happened as Mason's ApacheRequest attempts to require() Apache::Request a couple of places. But just the same, my suggestion to pre-load Apache::Request, as well as any other lib you normally use, stands. See: http://perl.apache.org/docs/1.0/guide/performance.html#Preloading_Perl_Modul es_at_Server_Startup Regards, Tim Tompkins -- Programmer http://www.clipart.com/ http://www.rebelartist.com/ --
RE: Can't locate object method "new" via package "Apache::Request" (via Mason)...SOLVED
>Huh? >It tells you EXACTLY what is wrong. No, not really. One reason is that it's not immediately clear (to me) which file can't be loaded. Is it Request.so or libapreq.so.1 that can't be loaded? This ambiguity is further blurred when you know both files are installed. And of course the other reason is that if the solution to the problem was so obvious from the error message, somebody would have posted a solution before I figured it out (with help from you guys). Searching the mailing list archives indicates that method name resolution is not exacly a new problem with mod_perl. Just ask this guy => http://lists.fsck.com/pipermail/rt-users/2002-September.txt. It's the exact same problem with the exact same error message, only in different clothing (he's having trouble with the Apache::Cookie object rather than the Apache::Request object). In the interest of full disclosure, other possible solutions include resetting /etc/ld.so.conf or the LD_LIBRARY_PATH variable to include more places to look for shared object files (only recently figured this out). But again, unless you're somewhat experienced or have encountered this class of bug before, this won't necessarily be the obvious place to look at first. Anyway enough of my babbling. Now that the answer is out there, hopefully it'll help out the poor souls who run into this issue in the future. Later, DeAngelo -Original Message- From: Ged Haywood [mailto:ged@;www2.jubileegroup.co.uk] Sent: Thursday, November 07, 2002 10:01 PM To: DeAngelo Lampkin Cc: mod_perl Mailing List Subject: RE: Can't locate object method "new" via package "Apache::Request" (via Mason)...SOLVED Hi there, On Thu, 7 Nov 2002, DeAngelo Lampkin wrote: > A file called libapreq.so.1 was located in /usr/local/lib > (should have been in /usr/lib) [snip] I ended up getting this thing: > > Syntax error on line 362 of /usr/local/apache/conf/httpd.conf: > Can't load >'/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Apache/Request/Request.so'\ > for module Apache::Request: libapreq.so.1: cannot open shared object file:\ > No such file or directory [snip] > > This isn't the most helpful error message in the world. Huh? It tells you EXACTLY what is wrong. 73, Ged.
RE: Can't locate object method "new" via package "Apache::Request"(via Mason)...SOLVED
Hi there, On Thu, 7 Nov 2002, DeAngelo Lampkin wrote: > A file called libapreq.so.1 was located in /usr/local/lib > (should have been in /usr/lib) [snip] I ended up getting this thing: > > Syntax error on line 362 of /usr/local/apache/conf/httpd.conf: > Can't load >'/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Apache/Request/Request.so'\ > for module Apache::Request: libapreq.so.1: cannot open shared object file:\ > No such file or directory [snip] > > This isn't the most helpful error message in the world. Huh? It tells you EXACTLY what is wrong. 73, Ged.
Re: Can't locate object method "new" via package "Apache::Request" (via Mason)...SOLVED
> As a quick follow-up, the "PerlModule Apache::Request" line is NOT > needed in the httpd.conf file for Mason to work. However, it was a very > valuable debugging tool. That wasn't really the purpose, though. The purpose was to pre-load the module in the parent apache process for efficiency. My suggestion did come about because it appeared that Apache::Request wasn't being loaded at all. I'm not exacly sure how that happened as Mason's ApacheRequest attempts to require() Apache::Request a couple of places. But just the same, my suggestion to pre-load Apache::Request, as well as any other lib you normally use, stands. See: http://perl.apache.org/docs/1.0/guide/performance.html#Preloading_Perl_Modul es_at_Server_Startup Regards, Tim Tompkins -- Programmer http://www.clipart.com/ http://www.rebelartist.com/ --
RE: Can't locate object method "new" via package "Apache::Request" (via Mason)...SOLVED
As a quick follow-up, the "PerlModule Apache::Request" line is NOT needed in the httpd.conf file for Mason to work. However, it was a very valuable debugging tool. -Original Message- From: DeAngelo Lampkin Sent: Thursday, November 07, 2002 11:21 AM To: Tim Tompkins; [EMAIL PROTECTED] Subject: RE: Can't locate object method "new" via package "Apache::Request" (via Mason)...SOLVED Thanks to Tim, Gareth, and Phillippe: OK, I'll start with the solution to the problem and then drag on a bit for how I found it. The problem was the location of a shared object file for the Apache Request object. A file called libapreq.so.1 was located in /usr/local/lib (should have been in /usr/lib), which was ok for the test script that Phillippe gave me and the one-liner that Gareth gave me, but was apparently NOT ok for Mason in the context of mod_perl. I didn't figure this out until I tried Tim's suggestion of preloading the Apache::Request module inside of httpd.conf. I ended up getting this thing: Syntax error on line 362 of /usr/local/apache/conf/httpd.conf: Can't load '/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Apache/Request/Request.so' for module Apache::Request: libapreq.so.1: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229. at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/mod_perl.pm line 14 Compilation failed in require at (eval 4) line 3. This isn't the most helpful error message in the world. However, I knew Request.so and libapreq.so.1 were installed, but I didn't know if they were in places that the server process expected them to be. So did a search for all the shared object files and noticed libapreq.so.1 file was sitting all by itself in /usr/local/lib, while about a billion other shared object files were inside of /usr/lib. I moved libapreq.so.1 to the place where all the other cool shared object files hung out, crossed my fingers, and booya! It worked. Apprently something about the way I configured the installation for libapreq was not very Mason friendly. Anyway, thanks again for the help. DeAngelo -Original Message- From: Tim Tompkins [mailto:timt@;arttoday.com] Sent: Thursday, November 07, 2002 10:16 AM To: DeAngelo Lampkin; [EMAIL PROTECTED] Subject: Re: Can't locate object method "new" via package "Apache::Request" (via Mason)... You should pre-load Apache::Request anyway, PerlModule Apache::Request PerlModule HTML::Mason::ApacheHandler SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler Regards, Tim Tompkins -- Programmer http://www.clipart.com/ http://www.rebelartist.com/ -- - Original Message - From: "Tim Tompkins" <[EMAIL PROTECTED]> To: "DeAngelo Lampkin" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, November 07, 2002 11:08 AM Subject: Re: Can't locate object method "new" via package "Apache::Request" (via Mason)... > Is Apache::Request installed for perl 5.8.0? Sounds like it's not loaded, > anyway. > > > Regards, > > Tim Tompkins > -- > Programmer > http://www.clipart.com/ > http://www.rebelartist.com/ > -- > - Original Message - > From: "DeAngelo Lampkin" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Thursday, November 07, 2002 10:54 AM > Subject: RE: Can't locate object method "new" via package "Apache::Request" > (via Mason)... > > > Hi Gareth, > > I'm using the latest version of Mason, Mason 1.15. As I posted in my > previous email, I put the following lines into my httpd.conf file per the > instructions on Mason's website: > > PerlModule HTML::Mason::ApacheHandler > > SetHandler perl-script > PerlHandler HTML::Mason::ApacheHandler > > > The reason this wasn't posted on a Mason mailing list is that this didn't > seem like a Mason problem per se and the Mason mailing list page > specifically mentioned the Apache Request object (at least in part the > source of my problem)as being something that is not directly Mason > related( http://lists.sourceforge.net/lists/listinfo/mason-users ). So I > took the advice of the list moderator and posted on the mod_perl list > instead. > > Thanks! > > DeAngelo > > -Original Message- > From: Gareth Kirwan [mailto:gbjk@;thermeoneurope.com] > Sent: Thursday, November 07, 2002 1:44 AM > To: DeAngelo Lampkin;
RE: Can't locate object method "new" via package "Apache::Request" (via Mason)...SOLVED
Thanks to Tim, Gareth, and Phillippe: OK, I'll start with the solution to the problem and then drag on a bit for how I found it. The problem was the location of a shared object file for the Apache Request object. A file called libapreq.so.1 was located in /usr/local/lib (should have been in /usr/lib), which was ok for the test script that Phillippe gave me and the one-liner that Gareth gave me, but was apparently NOT ok for Mason in the context of mod_perl. I didn't figure this out until I tried Tim's suggestion of preloading the Apache::Request module inside of httpd.conf. I ended up getting this thing: Syntax error on line 362 of /usr/local/apache/conf/httpd.conf: Can't load '/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Apache/Request/Request.so' for module Apache::Request: libapreq.so.1: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229. at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/mod_perl.pm line 14 Compilation failed in require at (eval 4) line 3. This isn't the most helpful error message in the world. However, I knew Request.so and libapreq.so.1 were installed, but I didn't know if they were in places that the server process expected them to be. So did a search for all the shared object files and noticed libapreq.so.1 file was sitting all by itself in /usr/local/lib, while about a billion other shared object files were inside of /usr/lib. I moved libapreq.so.1 to the place where all the other cool shared object files hung out, crossed my fingers, and booya! It worked. Apprently something about the way I configured the installation for libapreq was not very Mason friendly. Anyway, thanks again for the help. DeAngelo -Original Message- From: Tim Tompkins [mailto:timt@;arttoday.com] Sent: Thursday, November 07, 2002 10:16 AM To: DeAngelo Lampkin; [EMAIL PROTECTED] Subject: Re: Can't locate object method "new" via package "Apache::Request" (via Mason)... You should pre-load Apache::Request anyway, PerlModule Apache::Request PerlModule HTML::Mason::ApacheHandler SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler Regards, Tim Tompkins -- Programmer http://www.clipart.com/ http://www.rebelartist.com/ -- - Original Message - From: "Tim Tompkins" <[EMAIL PROTECTED]> To: "DeAngelo Lampkin" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, November 07, 2002 11:08 AM Subject: Re: Can't locate object method "new" via package "Apache::Request" (via Mason)... > Is Apache::Request installed for perl 5.8.0? Sounds like it's not loaded, > anyway. > > > Regards, > > Tim Tompkins > -- > Programmer > http://www.clipart.com/ > http://www.rebelartist.com/ > -- > - Original Message - > From: "DeAngelo Lampkin" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Thursday, November 07, 2002 10:54 AM > Subject: RE: Can't locate object method "new" via package "Apache::Request" > (via Mason)... > > > Hi Gareth, > > I'm using the latest version of Mason, Mason 1.15. As I posted in my > previous email, I put the following lines into my httpd.conf file per the > instructions on Mason's website: > > PerlModule HTML::Mason::ApacheHandler > > SetHandler perl-script > PerlHandler HTML::Mason::ApacheHandler > > > The reason this wasn't posted on a Mason mailing list is that this didn't > seem like a Mason problem per se and the Mason mailing list page > specifically mentioned the Apache Request object (at least in part the > source of my problem)as being something that is not directly Mason > related( http://lists.sourceforge.net/lists/listinfo/mason-users ). So I > took the advice of the list moderator and posted on the mod_perl list > instead. > > Thanks! > > DeAngelo > > -Original Message- > From: Gareth Kirwan [mailto:gbjk@;thermeoneurope.com] > Sent: Thursday, November 07, 2002 1:44 AM > To: DeAngelo Lampkin; [EMAIL PROTECTED] > Subject: RE: Can't locate object method "new" via package > "Apache::Request" (via Mason)... > > > You need to set Mason up better - probably. > > I'm an avid Mason user, and I've seen this a fair few times. > If you want help, you're most likely to get it on the > [EMAIL PROTECTED] list. > However if you want to tell me the version
Re: Can't locate object method "new" via package "Apache::Request" (via Mason)...
Sure I did. I was just keeping my response to the context of his present configuration according to the sample he sent. Regards, Tim Tompkins -- Programmer http://www.clipart.com/ http://www.rebelartist.com/ -- - Original Message - From: "Gareth Kirwan" <[EMAIL PROTECTED]> To: "Tim Tompkins" <[EMAIL PROTECTED]>; "DeAngelo Lampkin" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, November 07, 2002 11:20 AM Subject: RE: Can't locate object method "new" via package "Apache::Request" (via Mason)... > Tim - Did you not get the 18:06 email of mine ? > > It uses a handler instead. > > So he wouldn't be using this method anyway - if he decided to follow my > suggestion. > > > By the way - i'm new to this list - :-) > > Gareth >
RE: Can't locate object method "new" via package "Apache::Request" (via Mason)...
Tim - Did you not get the 18:06 email of mine ? It uses a handler instead. So he wouldn't be using this method anyway - if he decided to follow my suggestion. By the way - i'm new to this list - :-) Gareth -Original Message- From: Tim Tompkins [mailto:timt@;arttoday.com] Sent: 07 November 2002 18:16 To: DeAngelo Lampkin; [EMAIL PROTECTED] Subject: Re: Can't locate object method "new" via package "Apache::Request" (via Mason)... You should pre-load Apache::Request anyway, PerlModule Apache::Request PerlModule HTML::Mason::ApacheHandler SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler Regards, Tim Tompkins -- Programmer http://www.clipart.com/ http://www.rebelartist.com/ -- - Original Message - From: "Tim Tompkins" <[EMAIL PROTECTED]> To: "DeAngelo Lampkin" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, November 07, 2002 11:08 AM Subject: Re: Can't locate object method "new" via package "Apache::Request" (via Mason)... > Is Apache::Request installed for perl 5.8.0? Sounds like it's not loaded, > anyway. > > > Regards, > > Tim Tompkins > -- > Programmer > http://www.clipart.com/ > http://www.rebelartist.com/ > -- > - Original Message - > From: "DeAngelo Lampkin" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Thursday, November 07, 2002 10:54 AM > Subject: RE: Can't locate object method "new" via package "Apache::Request" > (via Mason)... > > > Hi Gareth, > > I'm using the latest version of Mason, Mason 1.15. As I posted in my > previous email, I put the following lines into my httpd.conf file per the > instructions on Mason's website: > > PerlModule HTML::Mason::ApacheHandler > > SetHandler perl-script > PerlHandler HTML::Mason::ApacheHandler > > > The reason this wasn't posted on a Mason mailing list is that this didn't > seem like a Mason problem per se and the Mason mailing list page > specifically mentioned the Apache Request object (at least in part the > source of my problem)as being something that is not directly Mason > related( http://lists.sourceforge.net/lists/listinfo/mason-users ). So I > took the advice of the list moderator and posted on the mod_perl list > instead. > > Thanks! > > DeAngelo > > -Original Message- > From: Gareth Kirwan [mailto:gbjk@;thermeoneurope.com] > Sent: Thursday, November 07, 2002 1:44 AM > To: DeAngelo Lampkin; [EMAIL PROTECTED] > Subject: RE: Can't locate object method "new" via package > "Apache::Request" (via Mason)... > > > You need to set Mason up better - probably. > > I'm an avid Mason user, and I've seen this a fair few times. > If you want help, you're most likely to get it on the > [EMAIL PROTECTED] list. > However if you want to tell me the version of mason you're using it might > help. > > You could use a mason-handler.pl with Mason 1.12 ( or 1.15) and the new > Lexer / Compiller components. > > There should be a require statement in your httpd.conf. > This gives you better control over data structures, variable scopes, and an > opportunity to handle persistent database connections better in the handler. > > Check out the information on http://www.masonhq.com > > Hope this helps. > > Gareth > > -Original Message- > From: DeAngelo Lampkin [mailto:dlampkin@;xencor.com] > Sent: 06 November 2002 23:25 > To: [EMAIL PROTECTED] > Subject: Can't locate object method "new" via package "Apache::Request" > (via Mason)... > > > Hey guys, > > You may remember me from such messages as "I can't get mod_perl to compile > on Irix64 systems!". Well now I've got a whole new problem that I need your > expertise on. > > I'm running Apache 1.3x and mod_perl 1.2x on a Linux system. However, > whenever I go to a page that should be handled by Mason (a perl templating > system), I get the following error message: > > "[Wed Nov 6 11:56:20 2002] [error] Can't locate object method "new" via > package "Apache::Request" at > /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/ApacheHandler.pm line 878." > > > My guess is that this (at some level)i
Re: Can't locate object method "new" via package "Apache::Request" (via Mason)...
You should pre-load Apache::Request anyway, PerlModule Apache::Request PerlModule HTML::Mason::ApacheHandler SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler Regards, Tim Tompkins -- Programmer http://www.clipart.com/ http://www.rebelartist.com/ -- - Original Message - From: "Tim Tompkins" <[EMAIL PROTECTED]> To: "DeAngelo Lampkin" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, November 07, 2002 11:08 AM Subject: Re: Can't locate object method "new" via package "Apache::Request" (via Mason)... > Is Apache::Request installed for perl 5.8.0? Sounds like it's not loaded, > anyway. > > > Regards, > > Tim Tompkins > -- > Programmer > http://www.clipart.com/ > http://www.rebelartist.com/ > -- > - Original Message - > From: "DeAngelo Lampkin" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Thursday, November 07, 2002 10:54 AM > Subject: RE: Can't locate object method "new" via package "Apache::Request" > (via Mason)... > > > Hi Gareth, > > I'm using the latest version of Mason, Mason 1.15. As I posted in my > previous email, I put the following lines into my httpd.conf file per the > instructions on Mason's website: > > PerlModule HTML::Mason::ApacheHandler > > SetHandler perl-script > PerlHandler HTML::Mason::ApacheHandler > > > The reason this wasn't posted on a Mason mailing list is that this didn't > seem like a Mason problem per se and the Mason mailing list page > specifically mentioned the Apache Request object (at least in part the > source of my problem)as being something that is not directly Mason > related( http://lists.sourceforge.net/lists/listinfo/mason-users ). So I > took the advice of the list moderator and posted on the mod_perl list > instead. > > Thanks! > > DeAngelo > > -Original Message- > From: Gareth Kirwan [mailto:gbjk@;thermeoneurope.com] > Sent: Thursday, November 07, 2002 1:44 AM > To: DeAngelo Lampkin; [EMAIL PROTECTED] > Subject: RE: Can't locate object method "new" via package > "Apache::Request" (via Mason)... > > > You need to set Mason up better - probably. > > I'm an avid Mason user, and I've seen this a fair few times. > If you want help, you're most likely to get it on the > [EMAIL PROTECTED] list. > However if you want to tell me the version of mason you're using it might > help. > > You could use a mason-handler.pl with Mason 1.12 ( or 1.15) and the new > Lexer / Compiller components. > > There should be a require statement in your httpd.conf. > This gives you better control over data structures, variable scopes, and an > opportunity to handle persistent database connections better in the handler. > > Check out the information on http://www.masonhq.com > > Hope this helps. > > Gareth > > -Original Message- > From: DeAngelo Lampkin [mailto:dlampkin@;xencor.com] > Sent: 06 November 2002 23:25 > To: [EMAIL PROTECTED] > Subject: Can't locate object method "new" via package "Apache::Request" > (via Mason)... > > > Hey guys, > > You may remember me from such messages as "I can't get mod_perl to compile > on Irix64 systems!". Well now I've got a whole new problem that I need your > expertise on. > > I'm running Apache 1.3x and mod_perl 1.2x on a Linux system. However, > whenever I go to a page that should be handled by Mason (a perl templating > system), I get the following error message: > > "[Wed Nov 6 11:56:20 2002] [error] Can't locate object method "new" via > package "Apache::Request" at > /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/ApacheHandler.pm line 878." > > > My guess is that this (at some level)involves a configuration error of some > kind. I added the following lines to my httpd.conf file per the > instructions on Mason's website: > > --- > PerlModule HTML::Mason::ApacheHandler > > SetHandler perl-script > PerlHandler HTML::Mason::ApacheHandler > > - > > So I'm not sure what's going on here. I looked through Apache/Request.pm > and found no "new" method and I didn't find one inside of Apache.pm either > (from which the Request module inherets). However, I'm assuming this is all > correct and some magical ultra-Perl-guru AUTOLOAD-like functionality is > going on somewhere. > > > Does anyone have any ideas about what may be causing this? > > > Thanks, > DeAngelo > > >
RE: Can't locate object method "new" via package "Apache::Request" (via Mason)...
Tim - You're quite right - I should have noticed the reference to 5.8.0 in the @INC file. I didn't /think/ 5.8.0 was stable ?! Am I being stupid ? Either way: perl -e 'use Apache::Request || die $!;' from the command line should tell you if you have Apache::Request installed. If you don't perl -MCPAN -e 'install Apache::Request' You're extremely likely to get more dependencies than you can shake a big stick at - but oh Well. You may also have a hell of a lot of questions - if you've never used cpan before... but let's hope you have ! :-) Good thinking, Batman @ Tim ;-) Gareth -Original Message- From: Tim Tompkins [mailto:timt@;arttoday.com] Sent: 07 November 2002 18:08 To: DeAngelo Lampkin; [EMAIL PROTECTED] Subject: Re: Can't locate object method "new" via package "Apache::Request" (via Mason)... Is Apache::Request installed for perl 5.8.0? Sounds like it's not loaded, anyway. Regards, Tim Tompkins -- Programmer http://www.clipart.com/ http://www.rebelartist.com/ -- - Original Message - From: "DeAngelo Lampkin" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, November 07, 2002 10:54 AM Subject: RE: Can't locate object method "new" via package "Apache::Request" (via Mason)... Hi Gareth, I'm using the latest version of Mason, Mason 1.15. As I posted in my previous email, I put the following lines into my httpd.conf file per the instructions on Mason's website: PerlModule HTML::Mason::ApacheHandler SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler The reason this wasn't posted on a Mason mailing list is that this didn't seem like a Mason problem per se and the Mason mailing list page specifically mentioned the Apache Request object (at least in part the source of my problem)as being something that is not directly Mason related( http://lists.sourceforge.net/lists/listinfo/mason-users ). So I took the advice of the list moderator and posted on the mod_perl list instead. Thanks! DeAngelo -Original Message- From: Gareth Kirwan [mailto:gbjk@;thermeoneurope.com] Sent: Thursday, November 07, 2002 1:44 AM To: DeAngelo Lampkin; [EMAIL PROTECTED] Subject: RE: Can't locate object method "new" via package "Apache::Request" (via Mason)... You need to set Mason up better - probably. I'm an avid Mason user, and I've seen this a fair few times. If you want help, you're most likely to get it on the [EMAIL PROTECTED] list. However if you want to tell me the version of mason you're using it might help. You could use a mason-handler.pl with Mason 1.12 ( or 1.15) and the new Lexer / Compiller components. There should be a require statement in your httpd.conf. This gives you better control over data structures, variable scopes, and an opportunity to handle persistent database connections better in the handler. Check out the information on http://www.masonhq.com Hope this helps. Gareth -----Original Message- From: DeAngelo Lampkin [mailto:dlampkin@;xencor.com] Sent: 06 November 2002 23:25 To: [EMAIL PROTECTED] Subject: Can't locate object method "new" via package "Apache::Request" (via Mason)... Hey guys, You may remember me from such messages as "I can't get mod_perl to compile on Irix64 systems!". Well now I've got a whole new problem that I need your expertise on. I'm running Apache 1.3x and mod_perl 1.2x on a Linux system. However, whenever I go to a page that should be handled by Mason (a perl templating system), I get the following error message: "[Wed Nov 6 11:56:20 2002] [error] Can't locate object method "new" via package "Apache::Request" at /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/ApacheHandler.pm line 878." My guess is that this (at some level)involves a configuration error of some kind. I added the following lines to my httpd.conf file per the instructions on Mason's website: --- PerlModule HTML::Mason::ApacheHandler SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler - So I'm not sure what's going on here. I looked through Apache/Request.pm and found no "new" method and I didn't find one inside of Apache.pm either (from which the Request module inherets). However, I'm assuming this is all correct and some magical ultra-Perl-guru AUTOLOAD-like functionality is going on somewhere. Does anyone have any ideas about what may be causing this? Thanks, DeAngelo
Re: Can't locate object method "new" via package "Apache::Request" (via Mason)...
Is Apache::Request installed for perl 5.8.0? Sounds like it's not loaded, anyway. Regards, Tim Tompkins -- Programmer http://www.clipart.com/ http://www.rebelartist.com/ -- - Original Message - From: "DeAngelo Lampkin" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, November 07, 2002 10:54 AM Subject: RE: Can't locate object method "new" via package "Apache::Request" (via Mason)... Hi Gareth, I'm using the latest version of Mason, Mason 1.15. As I posted in my previous email, I put the following lines into my httpd.conf file per the instructions on Mason's website: PerlModule HTML::Mason::ApacheHandler SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler The reason this wasn't posted on a Mason mailing list is that this didn't seem like a Mason problem per se and the Mason mailing list page specifically mentioned the Apache Request object (at least in part the source of my problem)as being something that is not directly Mason related( http://lists.sourceforge.net/lists/listinfo/mason-users ). So I took the advice of the list moderator and posted on the mod_perl list instead. Thanks! DeAngelo -Original Message- From: Gareth Kirwan [mailto:gbjk@;thermeoneurope.com] Sent: Thursday, November 07, 2002 1:44 AM To: DeAngelo Lampkin; [EMAIL PROTECTED] Subject: RE: Can't locate object method "new" via package "Apache::Request" (via Mason)... You need to set Mason up better - probably. I'm an avid Mason user, and I've seen this a fair few times. If you want help, you're most likely to get it on the [EMAIL PROTECTED] list. However if you want to tell me the version of mason you're using it might help. You could use a mason-handler.pl with Mason 1.12 ( or 1.15) and the new Lexer / Compiller components. There should be a require statement in your httpd.conf. This gives you better control over data structures, variable scopes, and an opportunity to handle persistent database connections better in the handler. Check out the information on http://www.masonhq.com Hope this helps. Gareth -Original Message- From: DeAngelo Lampkin [mailto:dlampkin@;xencor.com] Sent: 06 November 2002 23:25 To: [EMAIL PROTECTED] Subject: Can't locate object method "new" via package "Apache::Request" (via Mason)... Hey guys, You may remember me from such messages as "I can't get mod_perl to compile on Irix64 systems!". Well now I've got a whole new problem that I need your expertise on. I'm running Apache 1.3x and mod_perl 1.2x on a Linux system. However, whenever I go to a page that should be handled by Mason (a perl templating system), I get the following error message: "[Wed Nov 6 11:56:20 2002] [error] Can't locate object method "new" via package "Apache::Request" at /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/ApacheHandler.pm line 878." My guess is that this (at some level)involves a configuration error of some kind. I added the following lines to my httpd.conf file per the instructions on Mason's website: --- PerlModule HTML::Mason::ApacheHandler SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler - So I'm not sure what's going on here. I looked through Apache/Request.pm and found no "new" method and I didn't find one inside of Apache.pm either (from which the Request module inherets). However, I'm assuming this is all correct and some magical ultra-Perl-guru AUTOLOAD-like functionality is going on somewhere. Does anyone have any ideas about what may be causing this? Thanks, DeAngelo
RE: Can't locate object method "new" via package "Apache::Request" (via Mason)...
What version of perl ? Post 1.12 Mason has problems with perl 5.6.0 I believe ( or maybe .1 as well ) You're quite right about the problem not necessarily being a mason one. However as a mason user - you're likely to get help there all the same on things that are border line mason ( the new Request object is created IN ApacheHanler.pm ) Try this: Change your httpd.conf to use a mason-handler. Create a mason-handler.pl in either your @INC or your apache root. I put mine in the later ( /etc/httpd/ on my system ). Make sure the ownership / permissions of the mason-handler allow execution ( chmod +x if you must ) httpd.conf - PerlRequire mason-handler.pl SetHandler perl-script PerlHandler HTML::Mason mason-handler.pl - package HTML::Mason; use HTML::Mason; use HTML::Mason::ApacheHandler(); use strict; my $ah = new HTML::Mason::ApacheHandler ( comp_root=>'/var/virtual/www.mason-site.com/' data_dir=>'/var/virtual/HTML-Mason/data' ); chown ( 99, 99, $ah->interp->files_written ); { package HTML::Mason::Commands; use HTML::Entities; use vars qw($global1 $global2 $global3); $_escape = sub { my $text = join '', @_; HTML::Mason::Escapes::basic_html_escape(\$text); return $text } } 1; sub handler { my ($r) = @_; return -1 if $r->content_type && $r->content_type =~ m|^image/|i; $ah->handle_request($r); } == That's akin to what we use. Obviously change the /var/virtual to whatever you use as your root - and HTML-Mason is just where I wanted to keep our data for cache and stuff. The $globals are just examples. Once you've done this - let me know if you still get the same problem. Remember to keep copies of all files you change. I'd advice RCS/CVS ( i use the former ) for things like httpd.conf if you want to keep it tidy. Regards Gareth -Original Message- From: DeAngelo Lampkin [mailto:dlampkin@;xencor.com] Sent: 07 November 2002 17:54 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Can't locate object method "new" via package "Apache::Request" (via Mason)... Hi Gareth, I'm using the latest version of Mason, Mason 1.15. As I posted in my previous email, I put the following lines into my httpd.conf file per the instructions on Mason's website: PerlModule HTML::Mason::ApacheHandler SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler The reason this wasn't posted on a Mason mailing list is that this didn't seem like a Mason problem per se and the Mason mailing list page specifically mentioned the Apache Request object (at least in part the source of my problem)as being something that is not directly Mason related( http://lists.sourceforge.net/lists/listinfo/mason-users ). So I took the advice of the list moderator and posted on the mod_perl list instead. Thanks! DeAngelo -Original Message- From: Gareth Kirwan [mailto:gbjk@;thermeoneurope.com] Sent: Thursday, November 07, 2002 1:44 AM To: DeAngelo Lampkin; [EMAIL PROTECTED] Subject: RE: Can't locate object method "new" via package "Apache::Request" (via Mason)... You need to set Mason up better - probably. I'm an avid Mason user, and I've seen this a fair few times. If you want help, you're most likely to get it on the [EMAIL PROTECTED] list. However if you want to tell me the version of mason you're using it might help. You could use a mason-handler.pl with Mason 1.12 ( or 1.15) and the new Lexer / Compiller components. There should be a require statement in your httpd.conf. This gives you better control over data structures, variable scopes, and an opportunity to handle persistent database connections better in the handler. Check out the information on http://www.masonhq.com Hope this helps. Gareth -Original Message- From: DeAngelo Lampkin [mailto:dlampkin@;xencor.com] Sent: 06 November 2002 23:25 To: [EMAIL PROTECTED] Subject: Can't locate object method "new" via package "Apache::Request" (via Mason)... Hey guys, You may remember me from such messages as "I can't get mod_perl to compile on Irix64 systems!". Well now I've got a whole new problem that I need your expertise on. I'm running Apache 1.3x and mod_perl 1.2x on a Linux system. However, whenever I go to a page that should be handled by Mason (a perl templating system), I get the following error message: "[Wed Nov 6 11:56:20 2002] [error] Can't locate object method "new" via package "Apach
RE: Can't locate object method "new" via package "Apache::Request" (via Mason)...
Hi Gareth, I'm using the latest version of Mason, Mason 1.15. As I posted in my previous email, I put the following lines into my httpd.conf file per the instructions on Mason's website: PerlModule HTML::Mason::ApacheHandler SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler The reason this wasn't posted on a Mason mailing list is that this didn't seem like a Mason problem per se and the Mason mailing list page specifically mentioned the Apache Request object (at least in part the source of my problem)as being something that is not directly Mason related( http://lists.sourceforge.net/lists/listinfo/mason-users ). So I took the advice of the list moderator and posted on the mod_perl list instead. Thanks! DeAngelo -Original Message- From: Gareth Kirwan [mailto:gbjk@;thermeoneurope.com] Sent: Thursday, November 07, 2002 1:44 AM To: DeAngelo Lampkin; [EMAIL PROTECTED] Subject: RE: Can't locate object method "new" via package "Apache::Request" (via Mason)... You need to set Mason up better - probably. I'm an avid Mason user, and I've seen this a fair few times. If you want help, you're most likely to get it on the [EMAIL PROTECTED] list. However if you want to tell me the version of mason you're using it might help. You could use a mason-handler.pl with Mason 1.12 ( or 1.15) and the new Lexer / Compiller components. There should be a require statement in your httpd.conf. This gives you better control over data structures, variable scopes, and an opportunity to handle persistent database connections better in the handler. Check out the information on http://www.masonhq.com Hope this helps. Gareth -Original Message- From: DeAngelo Lampkin [mailto:dlampkin@;xencor.com] Sent: 06 November 2002 23:25 To: [EMAIL PROTECTED] Subject: Can't locate object method "new" via package "Apache::Request" (via Mason)... Hey guys, You may remember me from such messages as "I can't get mod_perl to compile on Irix64 systems!". Well now I've got a whole new problem that I need your expertise on. I'm running Apache 1.3x and mod_perl 1.2x on a Linux system. However, whenever I go to a page that should be handled by Mason (a perl templating system), I get the following error message: -------- "[Wed Nov 6 11:56:20 2002] [error] Can't locate object method "new" via package "Apache::Request" at /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/ApacheHandler.pm line 878." My guess is that this (at some level)involves a configuration error of some kind. I added the following lines to my httpd.conf file per the instructions on Mason's website: --- PerlModule HTML::Mason::ApacheHandler SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler - So I'm not sure what's going on here. I looked through Apache/Request.pm and found no "new" method and I didn't find one inside of Apache.pm either (from which the Request module inherets). However, I'm assuming this is all correct and some magical ultra-Perl-guru AUTOLOAD-like functionality is going on somewhere. Does anyone have any ideas about what may be causing this? Thanks, DeAngelo
RE: Can't locate object method "new" via package "Apache::Request" (via Mason)...
You need to set Mason up better - probably. I'm an avid Mason user, and I've seen this a fair few times. If you want help, you're most likely to get it on the [EMAIL PROTECTED] list. However if you want to tell me the version of mason you're using it might help. You could use a mason-handler.pl with Mason 1.12 ( or 1.15) and the new Lexer / Compiller components. There should be a require statement in your httpd.conf. This gives you better control over data structures, variable scopes, and an opportunity to handle persistent database connections better in the handler. Check out the information on http://www.masonhq.com Hope this helps. Gareth -Original Message- From: DeAngelo Lampkin [mailto:dlampkin@;xencor.com] Sent: 06 November 2002 23:25 To: [EMAIL PROTECTED] Subject: Can't locate object method "new" via package "Apache::Request" (via Mason)... Hey guys, You may remember me from such messages as "I can't get mod_perl to compile on Irix64 systems!". Well now I've got a whole new problem that I need your expertise on. I'm running Apache 1.3x and mod_perl 1.2x on a Linux system. However, whenever I go to a page that should be handled by Mason (a perl templating system), I get the following error message: "[Wed Nov 6 11:56:20 2002] [error] Can't locate object method "new" via package "Apache::Request" at /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/ApacheHandler.pm line 878." My guess is that this (at some level)involves a configuration error of some kind. I added the following lines to my httpd.conf file per the instructions on Mason's website: --- PerlModule HTML::Mason::ApacheHandler SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler - So I'm not sure what's going on here. I looked through Apache/Request.pm and found no "new" method and I didn't find one inside of Apache.pm either (from which the Request module inherets). However, I'm assuming this is all correct and some magical ultra-Perl-guru AUTOLOAD-like functionality is going on somewhere. Does anyone have any ideas about what may be causing this? Thanks, DeAngelo
Re: Can't locate object method "new" via package "Apache::Request" (via Mason)...
Seems somewhat similar to a bug I've reported 10 months ago. You might want to try to run the minimal testcase enclosed in the forwarded mail. Phil. --- Begin Message --- I've found that mod_perl can get confused when dealing with method calls during a redirect_internal phase: 1. page /1 uses method calls, and works when accessed as /1 2. an other page /R uses internal_redirect to go to /1, and mod_perl fails with an undefined subroutine error. This has been seen on: apache 1.3.9-14, perl 5.004.05-1.1, and mod_perl 1.25-3 (Debian "potato") and on: apache 1.3.22-2.1, perl 5.6.1-6, and mod_perl 1.26-1 (Debian "woody"/testing) How to reproduce: Use this startup.pl file: == # Common package Common; use Apache::Constants qw(:common); sub handler($$) { my $self = shift; my $req = shift; $req->content_type('text/plain'); $req->send_http_header(); $req->print($self->doit()); return OK; } sub doit { return "COMMON"; } # Common::Impl1 package Common::Impl1; @ISA=qw(Common); sub doit { return "IMPL1\n"; } # Common::Impl2; package Common::Impl2; @ISA=qw(Common); sub doit { return "IMPL2\n"; } # Redir package Redir; use Apache::Constants qw(:common); sub handler { my $req = shift; $req->internal_redirect("/1"); return OK; } 1; == PerlRequire the above, and use the following apache configuration: == Order allow,deny Allow from all SetHandler perl-script PerlHandler Common Order allow,deny Allow from all SetHandler perl-script PerlHandler Common::Impl1 Order allow,deny Allow from all SetHandler perl-script PerlHandler Common::Impl2 Order allow,deny Allow from all SetHandler perl-script PerlHandler Redir PerlRequire startup.pl == Then, directing a web browser to /0 prints COMMON, to /1 prints IMPL1, to /2 prints IMPL2, as expectected. Similarly, when pointing to /R (which redirects internally to /1), IMPL1 should appear. However, I get a 500 Internal server error and this in the logs: [error] Undefined subroutine &Common::Impl1::handler called at startup.pl line 49. I've tried to debug the problem, and the problem lies inside perl_handler_ismethod() in src/modules/perl/mod_perl.c: it returns different values when called from inside the internal_redirect than called without internal_redirect. Inside perl_handler_ismethod(): if(!sub) return 0; sv = newSVpv(sub,0); if(!(cv = sv_2cv(sv, &stash, &gv, FALSE))) { GV *gvp = gv_fetchmethod(pclass, sub); if (gvp) cv = GvCV(gvp); sv_2cv() returns different values when called from inside an internal_redirect than called without internal_redirect. Unfortunately, I could not grok sv_2cv(). It's not even documented in the perl docs. Phil. --- End Message ---
Can't locate object method "new" via package "Apache::Request" (via Mason)...
Hey guys, You may remember me from such messages as "I can't get mod_perl to compile on Irix64 systems!". Well now I've got a whole new problem that I need your expertise on. I'm running Apache 1.3x and mod_perl 1.2x on a Linux system. However, whenever I go to a page that should be handled by Mason (a perl templating system), I get the following error message: "[Wed Nov 6 11:56:20 2002] [error] Can't locate object method "new" via package "Apache::Request" at /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/ApacheHandler.pm line 878." My guess is that this (at some level)involves a configuration error of some kind. I added the following lines to my httpd.conf file per the instructions on Mason's website: --- PerlModule HTML::Mason::ApacheHandler SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler - So I'm not sure what's going on here. I looked through Apache/Request.pm and found no "new" method and I didn't find one inside of Apache.pm either (from which the Request module inherets). However, I'm assuming this is all correct and some magical ultra-Perl-guru AUTOLOAD-like functionality is going on somewhere. Does anyone have any ideas about what may be causing this? Thanks, DeAngelo
newbie:How to get form input in mod_perl 2 since Apache::request is not implemented yet ?
Hi all, I am a newbie to mod_perl and going straight to mod_perl 2. Have successfully written basic handler (API). Have not installed mod_perl 1.x Not using Apache::compat. ( Donot intend to use CGI.pm either ) In this case how to use methods from Apache::Request like $q->param() etc? I can get form data thru $r->read() but how to parse it ? Please point me to some documentation. have already checked perl.apache.org. Thanks in advance. Sumitro Chowdhury.Do you Yahoo!? HotJobs - Search new jobs daily now
Re: UTF8 character issue with Apache::Request?
Confirmed, but its browser dependant. IE on Mac OS X sends the file but munges the filename. So they file arrives fine but with the wrong name. Mozilla on Mac OS X doesnt even send the file. Still waiting for results with windows systems buth Eng and J. John- On 28 Sep 2002 23:02:59 -0400 Joe Schaefer <[EMAIL PROTECTED]> wrote: >"Peter Bi" <[EMAIL PROTECTED]> writes: > >> Please take a serious look. > >I did, and I suspect this problem is caused by OP's >client/browser >failing to open the file with the Kanji filename, so it >might be >sending an empty file with the default enctype instead. > >> There were several related reports in the mailing list >>during the >> months: Apache::Request might not handle double-bytes or >>utf8 >> correctly. Or it may be due to the C library. > >You seem to know something about this issue. However, >this is the first >time I've seen utf8 discussed in relation to >Apache::Request on this list. >I've tried a few dozen links from google ("utf8 >Apache::Request"), and >I've searched the epigone archives for this list. I >wasn't able to find >a single related report. > >A reference url, a test case, or a better still, a patch, >would be >considerably more helpful than sending me on a wild goose >chase. > >-- >Joe Schaefer
Re: UTF8 character issue with Apache::Request?
"Peter Bi" <[EMAIL PROTECTED]> writes: > Please take a serious look. I did, and I suspect this problem is caused by OP's client/browser failing to open the file with the Kanji filename, so it might be sending an empty file with the default enctype instead. > There were several related reports in the mailing list during the > months: Apache::Request might not handle double-bytes or utf8 > correctly. Or it may be due to the C library. You seem to know something about this issue. However, this is the first time I've seen utf8 discussed in relation to Apache::Request on this list. I've tried a few dozen links from google ("utf8 Apache::Request"), and I've searched the epigone archives for this list. I wasn't able to find a single related report. A reference url, a test case, or a better still, a patch, would be considerably more helpful than sending me on a wild goose chase. -- Joe Schaefer
Re: UTF8 character issue with Apache::Request?
Please take a serious look. There were several related reports in the mailing list during the months: Apache::Request might not handle double-bytes or utf8 correctly. Or it may be due to the C library. Peter - Original Message - From: "Joe Schaefer" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "modperl list" <[EMAIL PROTECTED]> Sent: Saturday, September 28, 2002 10:08 AM Subject: Re: UTF8 character issue with Apache::Request? > <[EMAIL PROTECTED]> writes: > > [...] > > > With Kanji filename : > > Size is 0 > > UPL:Content-Disposition=form-data; name="UPLOADFILE"; > > filename=".DOC" > > UPL:Content-Type=application/octet-stream > > > > Without Kanji filename > > Size is 306688 > > UPL:Content-Disposition=form-data; name="UPLOADFILE"; > > filename="copy.DOC" > > UPL:Content-Type=application/msword > > > > Any thoughts or input would be great. > > Are you certain this is a server-side problem? The > varying Content-Types look suspicious to me. I'd double-check > (via tcpdump or something) that the client is actually sending > the whole file to the server. > > -- > Joe Schaefer >
Re: UTF8 character issue with Apache::Request?
<[EMAIL PROTECTED]> writes: [...] > With Kanji filename : > Size is 0 > UPL:Content-Disposition=form-data; name="UPLOADFILE"; > filename=".DOC" > UPL:Content-Type=application/octet-stream > > Without Kanji filename > Size is 306688 > UPL:Content-Disposition=form-data; name="UPLOADFILE"; > filename="copy.DOC" > UPL:Content-Type=application/msword > > Any thoughts or input would be great. Are you certain this is a server-side problem? The varying Content-Types look suspicious to me. I'd double-check (via tcpdump or something) that the client is actually sending the whole file to the server. -- Joe Schaefer
UTF8 character issue with Apache::Request?
Hi All- We are using Apache::Request to handle our uploads via the browser. Now that we switched to UTF-8 encoding any filename with Kanji in the filename uploads with a size of '0' and nothing goes to disk. Take the same file, put its name to roman chars and it uploads fine. All other file fields handle Kanji inputs without any problems, only TYPE=FILE bomb under Apache::Request. Has anyone else seen a problem with Apache::Request and kanji character filenames? # # Read and Encode the uploaded document # my $upload = $r->upload() ; my $fh = $upload->fh() ; my $info = $upload->info; my $size = $upload->size; $Title = $upload->filename ; print STDERR "Size is $size\n" if $debug ; if( $debug ) { while (my($key, $val) = each %$info) { print STDERR "UPL:$key=$val\n" ; } } while( $buf = <$fh> ) { $TEMP .= $buf ; } With Kanji filename : Size is 0 UPL:Content-Disposition=form-data; name="UPLOADFILE"; filename=".DOC" UPL:Content-Type=application/octet-stream Without Kanji filename Size is 306688 UPL:Content-Disposition=form-data; name="UPLOADFILE"; filename="copy.DOC" UPL:Content-Type=application/msword Any thoughts or input would be great. John-
Re: Apache::Request
On Mon, 26 Aug 2002, Ufuk Yuzereroglu wrote: > I dont know if this is the right place to ask but I just cant > install Apache::Request. When calling 'make', make cant find > any of the header files. Can anyone tell me where I did go > wrong? Did you install mod_perl and apache successfully on the same machine? -- best regards, randy kobes
Apache::Request
Hi, I dont know if this is the right place to ask but I just cant install Apache::Request. When calling 'make', make cant find any of the header files. Can anyone tell me where I did go wrong? Thanks UY
sections and Apache->request->subprocess_env
I'd like to access the original Apache startup environment variables from within sections. Through experimentation and reading page 498 of the Eagle that I need to use Apache->Request->subprocess_env to access the original environment in order to do this, as %ENV is cleared at interpreter creation. However, I cannot figure out how to do this in sections! Apache->Request returns undef (reasonably so, as there is no current request) So, the question is this: How to get the equivalent of $r->subprocess_env from within a section? -- -- Tom Mornini -- InfoMania Printing & Prepress -- -- ICQ: 113526784, AOL: tmornini, Yahoo: tmornini, MSN: tmornini
Re: leaks with Apache::Request?
[resent to modperl list; earlier copy mistakenly cc'd to "p5p"] Does anyone know what's causing the Apache::Request object to leak here? See # XXX comment below: package Apache::test; sub Apache::Request::DESTROY{warn "DEAD: $_[0]\n"} sub Apache::DESTROY{warn "Dead: $_[0]\n"} use Devel::Peek; use Apache::Request; sub handler { my $r = shift; my $apr = Apache::Request->new($r); Dump($apr); # OK $r = $apr; # XXX: what's going on here??? Dump($apr); # fscked $r->send_http_header; $r->print('apr test'); return 200; } 1; SetHandler perl-script PerlHandler Apache::test --> server error log for request to /test <-- [Wed Jul 10 07:38:32 2002] [notice] Apache/1.3.27-dev (Unix) mod_perl/1.27_01-dev Perl/v5.8.0 configured [...] SV = RV(0x87aca6c) at 0x89902b8 REFCNT = 1 FLAGS = (PADBUSY,PADMY,ROK) RV = 0x8626da4 SV = PVMG(0x8703130) at 0x8626da4 REFCNT = 1 FLAGS = (OBJECT,RMG,IOK,pIOK) IV = 148456972 NV = 0 PV = 0 MAGIC = 0x8d7b2c8 MG_VIRTUAL = 0 MG_TYPE = PERL_MAGIC_ext(~) MG_FLAGS = 0x02 REFCOUNTED MG_OBJ = 0x89975dc SV = RV(0x87aca64) at 0x89975dc REFCNT = 2 FLAGS = (PADBUSY,PADMY,ROK) RV = 0x8626c78 SV = PVMG(0x8703110) at 0x8626c78 REFCNT = 2 FLAGS = (OBJECT,IOK,pIOK) IV = 148451868 NV = 0 PV = 0 STASH = 0x8298510 "Apache" MG_LEN = -1 MG_PTR = 0x8d9321c - please notify IZ STASH = 0x835f8ec "Apache::Request" SV = RV(0x87aca6c) at 0x89902b8 REFCNT = 1 FLAGS = (PADBUSY,PADMY,ROK) RV = 0x8626da4 SV = PVMG(0x8703130) at 0x8626da4 REFCNT = 2 FLAGS = (OBJECT,RMG,IOK,pIOK) IV = 148456972 NV = 0 PV = 0 MAGIC = 0x8d7b2c8 MG_VIRTUAL = 0 MG_TYPE = PERL_MAGIC_ext(~) MG_FLAGS = 0x02 REFCOUNTED MG_OBJ = 0x89975dc SV = RV(0x87aca64) at 0x89975dc REFCNT = 2 FLAGS = (PADBUSY,PADMY,ROK) RV = 0x8626da4 SV = PVMG(0x8703130) at 0x8626da4 REFCNT = 2 FLAGS = (OBJECT,RMG,IOK,pIOK) IV = 148456972 NV = 0 PV = 0 MAGIC = 0x8d7b2c8 MG_VIRTUAL = 0 MG_TYPE = PERL_MAGIC_ext(~) MG_FLAGS = 0x02 REFCOUNTED MG_OBJ = 0x89975dc SV = RV(0x87aca64) at 0x89975dc REFCNT = 2 FLAGS = (PADBUSY,PADMY,ROK) RV = 0x8626da4 MG_LEN = -1 MG_PTR = 0x8d9321c - please notify IZ STASH = 0x835f8ec "Apache::Request" MG_LEN = -1 MG_PTR = 0x8d9321c - please notify IZ STASH = 0x835f8ec "Apache::Request" Dead: Apache=SCALAR(0x8626c78)
Re: leaks with Apache::Request?
Does anyone know what's causing the Apache::Request object to leak here? See # XXX comment below: package Apache::test; sub Apache::Request::DESTROY{warn "DEAD: $_[0]\n"} sub Apache::DESTROY{warn "Dead: $_[0]\n"} use Devel::Peek; use Apache::Request; sub handler { my $r = shift; my $apr = Apache::Request->new($r); Dump($apr); # OK $r = $apr; # XXX: what's going on here??? Dump($apr); # fscked $r->send_http_header; $r->print('apr test'); return 200; } 1; SetHandler perl-script PerlHandler Apache::test --> server error log for request to /test <-- [Wed Jul 10 07:38:32 2002] [notice] Apache/1.3.27-dev (Unix) mod_perl/1.27_01-dev Perl/v5.8.0 configured [...] SV = RV(0x87aca6c) at 0x89902b8 REFCNT = 1 FLAGS = (PADBUSY,PADMY,ROK) RV = 0x8626da4 SV = PVMG(0x8703130) at 0x8626da4 REFCNT = 1 FLAGS = (OBJECT,RMG,IOK,pIOK) IV = 148456972 NV = 0 PV = 0 MAGIC = 0x8d7b2c8 MG_VIRTUAL = 0 MG_TYPE = PERL_MAGIC_ext(~) MG_FLAGS = 0x02 REFCOUNTED MG_OBJ = 0x89975dc SV = RV(0x87aca64) at 0x89975dc REFCNT = 2 FLAGS = (PADBUSY,PADMY,ROK) RV = 0x8626c78 SV = PVMG(0x8703110) at 0x8626c78 REFCNT = 2 FLAGS = (OBJECT,IOK,pIOK) IV = 148451868 NV = 0 PV = 0 STASH = 0x8298510 "Apache" MG_LEN = -1 MG_PTR = 0x8d9321c - please notify IZ STASH = 0x835f8ec "Apache::Request" SV = RV(0x87aca6c) at 0x89902b8 REFCNT = 1 FLAGS = (PADBUSY,PADMY,ROK) RV = 0x8626da4 SV = PVMG(0x8703130) at 0x8626da4 REFCNT = 2 FLAGS = (OBJECT,RMG,IOK,pIOK) IV = 148456972 NV = 0 PV = 0 MAGIC = 0x8d7b2c8 MG_VIRTUAL = 0 MG_TYPE = PERL_MAGIC_ext(~) MG_FLAGS = 0x02 REFCOUNTED MG_OBJ = 0x89975dc SV = RV(0x87aca64) at 0x89975dc REFCNT = 2 FLAGS = (PADBUSY,PADMY,ROK) RV = 0x8626da4 SV = PVMG(0x8703130) at 0x8626da4 REFCNT = 2 FLAGS = (OBJECT,RMG,IOK,pIOK) IV = 148456972 NV = 0 PV = 0 MAGIC = 0x8d7b2c8 MG_VIRTUAL = 0 MG_TYPE = PERL_MAGIC_ext(~) MG_FLAGS = 0x02 REFCOUNTED MG_OBJ = 0x89975dc SV = RV(0x87aca64) at 0x89975dc REFCNT = 2 FLAGS = (PADBUSY,PADMY,ROK) RV = 0x8626da4 MG_LEN = -1 MG_PTR = 0x8d9321c - please notify IZ STASH = 0x835f8ec "Apache::Request" MG_LEN = -1 MG_PTR = 0x8d9321c - please notify IZ STASH = 0x835f8ec "Apache::Request" Dead: Apache=SCALAR(0x8626c78)
Re: leaks with Apache::Request?
Joe Schaefer wrote: >>Somehow the assignment operator MUST be involved in the leak here. >>(You only get a leak when the *same* reference (*SV) is on both sides >>of the assignment). > > > Could someone with modperl 1.2x built using a perl 5.8 release candidate > please test this out: I got the same behavior (Apache/1.3.26 (Unix) mod_perl/1.27 perl@17440) with a modified version of your code (it doesn't work as is.) HTH.
Re: leaks with Apache::Request?
Joe Schaefer <[EMAIL PROTECTED]> writes: [...] > Somehow the assignment operator MUST be involved in the leak here. > (You only get a leak when the *same* reference (*SV) is on both sides > of the assignment). Could someone with modperl 1.2x built using a perl 5.8 release candidate please test this out: sub Apache::Request::DESTROY{warn "DEAD: $_[0]\n"} sub Apache::DESTROY{warn "Dead: $_[0]\n"} use Devel::Peek; use Apache:Request; package Apache::test; sub handler { my $r = shift; my $apr = Apache::Request->new($r); Dump($apr); # OK $r = $apr; # XXX: what's going on here??? Dump($apr); # fscked $r->send_header; $r->print('apr test'); return 200; } 1; SetHandler perl-script PerlHandler Apache::test My error log for a request to /test is below. The above assignment on the line marked "XXX" is modifying $apr, which it shouldn't. I don't have a 5.8-RC handy to test this on, but if somebody else sees the same problem on 5.8, I'll file a bug report to p5p. Thanks alot. -- SV = RV(0x814b154) at 0x82309b8 REFCNT = 1 FLAGS = (ROK) RV = 0x82472f4 SV = PVMG(0x8244f58) at 0x82472f4 REFCNT = 1 FLAGS = (OBJECT,RMG,IOK,pIOK) IV = 136639644 NV = 0 PV = 0 MAGIC = 0x8244f80 MG_VIRTUAL = 0 MG_TYPE = '~' MG_FLAGS = 0x02 REFCOUNTED MG_OBJ = 0x822dec4 SV = RV(0x814b14c) at 0x822dec4 REFCNT = 2 FLAGS = (PADBUSY,PADMY,ROK) RV = 0x82472dc SV = PVMG(0x8244f30) at 0x82472dc REFCNT = 2 FLAGS = (OBJECT,IOK,pIOK) IV = 136628428 NV = 0 PV = 0 STASH = 0x81420e4 "Apache" MG_LEN = -1 MG_PTR = 0x824c8cc - please notify IZ STASH = 0x8224a18 "Apache::Request" SV = RV(0x814b154) at 0x82309b8 REFCNT = 1 FLAGS = (ROK) RV = 0x82472f4 SV = PVMG(0x8244f58) at 0x82472f4 REFCNT = 2 FLAGS = (OBJECT,RMG,IOK,pIOK) IV = 136639644 NV = 0 PV = 0 MAGIC = 0x8244f80 MG_VIRTUAL = 0 MG_TYPE = '~' MG_FLAGS = 0x02 REFCOUNTED MG_OBJ = 0x822dec4 SV = RV(0x814b14c) at 0x822dec4 REFCNT = 2 FLAGS = (PADBUSY,PADMY,ROK) RV = 0x82472f4 SV = PVMG(0x8244f58) at 0x82472f4 REFCNT = 2 FLAGS = (OBJECT,RMG,IOK,pIOK) IV = 136639644 NV = 0 PV = 0 MAGIC = 0x8244f80 MG_VIRTUAL = 0 MG_TYPE = '~' MG_FLAGS = 0x02 REFCOUNTED MG_OBJ = 0x822dec4 SV = RV(0x814b14c) at 0x822dec4 REFCNT = 2 FLAGS = (PADBUSY,PADMY,ROK) RV = 0x82472f4 MG_LEN = -1 MG_PTR = 0x824c8cc - please notify IZ STASH = 0x8224a18 "Apache::Request" MG_LEN = -1 MG_PTR = 0x824c8cc - please notify IZ STASH = 0x8224a18 "Apache::Request" Dead: Apache=SCALAR(0x82472dc) -- -- Joe Schaefer
Re: leaks with Apache::Request?
darren chamberlain <[EMAIL PROTECTED]> writes: > * Joe Schaefer <[EMAIL PROTECTED]> [2002-07-09 12:47]: > > Dave Rolsky <[EMAIL PROTECTED]> writes: > > > On 8 Jul 2002, Joe Schaefer wrote: > > > If I do this: > > > > > > my $x = shift; > > > $x = make_something_from($x); > > > > > > then it seems like the original $x should go out of scope when it is > > > assigned to, so its refcount should stay at 1. > >^^ > > > > Right, it should stay at 1. But all bets are off when > > $x is has magic and make_something_from() is an XS sub :-). > > But the leak is not with $x, it's with what $_[0] is; $x is just a > reference to that, and the reassignment in the second line should > reassign $x, and decrement the ref count for what $x is pointing to at > that point. So, it all depends on what make_something_from() does with > the $x's referent. I don't think it's as simple as that- THIS LEAKS: my $r = shift; $r = Apache::Request->new($r); my $r = shift; $r = Apache::Request->new($_) for $r; DOES NOT LEAK: my $apr = Apache::Request->new(shift); my $r = shift; my $apr = $r; # $r and $apr have the same referent now right? $apr = Apache::Request->new($r); my $r = shift; my $apr = Apache::Request->new($r); my $r = shift; $r = Apache::Request->new($_) for map $_, $r; Somehow the assignment operator MUST be involved in the leak here. (You only get a leak when the *same* reference (*SV) is on both sides of the assignment). -- Joe Schaefer
Re: leaks with Apache::Request?
* Joe Schaefer <[EMAIL PROTECTED]> [2002-07-09 12:47]: > Dave Rolsky <[EMAIL PROTECTED]> writes: > > On 8 Jul 2002, Joe Schaefer wrote: > > If I do this: > > > > my $x = shift; > > $x = make_something_from($x); > > > > then it seems like the original $x should go out of scope when it is > > assigned to, so its refcount should stay at 1. >^^ > > Right, it should stay at 1. But all bets are off when > $x is has magic and make_something_from() is an XS sub :-). But the leak is not with $x, it's with what $_[0] is; $x is just a reference to that, and the reassignment in the second line should reassign $x, and decrement the ref count for what $x is pointing to at that point. So, it all depends on what make_something_from() does with the $x's referent. (darren) -- Great minds discuss ideas. Average minds discuss events. Small minds discuss people. -- Admiral Hyman G. Rickover