MP2: Second easy question: DB connection pooling
I've seen conflicting information in docs, websites, lists archives, etc. Is there currently a way to do database connection pooling with mod_perl2? I have tried using Apache::DBI with a use statement in my startup.pl but that doesn't seem to work. Using PerlModule Apache::DBI in my httpd.conf doesn't help either. Do I need to turn on mod_perl1 compatibility mode and then use Apache::DBI in the startup script? Is there something else entirely? =) An example or pointer to further information would be appreciated. --TWH -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
strange apache restart problem
Hello! :) I've compile apache_1.3.31 with mod_perl-1.29 : perl Makefile.PL DO_HTTPD=1 USE_APACI=1 APACHE_PREFIX=/home/httpd EVERYTHING=1 Everything is ok and scripts run perfect, but when I upload new script or modify existing one and run apachectl restart i recieve /home/httpd/bin/apachectl restart: httpd restarted, but the old script is loaded!!! Only if I do apachectl stop and then apachectl start the new script is loaded. Please give me some advice. I try it on Suse,RedHat and Fedora with the same success. What I do wrong. Kosyo __ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
write results of subrequest to file
I want to publish the result of a dynamic request to a file. So within a handler I create a subrequest that gives me the result of the dynamic request. Something like: $sub = $r-lookup_uri($page?id=$id); Now I want to get the results of this request and stream it into a file. Would using Apache::File be a possibillity? The main handler will continue and print if the write has been successfull. Cheers, Marc -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: write results of subrequest to file
MJW Lambrichs wrote: I want to publish the result of a dynamic request to a file. So within a handler I create a subrequest that gives me the result of the dynamic request. Something like: $sub = $r-lookup_uri($page?id=$id); Now I want to get the results of this request and stream it into a file. you can't do that with mod_perl 1.0 - you can $sub-run() but that result goes right to the client. basically, you need to issue a full request to the server using lwp or some similar tool. see the discussion in recipe 5.7 in the mod_perl developer's cookbook, including this code http://www.modperlcookbook.org/code/ch05/Cookbook/SubRequestContent.pm which is probably overly complex for simple needs but includes the LWP and uri-manipulating code you would want. HTH --Geoff -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: write results of subrequest to file
On Fri, 2004-08-13 at 11:06, Geoffrey Young wrote: you can't do that with mod_perl 1.0 - you can $sub-run() but that result goes right to the client. For comparison, how would you do this in mp2? With a filter? - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
RE: Modperl and Distance Education
Looks like PHP hasquite a lock on this market. Many of the online collaborative systems are PHP/mysql based. Top open-source contenders in this market would be: Moodle (moodle.org) ATutor (atutor.ca) Ilias (www.ilias.uni-koeln.de/ios/index-e.html) Note that these are collaborative learning management systems attempted to go head-to-head with commercial LMS's. I'm sure that there are some that are perl-based, but these are getting a lot of attention and they're all PHP-based. Todd From: Alfred Vahau [mailto:[EMAIL PROTECTED] Sent: Thursday, August 12, 2004 4:46 PMTo: ModperlSubject: Modperl and Distance Education Hi,Are there any major distance education sites powered by modperl technology?I work for a University with 7 campuses scattered around the country. Provision of distanceeducation through online access to teaching material and academic transcripts are among the longterm goals of the university.I find it challenging to develop a site to meet the university's requirements. It has been proposedthat I consider Java or PHP applications to develop the site to include online directory for allstaff and students connected to the university. However, I am confident that I can meet the sameobjectives using modperl technology. Somewhere I think I can use Bricolage or Mason and I amwondering whether these are appropriate technologies to consider. Or are there other applications ofmodperl relating to delivery of distance education that I am not aware of.Coming from a traditional Unix background in connection with academic research, I turned to Perl in2000 to survive in an environment dominated by Windows operating system. I continue to work on myown Breeze Project for which an early account was posted on the Oreilly site in 2002. Since then I havebeen following developments and have tested modperl and apache on trial basis.Any pointers to help in broadening my options would be highly appreciated.Many thanks in advance,Alfred VahauDirectorInformation Technology ServicesUniversity of Papua New GuineaInformation Resources Centre
Re: strange apache restart problem
On Fri, 2004-08-13 at 07:14, Konstantin Yotov wrote: Everything is ok and scripts run perfect, but when I upload new script or modify existing one and run apachectl restart i recieve /home/httpd/bin/apachectl restart: httpd restarted, but the old script is loaded!!! Only if I do apachectl stop and then apachectl start the new script is loaded. That's normal. The restart command from apachectl just sends a SIGHUP to the server, which does not shut down and restart the perl interpreter. You have to stop the server and restart it to do that. You can use PerlFreshRestart if you want to, but I don't recommend it. Please check the docs for more info on this. - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: MP2: Second easy question: DB connection pooling
On Thu, 2004-08-12 at 14:05, Tim Howell wrote: Is there currently a way to do database connection pooling with mod_perl2? No. I have tried using Apache::DBI with a use statement in my startup.pl but that doesn't seem to work. It should. Make sure it comes before anything that uses DBI. Do I need to turn on mod_perl1 compatibility mode and then use Apache::DBI in the startup script? No, it should work exactly the same as it does on mp1. - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: write results of subrequest to file
Perrin Harkins wrote: On Fri, 2004-08-13 at 11:06, Geoffrey Young wrote: you can't do that with mod_perl 1.0 - you can $sub-run() but that result goes right to the client. For comparison, how would you do this in mp2? With a filter? pretty much. I believe that subrequests in apache2 have the same limitations as before wrt calling run(). but if the main reason you want to capture a subrequest is to post-process dynamic content then you can simply insert an output filter to do that for you, as that is what they were designed for. --Geoff -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Apache::DBI and DBIx::*
What does a DBIx::* module have to do in order to correctly call
Apache::DBI's no-op version of disconnect() when running under mod_perl with
Apache::DBI?
Below is an example that illustrates a bug I found when using a particular
DBIx:: module.
---
package MyTest;
use strict;
use Apache::DBI;
use DBIx::ContextualFetch;
sub handler
{
my($r) = shift;
my $dbh = DBI-connect('dbi:...', 'myuser', 'mypass',
{ RootClass = 'DBIx::ContextualFetch' });
$r-send_http_header('text/plain');
$dbh-do('...any valid sql...') ?
print 'OK' : print 'Failed';
$dbh-disconnect; # This calls the wrong disconnect()!
return 200;
}
1;
---
Run it under httpd -X to further isolate the problem and you'll see that the
first request works, but all subsequent requests fail. This happens because
the disconnect() call actually calls the real disconnect method instead of
the Apache::DBI implementation, which is a no-op. On the next request,
Apache::DBI happily provides what is now a disconnected $dbh. Any attempt
to use that $dbh fails, obviously.
If you enable Apache::DBI's debugging output ($Apache::DBI::DEBUG = 1),
you'll see that the correct connect() method is called. That is, only one
connection is made and then re-used.
So, getting back to my original question, who is at fault here? Is this an
Apache::DBI bug, a DBIx::ContextualFetch bug, or something else?
One easy fix is to add a disconnect() method to DBIx::ContextualFetch that
detects when Apache::DBI is in use. Example:
sub DBIx::ContextualFetch::disconnect
{
if($ENV{'MOD_PERL'} $Apache::DBI::VERSION)
{
# Do nothing when Apache::DBI is in use
return 1;
}
shift-SUPER::disconnect(@_);
}
But isn't Apache::DBI supposed to be transparent and do all this stuff for
me? Or are all bets off when using a DBIx module? If so, what is a DBIx
author supposed to do to be a good Apache::DBI citizen?
-John
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache::DBI and DBIx::*
while perrin addressed your other issues, I thought I'd bring this up as a learning point :) return 200; this is wrong - you should be returning OK (0) not HTTP_OK (200) from handlers if everything is swell. while 200 works in mp1 (due to mod_perl guessing what you meant) you cannot do this in mod_perl 2.0. so, if you do it correctly now you'll have one less thing to migrate later :) --Geoff -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache::DBI and DBIx::*
On Fri, 13 Aug 2004 15:32:03 -0400, Perrin Harkins [EMAIL PROTECTED] wrote: On Fri, 2004-08-13 at 15:25, John Siracusa wrote: What does a DBIx::* module have to do in order to correctly call Apache::DBI's no-op version of disconnect() when running under mod_perl with Apache::DBI? It needs to not set RootClass. Apache::DBI essentially subclasses DBI, which is what RootClass does as well. Er, yeah, essentially :) All the crazy re-blessing that goes on is quite a mess, IMO. So what you're saying is that DBIx::* and Apache::DBI will simply never get along because they both want to do the same thing, but use different (and apparently incompatible) methods to do so? Run it under httpd -X to further isolate the problem and you'll see that the first request works, but all subsequent requests fail. This happens because the disconnect() call actually calls the real disconnect method instead of the Apache::DBI implementation, which is a no-op. Why call disconnect at all? Are you trying to run this as normal CGI too? The first answer is that I'm calling disconnect because it's The Right Thing To Do. Maybe some people think just letting things go out of scope is more (mod_)perl-ish, but I always wonder if those people don't call close(FILE) either ;) Anyway, I'm not one of those people. The second answer is that it's common (and usually desirable) for certain DBI-using modules to be used both in both web and offline contexts. (The example was heavily simplified, obviously.) -John -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache::DBI and DBIx::*
On Fri, 2004-08-13 at 16:43, John Siracusa wrote: It just seemed odd to me to be doing stuff in service of Apache::DBI, which was totally transparent until then. That's one of the things I don't like about Apache::DBI. I don't want it to be magical. Now that Perl has lexically scoped filehandles, there isn't any reason to explicitly call close() in most cases. ;) Tsk, for shame. Just wait until you forget to call close() after writing to a file... ;) That's the point actually -- perl closes it for me when it goes out of scope. That assumes the connection was opened by (or is at least accessible from) the script itself. If the connection is opened and managed by a module (which may abstract things such that you aren't even supposed to know whether or not it has to hit a database at all) rather than by your script, that's not an option. True, you have to structure your code for this. Making all calls to open a db connection go through one utility class is my approach, but may not work for everyone. Hmm, I wonder why my Class::DBI unit test scripts never get the disconnect warning? I should look into that. Class::DBI uses connect_cached. I also wrap DBI rather than subclass it when I have a choice. Me too. Subclassing DBI (or Apache or Apache::Request for that matter) is nearly always a bad idea IMO. In this one case it makes some sense though, since that module is literally all about changing the behavior of DBI methods. - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache::DBI and DBIx::*
On Fri, 13 Aug 2004 16:45:59 -0400, Perrin Harkins [EMAIL PROTECTED] wrote: On Fri, 2004-08-13 at 16:37, Stas Bekman wrote: IMHO, that should be folded into DBI::Pool I'm not really interested in tackling pooling, since I don't plan to run threads. All that I really want my module to do is extend the DBI-connect_cached() method by adding the cleanup handler stuff from Apache::DBI. Even without threads, wouldn't you rather have each apache child pulling connections from a shared, server-wide pool rather than holding onto at least one connection a piece whether they need it or not? With the Apache::DBI system on a typical db-backed web site, the max number of simultaneous (mod_perl) requests is pretty much limited by the max number of simultaneous open database connections (since, long term, every apache child will be hanging onto at least one db connection). A server-wide pool removes that limitation, allowing each request to retain, use, and then release any number of connections (possibly zero) within the course of a single request. Maybe that'd lead to too much contention, I don't know, but I assumed something like that was a long-term mod_perl2/apache2/perl6 goal. Or maybe it's just a personal fantasy... :) -John -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache::DBI and DBIx::*
On Fri, 13 Aug 2004 17:02:27 -0400, Perrin Harkins [EMAIL PROTECTED] wrote: Now that Perl has lexically scoped filehandles, there isn't any reason to explicitly call close() in most cases. ;) Tsk, for shame. Just wait until you forget to call close() after writing to a file... ;) That's the point actually -- perl closes it for me when it goes out of scope. Ah, but perl doesn't check the return value! :) Something tells me you haven't been bitten by this bug yet, but let me save you the grief. When, say, your disk fills up and you let that file handle go out of scope, close() will silently fail when trying to flush the buffers to disk. The moral of the story: always call close() explicitly *and check the return value* when writing to a file. -John -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache::DBI and DBIx::*
On Fri, 2004-08-13 at 17:05, John Siracusa wrote: Even without threads, wouldn't you rather have each apache child pulling connections from a shared, server-wide pool rather than holding onto at least one connection a piece whether they need it or not? Sure. Can you figure out a way to do it? It is possible on unix systems to pass filehandles between processes, but that kind of C programming is not something I'm likely to tackle myself. With the Apache::DBI system on a typical db-backed web site, the max number of simultaneous (mod_perl) requests is pretty much limited by the max number of simultaneous open database connections (since, long term, every apache child will be hanging onto at least one db connection). You actually have a site where you can run more apache children than database connections? I have never seen such a beast. IMO the only real advantage of having pooling over the way things are now (assuming you run a front-end proxy for static stuff) is that sites which use different database logins for each user will be able to use persistent connections. Right now, that would result in a very large number of connections. Maybe that'd lead to too much contention, I don't know, but I assumed something like that was a long-term mod_perl2/apache2/perl6 goal. Or maybe it's just a personal fantasy... :) Perl6 would presumably mean mod_perl 3. Anyway, the pooling thing is mostly driven by how much Java people hype it. The usefulness of pooling is pretty limited for a site that actually uses database connections on every request. - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
[PATCH] Apache::DBI support for subclassed DBI connections
This patch should make Apache::DBI work with subclassed DBI
connections. The only downside is that it makes ALL of your cached
connections subclassed if you give it one that is subclassed. Given how
most people use DBI subclasses (for universal functionality on all DBI
connections), this is probably not an issue.
- Perrin
--- /usr/lib/perl5/site_perl/5.8.3/Apache/DBI.pm 2004-02-17 19:18:50.0 -0500
+++ ./DBI.pm 2004-08-13 17:41:41.045930048 -0400
@@ -130,6 +130,12 @@
# return the new database handle
print STDERR $prefix new connect to '$Idx'\n if $Apache::DBI::DEBUG;
+
+# support subclassed DBI connections
+if (ref $Connected{$Idx} ne 'DBI::st') {
+push @Apache::DBI::st::ISA, ref $Connected{$Idx};
+}
+
return (bless $Connected{$Idx}, 'Apache::DBI::db');
}
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache::DBI and DBIx::*
Perrin Harkins wrote: On Fri, 2004-08-13 at 16:37, Stas Bekman wrote: IMHO, that should be folded into DBI::Pool I'm not really interested in tackling pooling, since I don't plan to run threads. Support for threads is only partial functionality of DBI::Pool. Otherwise it should be a ground-up rewrite based on the experiences with Apache::DBI and other wrappers so far. Apache::DBI should become just a thin wrapper on top of DBI::Pool, to handle things like connect_on_init. All that I really want my module to do is extend the DBI-connect_cached() method by adding the cleanup handler stuff from Apache::DBI. Sure, just thought that you are planning to work on yet another Apache::DBI version, so I've suggested to direct the effort into something new that (will) solves it all. -- __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Checking the return value of close() (was: Apache::DBI and DBIx::*)
On 8/13/04 5:23 PM, Perrin Harkins wrote: On Fri, 2004-08-13 at 17:15, John Siracusa wrote: Something tells me you haven't been bitten by this bug yet, but let me save you the grief. When, say, your disk fills up and you let that file handle go out of scope, close() will silently fail when trying to flush the buffers to disk. If you're concerned about that, you should actually check the return value of print() as well. Believe me, everyone should be concerned about that :) Also, the return value from print() is not always useful. In the situation I described, for example, print will happily return 1 so long as what it's printing fits in the output buffer, regardless of whether or not the data is actually going to make it to the disk. Checking the return value from close() gives a more reliable answer, and you only have to do it once at the end. -John -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache::DBI and DBIx::*
On 8/13/04 5:22 PM, Perrin Harkins wrote: On Fri, 2004-08-13 at 17:05, John Siracusa wrote: Even without threads, wouldn't you rather have each apache child pulling connections from a shared, server-wide pool rather than holding onto at least one connection a piece whether they need it or not? Sure. Can you figure out a way to do it? Probably not in Perl 5 and apache 1.x, but I hope Perl 6, apache 2, and mod_(perl6|parrot) will be flexible enough... You actually have a site where you can run more apache children than database connections? I have never seen such a beast. Maybe your database is just too beefy? :) I've worked on sites that would routinely bump into a database connection limit of ~200 during traffic spikes. (And yes, of course static content was served elsewhere :) Maybe that'd lead to too much contention, I don't know, but I assumed something like that was a long-term mod_perl2/apache2/perl6 goal. Or maybe it's just a personal fantasy... :) Perl6 would presumably mean mod_perl 3. ...or mod_parrot or something, especially if this Parrot DBI-like-core thing takes off (I forget the name they're using) Anyway, the pooling thing is mostly driven by how much Java people hype it. The usefulness of pooling is pretty limited for a site that actually uses database connections on every request. I've worked on sites that use a session (MySQL) database connection on every request, but don't use a main (Postgres) database connection nearly that often. If that main database is shared by several sites/apps, it can become the bottleneck. Maybe read-only replication would help, but it still seems wasteful. -John -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Checking the return value of close() (was: Apache::DBI and DBIx::*)
On 8/13/04 10:34 PM, John Siracusa wrote: In the situation I described, for example, print will happily return 1 so long as what it's printing fits in the output buffer, regardless of whether or not the data is actually going to make it to the disk. Er, that should read regardless of whether or not the disk is full, since making it to disk is outside the scope of Perl's core functions (and may be outside the scope of the OS if the hardware lies :) -John -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [PATCH] Apache::DBI support for subclassed DBI connections
On 8/13/04 5:43 PM, Perrin Harkins wrote: This patch should make Apache::DBI work with subclassed DBI connections. The only downside is that it makes ALL of your cached connections subclassed if you give it one that is subclassed. Given how most people use DBI subclasses (for universal functionality on all DBI connections), this is probably not an issue. Cool, I'll try it out on Monday. If it works, you should submit it to the Apache::DBI maintainer (if you haven't already) -John -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache::DBI and DBIx::*
John Siracusa wrote: Even without threads, wouldn't you rather have each apache child pulling connections from a shared, server-wide pool rather than holding onto at least one connection a piece whether they need it or not? Sure. Can you figure out a way to do it? Probably not in Perl 5 and apache 1.x, but I hope Perl 6, apache 2, and mod_(perl6|parrot) will be flexible enough... It's not a matter of flexibility, but rather one of difficult coding and potential issues with closed source database client libraries. The coding would be in C, and it would involve passing data structures and open sockets between running processes. It's way beyond my level of unix-foo, but if someone out there wants to try it, there is nothing needed for it that hasn't already been there for years. Making DBI::Pool work for threads is probably easier, and that could also be done today if someone has both the incentive and the C-coding skills to deal with the threading and XS issues. I've worked on sites that use a session (MySQL) database connection on every request, but don't use a main (Postgres) database connection nearly that often. In that situation, if a significant percentage of requests need sessions but not the main database, and the difference is determined by URL, I would move the session-only requests to a separate server. Pooling sounds nice, but is a non-trivial problem, and only helps in a few specific situations. In the common case, where every request to the app-server needs a database handle, it is not very useful. - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
cvs commit: modperl-2.0/t/response/TestDirective cmdparms.pm
gozer 2004/08/13 21:29:50
Modified:t/response/TestDirective cmdparms.pm
Log:
Whitespace and indentation cleanups
Revision ChangesPath
1.3 +19 -25modperl-2.0/t/response/TestDirective/cmdparms.pm
Index: cmdparms.pm
===
RCS file: /home/cvs/modperl-2.0/t/response/TestDirective/cmdparms.pm,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- cmdparms.pm 13 Aug 2004 05:27:11 - 1.2
+++ cmdparms.pm 14 Aug 2004 04:29:50 - 1.3
@@ -5,6 +5,7 @@
use Apache::CmdParms ();
use Apache::Module ();
+
use Apache::Test;
use Apache::TestUtil;
@@ -34,41 +35,32 @@
},
);
-my @methods = qw(
-cmd
-context
-directive
-info
-limited
-override
-path
-pool
-server
-temp_pool
-);
+my @methods = qw(cmd context directive info limited override path
+ pool server temp_pool);
sub TestCmdParms {
-my ($self, $parms, $args) = @_;
+my($self, $parms, $args) = @_;
my $srv_cfg = $self-get_config($parms-server);
foreach my $method (@methods) {
$srv_cfg-{$args}{$method} = $parms-$method();
}
-$srv_cfg-{$args}{check_ctx} =
$parms-check_cmd_context(Apache::NOT_IN_LOCATION);
+$srv_cfg-{$args}{check_ctx} =
+$parms-check_cmd_context(Apache::NOT_IN_LOCATION);
}
sub get_config {
-my ($self, $s) = (shift, shift);
+my($self, $s) = (shift, shift);
Apache::Module-get_config($self, $s, @_);
}
### response handler ###
sub handler : method {
-my ($self, $r) = @_;
+my($self, $r) = @_;
my $override;
my $srv_cfg = $self-get_config($r-server);
-
+
plan $r, tests = 6 + ( 8 * keys(%$srv_cfg) );
-
+
foreach my $cfg (values %$srv_cfg) {
ok t_cmp (ref($cfg-{cmd}), 'Apache::Command', 'cmd');
ok t_cmp (ref($cfg-{context}), 'Apache::ConfVector', 'context');
@@ -79,30 +71,32 @@
ok t_cmp ($cfg-{limited}, -1, 'limited');
ok t_cmp ($cfg-{info}, 'cmd_data', 'cmd_data');
}
-
+
my $vhost = $srv_cfg-{Vhost};
-
+
$override = Apache::RSRC_CONF |
Apache::OR_INDEXES |
Apache::OR_FILEINFO |
Apache::OR_OPTIONS;
-
+
ok t_cmp ($vhost-{override}, $override, 'override');
ok t_cmp ($vhost-{path}, undef, 'path');
ok t_cmp ($vhost-{check_ctx}, undef, 'check_cmd_ctx');
-
+
my $loc = $srv_cfg-{Location};
-
+
$override = Apache::ACCESS_CONF |
Apache::OR_INDEXES |
Apache::OR_AUTHCFG |
Apache::OR_FILEINFO |
Apache::OR_OPTIONS |
Apache::OR_LIMIT;
-
+
ok t_cmp ($loc-{override}, $override, 'override');
ok t_cmp ($loc-{path}, '/TestDirective__cmdparms', 'path');
-ok t_cmp ($loc-{check_ctx}, KEY . ' cannot occur within Location section',
'check_cmd_ctx');
+ok t_cmp ($loc-{check_ctx}, KEY .
+ ' cannot occur within Location section', 'check_cmd_ctx');
+
return Apache::OK;
}
cvs commit: modperl-2.0/t/response/TestDirective cmdparms.pm
gozer 2004/08/13 21:36:09
Modified:t/response/TestDirective cmdparms.pm
Log:
More small whitespace fixes
Revision ChangesPath
1.4 +14 -14modperl-2.0/t/response/TestDirective/cmdparms.pm
Index: cmdparms.pm
===
RCS file: /home/cvs/modperl-2.0/t/response/TestDirective/cmdparms.pm,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- cmdparms.pm 14 Aug 2004 04:29:50 - 1.3
+++ cmdparms.pm 14 Aug 2004 04:36:09 - 1.4
@@ -62,14 +62,14 @@
plan $r, tests = 6 + ( 8 * keys(%$srv_cfg) );
foreach my $cfg (values %$srv_cfg) {
-ok t_cmp (ref($cfg-{cmd}), 'Apache::Command', 'cmd');
-ok t_cmp (ref($cfg-{context}), 'Apache::ConfVector', 'context');
-ok t_cmp (ref($cfg-{directive}), 'Apache::Directive', 'directive');
-ok t_cmp (ref($cfg-{pool}), 'APR::Pool', 'pool');
-ok t_cmp (ref($cfg-{temp_pool}), 'APR::Pool', 'temp_pool');
-ok t_cmp (ref($cfg-{server}), 'Apache::ServerRec', 'server');
-ok t_cmp ($cfg-{limited}, -1, 'limited');
-ok t_cmp ($cfg-{info}, 'cmd_data', 'cmd_data');
+ok t_cmp(ref($cfg-{cmd}), 'Apache::Command', 'cmd');
+ok t_cmp(ref($cfg-{context}), 'Apache::ConfVector', 'context');
+ok t_cmp(ref($cfg-{directive}), 'Apache::Directive', 'directive');
+ok t_cmp(ref($cfg-{pool}), 'APR::Pool', 'pool');
+ok t_cmp(ref($cfg-{temp_pool}), 'APR::Pool', 'temp_pool');
+ok t_cmp(ref($cfg-{server}), 'Apache::ServerRec', 'server');
+ok t_cmp($cfg-{limited}, -1, 'limited');
+ok t_cmp($cfg-{info}, 'cmd_data', 'cmd_data');
}
my $vhost = $srv_cfg-{Vhost};
@@ -79,9 +79,9 @@
Apache::OR_FILEINFO |
Apache::OR_OPTIONS;
-ok t_cmp ($vhost-{override}, $override, 'override');
-ok t_cmp ($vhost-{path}, undef, 'path');
-ok t_cmp ($vhost-{check_ctx}, undef, 'check_cmd_ctx');
+ok t_cmp($vhost-{override}, $override, 'override');
+ok t_cmp($vhost-{path}, undef, 'path');
+ok t_cmp($vhost-{check_ctx}, undef, 'check_cmd_ctx');
my $loc = $srv_cfg-{Location};
@@ -92,9 +92,9 @@
Apache::OR_OPTIONS |
Apache::OR_LIMIT;
-ok t_cmp ($loc-{override}, $override, 'override');
-ok t_cmp ($loc-{path}, '/TestDirective__cmdparms', 'path');
-ok t_cmp ($loc-{check_ctx}, KEY .
+ok t_cmp($loc-{override}, $override, 'override');
+ok t_cmp($loc-{path}, '/TestDirective__cmdparms', 'path');
+ok t_cmp($loc-{check_ctx}, KEY .
' cannot occur within Location section', 'check_cmd_ctx');
return Apache::OK;
cvs commit: modperl-2.0/t/response/TestDirective cmdparms.pm
gozer 2004/08/13 21:45:20
Modified:t/response/TestDirective cmdparms.pm
Log:
A little bit more cleanup.
Revision ChangesPath
1.5 +28 -20modperl-2.0/t/response/TestDirective/cmdparms.pm
Index: cmdparms.pm
===
RCS file: /home/cvs/modperl-2.0/t/response/TestDirective/cmdparms.pm,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- cmdparms.pm 14 Aug 2004 04:36:09 - 1.4
+++ cmdparms.pm 14 Aug 2004 04:45:20 - 1.5
@@ -72,30 +72,38 @@
ok t_cmp($cfg-{info}, 'cmd_data', 'cmd_data');
}
-my $vhost = $srv_cfg-{Vhost};
+# vhost
+{
+my $vhost = $srv_cfg-{Vhost};
-$override = Apache::RSRC_CONF |
-Apache::OR_INDEXES |
-Apache::OR_FILEINFO |
-Apache::OR_OPTIONS;
+my $wanted = Apache::RSRC_CONF |
+ Apache::OR_INDEXES |
+ Apache::OR_FILEINFO |
+ Apache::OR_OPTIONS;
+my $masked = $vhost-{override} $wanted;
-ok t_cmp($vhost-{override}, $override, 'override');
-ok t_cmp($vhost-{path}, undef, 'path');
-ok t_cmp($vhost-{check_ctx}, undef, 'check_cmd_ctx');
+ok t_cmp($masked, $wanted, 'override bitmask');
+ok t_cmp($vhost-{path}, undef, 'path');
+ok t_cmp($vhost-{check_ctx}, undef, 'check_cmd_ctx');
+}
-my $loc = $srv_cfg-{Location};
+# Location
+{
+my $loc = $srv_cfg-{Location};
+
+my $wanted = Apache::ACCESS_CONF |
+ Apache::OR_INDEXES |
+ Apache::OR_AUTHCFG |
+ Apache::OR_FILEINFO |
+ Apache::OR_OPTIONS |
+ Apache::OR_LIMIT;
+my $masked = $loc-{override} $wanted;
-$override = Apache::ACCESS_CONF |
-Apache::OR_INDEXES |
-Apache::OR_AUTHCFG |
-Apache::OR_FILEINFO |
-Apache::OR_OPTIONS |
-Apache::OR_LIMIT;
-
-ok t_cmp($loc-{override}, $override, 'override');
-ok t_cmp($loc-{path}, '/TestDirective__cmdparms', 'path');
-ok t_cmp($loc-{check_ctx}, KEY .
- ' cannot occur within Location section', 'check_cmd_ctx');
+ok t_cmp($masked, $wanted, 'override bitmask');
+ok t_cmp($loc-{path}, '/TestDirective__cmdparms', 'path');
+ok t_cmp($loc-{check_ctx}, KEY .
+ ' cannot occur within Location section', 'check_cmd_ctx');
+}
return Apache::OK;
}
cvs commit: modperl-2.0/xs/maps apache_functions.map
stas2004/08/13 22:10:12
Modified:t/api.cvsignore internal_redirect.t
t/response/TestAPI lookup_uri.pm
.Changes
todo api_status
xs/maps apache_functions.map
Added: t/apiinternal_redirect_handler.t lookup_misc.t
lookup_uri.t sub_request.t
t/response/TestAPI internal_redirect_handler.pm
lookup_misc.pm sub_request.pm
Log:
- fix Apache::SubRequest's methods: lookup_file, lookup_uri,
lookup_method_uri to default the last argument to
r-proto_output_filters (no request filters for the subrequest) and
not r-output_filters-next as it was before (one filter was getting
skipped and the rest of the filters were applied *twice*).
- add more sub-request tests
Revision ChangesPath
1.15 +0 -1 modperl-2.0/t/api/.cvsignore
Index: .cvsignore
===
RCS file: /home/cvs/modperl-2.0/t/api/.cvsignore,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -u -r1.14 -r1.15
--- .cvsignore12 Aug 2004 06:40:45 - 1.14
+++ .cvsignore14 Aug 2004 05:10:11 - 1.15
@@ -4,7 +4,6 @@
conn_rec.t
conn_util.t
lookup_uri2.t
-lookup_uri.t
module.t
process.t
query.t
1.3 +1 -1 modperl-2.0/t/api/internal_redirect.t
Index: internal_redirect.t
===
RCS file: /home/cvs/modperl-2.0/t/api/internal_redirect.t,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -u -r1.2 -r1.3
--- internal_redirect.t 8 Jul 2004 05:29:42 - 1.2
+++ internal_redirect.t 14 Aug 2004 05:10:11 - 1.3
@@ -18,7 +18,7 @@
modperl = perl-script = ${uri}_modperl?uri=${uri}_perl_script,
);
-plan tests = 4;
+plan tests = scalar keys %map;
while (my($key, $val) = each %map) {
my $expected = internal redirect: $key;
1.1 modperl-2.0/t/api/internal_redirect_handler.t
Index: internal_redirect_handler.t
===
use strict;
use warnings FATAL = 'all';
use Apache::Test;
use Apache::TestUtil;
use Apache::TestRequest;
my $uri = /TestAPI__internal_redirect_handler;
my @ct_types = qw(text/plain text/html);
plan tests = scalar @ct_types;
for my $type (@ct_types) {
my $expected = $type;
my $received = GET_BODY_ASSERT $uri?ct=$type;
ok t_cmp $received, $expected, Content-type: $type;
}
1.1 modperl-2.0/t/api/lookup_misc.t
Index: lookup_misc.t
===
use strict;
use warnings FATAL = 'all';
use Apache::Test;
use Apache::TestUtil;
use Apache::TestRequest;
use File::Spec;
my $uri = /TestAPI__lookup_misc;
my $file = File::Spec-rel2abs(__FILE__);
open my $fh, $file or die Can't open $file: $!;
my $data = do { binmode $fh; local $/; $fh };
close $fh;
plan tests = 2;
# lookup_file
{
my $args = subreq=lookup_file;file=$file;
my $expected = $data;
my $received = GET_BODY_ASSERT $uri?$args;
t_debug lookup_file;
ok $received eq $expected;
}
# lookup_method_uri
{
my $args = subreq=lookup_method_uri;uri=/lookup_method_uri;
my $expected = ok;
my $received = GET_BODY_ASSERT $uri?$args;
ok t_cmp $received, $expected, lookup_method_uri;
}
1.1 modperl-2.0/t/api/lookup_uri.t
Index: lookup_uri.t
===
use strict;
use warnings FATAL = 'all';
use Apache::Test;
use Apache::TestUtil;
use Apache::TestRequest;
my $uri = /TestAPI__lookup_uri;
use constant PREFIX = 0;
use constant SUFFIX = 1;
my %opts = (
first = [2, 2], # all filters run twice
second = [1, 2], # the top level req filter skipped for the subreq
none= [1, 1], # no request filters run by subreq
default = [1, 1], # same as none
);
plan tests = scalar keys %opts;
while (my($filter, $runs) = each %opts) {
my $args = subreq=lookup_uri;filter=$filter;
my $prefix = pre+ x $runs-[PREFIX];
my $suffix = +suf x $runs-[SUFFIX];
my $expected = $prefix$args$suffix;
my $received = GET_BODY_ASSERT $uri?$args;
ok t_cmp $received, $expected, $args;
}
1.1 modperl-2.0/t/api/sub_request.t
Index: sub_request.t
===
# WARNING: this file is generated, do not edit
# 01: /home/stas/apache.org/mp2-pool/Apache-Test/lib/Apache/TestConfig.pm:875
# 02: /home/stas/apache.org/mp2-pool/Apache-Test/lib/Apache/TestConfig.pm:893
# 03:
cvs commit: modperl-2.0/t/response/TestDirective cmdparms.pm
stas2004/08/13 22:20:19
Modified:t/response/TestDirective cmdparms.pm
Log:
remove excessive spacing
Revision ChangesPath
1.6 +7 -7 modperl-2.0/t/response/TestDirective/cmdparms.pm
Index: cmdparms.pm
===
RCS file: /home/cvs/modperl-2.0/t/response/TestDirective/cmdparms.pm,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -u -r1.5 -r1.6
--- cmdparms.pm 14 Aug 2004 04:45:20 - 1.5
+++ cmdparms.pm 14 Aug 2004 05:20:19 - 1.6
@@ -28,16 +28,16 @@
use constant KEY = TestCmdParms;
our @APACHE_MODULE_COMMANDS = (
-{
+{
name= +KEY,
cmd_data= 'cmd_data',
errmsg = 'errmsg',
},
);
-
+
my @methods = qw(cmd context directive info limited override path
pool server temp_pool);
-
+
sub TestCmdParms {
my($self, $parms, $args) = @_;
my $srv_cfg = $self-get_config($parms-server);
@@ -56,7 +56,7 @@
### response handler ###
sub handler : method {
my($self, $r) = @_;
-my $override;
+my $override;
my $srv_cfg = $self-get_config($r-server);
plan $r, tests = 6 + ( 8 * keys(%$srv_cfg) );
@@ -70,7 +70,7 @@
ok t_cmp(ref($cfg-{server}), 'Apache::ServerRec', 'server');
ok t_cmp($cfg-{limited}, -1, 'limited');
ok t_cmp($cfg-{info}, 'cmd_data', 'cmd_data');
-}
+}
# vhost
{
@@ -90,7 +90,7 @@
# Location
{
my $loc = $srv_cfg-{Location};
-
+
my $wanted = Apache::ACCESS_CONF |
Apache::OR_INDEXES |
Apache::OR_AUTHCFG |
@@ -101,7 +101,7 @@
ok t_cmp($masked, $wanted, 'override bitmask');
ok t_cmp($loc-{path}, '/TestDirective__cmdparms', 'path');
-ok t_cmp($loc-{check_ctx}, KEY .
+ok t_cmp($loc-{check_ctx}, KEY .
' cannot occur within Location section', 'check_cmd_ctx');
}
cvs commit: modperl-2.0/t/api .cvsignore sub_request.t
stas2004/08/13 22:23:50 Modified:t/api.cvsignore Removed: t/apisub_request.t Log: oops, shouldn't have committed an autogenerated file Revision ChangesPath 1.16 +1 -0 modperl-2.0/t/api/.cvsignore Index: .cvsignore === RCS file: /home/cvs/modperl-2.0/t/api/.cvsignore,v retrieving revision 1.15 retrieving revision 1.16 diff -u -u -r1.15 -r1.16 --- .cvsignore14 Aug 2004 05:10:11 - 1.15 +++ .cvsignore14 Aug 2004 05:23:50 - 1.16 @@ -15,4 +15,5 @@ server_rec.t server_util.t show.t +sub_request.t uri.t
