Re: Using SSI with perl handlers?
On Mon, 2003-11-17 at 01:36, Christopher P. Lindsey wrote: Basically, it all boils down to the fact that once an SSI directive with #EXEC CGI is parsed, the document fails to parse any further SSI directives *if the script to be executed has a perl-script handler.* What happens if you use #include virtual instead? The #exec cgi directive has been deprecated in mod_include for years. The Apache::SSI module sets the content-type to application/x-httpd-cgi when you use exec cgi, and that might be causing a problem here, since what you are including are not actually CGI scripts. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Using SSI with perl handlers?
What happens if you use #include virtual instead? The #exec cgi directive has been deprecated in mod_include for years. The Apache::SSI module sets the content-type to application/x-httpd-cgi when you use exec cgi, and that might be causing a problem here, since what you are including are not actually CGI scripts. Hi Perrin, I actually get the same results, but I appreciate the idea! Chris -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: PATCH perl_reference.pod Remedies for Inner Subroutines
Stas Bekman [EMAIL PROTECTED] writes: Brian McCauley wrote: Stas Bekman [EMAIL PROTECTED] writes: I think it would be more clear if all are declared at the top of the file, Declaring variables at the top of the file is, IMNSHO, a bad programming habit that should be discouraged. Sorry I've missed the word globals while typing [...] You are talking about the locality rule, which I perfectly agree with when it comes to scoped variables. However when it comes to globals I tend to disagree with you. [ snip - Stas correctly anticipates all my arguments in the debate ] Agreed. I used to think I was the only person I knew who could loose a debate without letting the other guy get a word in. :-) Both are now committed and will appear online within the next 6 hours. Phew! Thanks a lot, Brian. Please keep those patches coming (and I promise to be build less walls next time). Will do - but right now I have other fish to fry. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Ongoing problem with random Handler Not Found
I've got an existing production system which I've built and maintained over the past 3 years - I've never had a problem with mod_perl until about 4 months ago. During that time I built a new module - PostBlotter.pm, which was not preloaded in startup.pl (I don't typically preload most of our periphery applications). We have about 90% of our 20 modules in a non-preload state, and have never had a problem. However, with this project, PostBlotter and ONLY PostBlotter began exhibiting random (maybe 4 out of 10 requests?) 500 errors - with an error log note of: Undefined subroutine Apache::MuniCenter::MarkupMatrix::PostBlotter::handler called. And no further information. The cause of this could not be determined, and it was found that setting it to preload in startup.pl completely resolved the problem. Now, a few months later, I've written yet another not-for-preload, periphery process, and I'm seeing the exact same problem, again about 4 out of 10 times: [Mon Nov 17 10:46:43 2003] [error] Undefined subroutine Apache::MuniCenter::MarkupMatrix::TaxSwap::handler called. Unfortunately, preloading this was not possible - we found that Inline::Java, which we load in for various bond calculation routines, does not behave properly when preloaded, and causes the entire mod_perl system to be unstable; consequently we can't preload this module. At this point I need to know WHY mod_perl randomly can't find the handler, which is properly written, runs through perl -c cleanly, under strict and warnings, and has a 1; at the bottom. Are there any known issues that could cause this? Any easy way to produce a trace of where Apache is looking and what's happening (preferably not a recompile of apache - a trace perl module I can load would be better). This problem exhibits across my development, test/integration, staging, and production environments so it's not a single box issue. Perl version v5.8.1 for Apache/1.3.29 (Unix) mod_perl/1.29 mod_ssl/2.8.16 OpenSSL/0.9.7c Note this problem occurred under Perl 5.6/5.6.1 and Apache 1.3.26, mod_perl 1.26 as well. -- Brendan W. McAdams | [EMAIL PROTECTED] Senior Applications Developer | (646) 375-1140 TheMuniCenter, LLC | www.themunicenter.com -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: transaction Apache::DBI
On Mon, 2003-11-17 at 09:30, Jamie Le Tual wrote: An interesting test would be to put a sleep(20) adter the delcaration of the second database handle, then open a mysql shell and do a : show processlist; There's no need to go to all that trouble. Turning on debugging for Apache::DBI will tell you when new connection are made. I already tried it, and I can confirm that no new connections are being made. Because Apache::DBI uses the DSN/username/password combination to uniquely identify a connection within its connection pool, the second connect() is getting returned the first handle, _and_ you are resetting AutoCommit on the fly. Because $db2 and $db1 are references to the same connection in the pool, $db1 will get the attributes you set on $db2. That isn't what's happening. Instead, asking for $db2 causes $db1 to return to its original state, before AutoCommit was set. This shouldn't happen, and it doesn't happen when you use connect_cached instead of Apache::DBI. Apache::DBI doesn't make any effort to return database handles to their original state when you call connect. If you change something, it should stay changed. I think there is something strange going on deep within DBI itself. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
1 server, 2 databases + sites = Mixed calls
Hi everyone I would search archives for this but I honestly can't think what to search for in this case :( I have 1 server, with 2 practically identical sites on it. And calls to databases are getting mixed up (Using MySQL and DBI) I have an ensim server running: Apache/1.3.27 mod_perl/1.24_01 (Red-Hat/Linux) I'm using PerlAuthenHandler Apache::AuthDBI::authen I'm calling it like so: PerlSetVar Auth_DBI_data_source DBI:mysql:angie_mydomain_net I have my own handler calling my Perl Script for all .html pages: Action add-vertmod /perl/onefile.pl AddHandler add-vertmod .html onfile.pl calls a load of my modules like so: use lib /home/virtual/site17/fst/var/www/perl/vert; use SiteMap; use Event; inside my modules I have the following DBI Code my ($dbname, $host, $user, $password, $tablename) = qw(angie_mydomain_net localhost username password Event); my $dbh = DBI-connect(DBI:mysql:$dbname:$host,$user,$password) or die can't connect user $user to to database $host:$dbname; OK that's the setup: I set up another subdomain on the server, which lives in folder /home/virtual/site29 I changed all references to site17 to site29, and all references to the database and it's username and password. I've double checked this twice in BBedit now. I didn't miss any. So I have one set of modules in /home/virtual/site17/fst/var/www/perl/vert and another in /home/virtual/site29/fst/var/www/perl/vert And those modules have different database information (but tables inside are the same). As you've probably guessed I'm trying to get a mirror site up so I can work on it while people use the other one safely. However it seems the database calls are getting mixed up. Sometimes actions get set to one instead of the other, it's hard to actually say what is happening, It looks like a var is being overwritten, but I've used my everywhere so I can't work it out. A bit stuck... Any ideas? Thanks Angie -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: 1 server, 2 databases + sites = Mixed calls
On Mon, 2003-11-17 at 12:40, angie ahl wrote: So I have one set of modules in /home/virtual/site17/fst/var/www/perl/vert and another in /home/virtual/site29/fst/var/www/perl/vert And those modules have different database information (but tables inside are the same). Sounds like you're having namespace collisions. You can't run two different modules with the same package name in the same interpreter. Take a look at Apache::PerlVINC for a workaround, or run two separate apaches. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Using SSI with perl handlers?
On Mon, 2003-11-17 at 02:15, Christopher P. Lindsey wrote: I actually get the same results, but I appreciate the idea! Hmmm, then the problem is most likely in the code that you are including. Does it happen if you include a static file instead? Can you try taking things out of your included script to see if the problem goes away? - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
PerlSetVar with '0' value
Hi all,
I have this PerlSetVar behaviour. Suppose to have:
Location /foo
SetHander perl-script
PerlSetVar Something 0
PerlResponseHandler MyModule
/Location
But in MyModule.pm, $r-dir_config('Something') returns an undef value instead
of 0 (zero). This happens on both mod_perl generations (I have Perl 5.8.1 with mp
1.29 and mp 1.99_10).
Also I've tried with:
PerlSetVar Something '0'
PerlSetVar Something 0
My problem is that the my default value of 'Something' isn't 0 and 0 is a
possible value for my module. So, currently I have to code around for example
with:
PerlSetVar Something none
in order to pass a correspondent 0 value.
Maybe it is a known behaviour, but... I've forgotten something in the docs about
it? :-)
I'm surprise of this, because in my Apache (1.x) C modules experience, TAKE1 (or
TAKE2) directive doesn't have the same behaviour returnig args also with 0
values.
by
- Enrico
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Using SSI with perl handlers?
sorry, I sent this yesterday from a different email account but it doesn't look like it went through... Christopher P. Lindsey wrote: Hi, I sent out an email yesterday describing some problems that I'm having with Apache::SSI. I've narrowed things down significantly and hope that this extra info can help someone point me in the right direction. Basically, it all boils down to the fact that once an SSI directive with #EXEC CGI is parsed, the document fails to parse any further SSI directives *if the script to be executed has a perl-script handler.* this is a documented feature from the manpage: =head1 CAVEATS * When chaining handlers via Apache::Filter, if you use !--#include...-- or !--#exec cgi=...--, then Apache::SSI must be the last filter in the chain. This is because Apache::SSI uses $r-lookup_uri(...)-run to include the files, and this sends the output through C's stdout rather than Perl's STDOUT. Thus Apache::Filter can't catch it and filter it. for a way around this, see recipe 10.2 in the mod_perl developer's cookbook: http://www.modperlcookbook.org/code/ch10/Cookbook/SSI.pm you can also try Apache::FakeSSI (includes with Apache::SSI) but I haven't tried it myself. HTH --Geoff -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: PerlSetVar with '0' value
Enrico Sorcinelli wrote:
Hi all,
I have this PerlSetVar behaviour. Suppose to have:
Location /foo
SetHander perl-script
PerlSetVar Something 0
PerlResponseHandler MyModule
/Location
But in MyModule.pm, $r-dir_config('Something') returns an undef value instead
of 0 (zero). This happens on both mod_perl generations (I have Perl 5.8.1 with mp
1.29 and mp 1.99_10).
hmm. PerlSetVar uses apache tables, so I'm not sure whether the problem is
with mod_perl or apache's internal treatment of 0 in C land and the
subsequent perl translation. but I'll look into it for you next week.
thanks for reporting it.
I'm surprise of this, because in my Apache (1.x) C modules experience, TAKE1 (or
TAKE2) directive doesn't have the same behaviour returnig args also with 0
values.
this uses a completely different mechanism :)
--Geoff
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: 1 server, 2 databases + sites = Mixed calls
Thanks for that, but CPAN seems to indicate that Apache::PerlVINC will have a performance hit (which I need to avoid if possible). would the following work? if the 2 sites call a different directory name eg: site 1: use lib /home/virtual/site17/fst/var/www/perl/verttemp; use verttemp::SiteMap; site 2: use lib /home/virtual/site17/fst/var/www/perl/vert; use vert::SiteMap; or should that be use lib /home/virtual/site17/fst/var/www/perl; ie missing the directory name that corresponds with the module name Have I undestood that concept correctly? Could I still call it via my $page = SiteMap-new; or would I need to say my $page = vert::SiteMap-new; A little find and replacing wouldn't kill me ;) Cheers Angie on 17/11/03 Perrin Harkins said: On Mon, 2003-11-17 at 12:40, angie ahl wrote: So I have one set of modules in /home/virtual/site17/fst/var/www/perl/vert and another in /home/virtual/site29/fst/var/www/perl/vert And those modules have different database information (but tables inside are the same). Sounds like you're having namespace collisions. You can't run two different modules with the same package name in the same interpreter. Take a look at Apache::PerlVINC for a workaround, or run two separate apaches. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: 1 server, 2 databases + sites = Mixed calls
On Mon, 2003-11-17 at 13:47, angie ahl wrote: Thanks for that, but CPAN seems to indicate that Apache::PerlVINC will have a performance hit (which I need to avoid if possible). It's really for development use. if the 2 sites call a different directory name eg: site 1: use lib /home/virtual/site17/fst/var/www/perl/verttemp; use verttemp::SiteMap; site 2: use lib /home/virtual/site17/fst/var/www/perl/vert; use vert::SiteMap; That will work, if you change the package names inside every file. Have I undestood that concept correctly? Could I still call it via my $page = SiteMap-new; or would I need to say my $page = vert::SiteMap-new; The latter. A little find and replacing wouldn't kill me ;) It seems simper to just run two instances of apache. You can just start the same binary twice, with different conf files. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: mp2 -undefined symbol in error_log - HOWTO
You are quite welcome. I hope I have more chances to contribute, I feel like I owe a great debt. -Matisse At 9:47 PM -0800 11/14/03, Stas Bekman wrote: Matisse Enzer wrote: Here's a very rough draft of what do do if the error_log includes any undefined symbol errors. It's mostly based on Stas' advice for when i had this problem last week. Just perfect, Matisse. I wish my rough drafts were all like this. I've committed it after podifying it and doing a few minor tweaks (mainly formatting). Here it is: http://perl.apache.org/docs/2.0/user/troubleshooting/troubleshooting.html#undefined_symbol__apr_table_compress Muchas gracias, keep those patches coming __ 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 -- -- Matisse Enzer Doodlelab Inc. 415-925-5294 ext. 212 (office) 415-225-6703 (mobile) -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: strange problem with tied STDIN
SUCH SANMARTÍN, GERARD wrote:
I say strange because i have the next
read(STDIN,$buf,$apache_headers-{'Content-length'});
and it works (when in POST method).
But if i write
$r-read($buf,$apache_headers-{'Content-length'});
then i get no $buf, no data.
I've read some comments about this
http://www.gossamer-threads.com/archive/mod_perl_C1/dev_F4/Problem_with_tied
_STDIN,_CGI.pm_mod_perl_1.26_and_perl_5.6.1_P7683/
and i like to believe in newest perl - modperl version this is solved.
I use
Apache/2.0.47 (Win32) mod_perl/1.99_10-dev Perl/v5.8.0 Server at localhost
Port 80
This another link
http://www.gossamer-threads.com/archive/mod_perl_C1/modperl_F7/%5Bmp2%5D_POS
T_of_multipart/form-data_broken_in_1.99_10_P88430/
talks about the necessity of use the tied structure rather than the other.
So, any idea?
Please report bugs as explained at:
http://perl.apache.org/bugs/. We need to have a simple test case that we can
reproduce the problem with. Also I'd appreciate if you upgrade first to
1.99_11 or even better the current cvs.
__
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
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Using SSI with perl handlers?
Basically, it all boils down to the fact that once an SSI directive with #EXEC CGI is parsed, the document fails to parse any further SSI directives *if the script to be executed has a perl-script handler.* from the manpage: * When chaining handlers via Apache::Filter, if you use !--#include...-- or !--#exec cgi=...--, then Apache::SSI must be the last filter in the chain. This is because Apache::SSI uses $r-lookup_uri(...)-run to include the files, and this sends the output through C's stdout rather than Perl's STDOUT. Thus Apache::Filter can't catch it and filter it. I'm not sure if it's the same problem as I was having (I was using Apache::OutputChain instead because it seems to be more memory-friendly), but switching to Apache::Filter with Apache::SSI *almost* works: Files ~ \.phtml$ SetHandler perl-script PerlSetVar Filter On PerlModule Apache::Filter Apache::RegistryFilter Apache::SSI PerlHandler Apache::RegistryFilter Apache::SSI /Files The problem now is that everything is sent out encoded as text/plain. If I add a line like this AddType text/html .phtml The problem goes away and everything is hunky-dory. But that seems wrong. Is it? Am I missing something? Turning PerlSendHeader On or Off doesn't change things any. for a way around this, see recipe 10.2 in the mod_perl developer's cookbook: http://www.modperlcookbook.org/code/ch10/Cookbook/SSI.pm Cool, thanks! I'll try to get Apache::Filter working first, but if that doesn't work, it's good to have a fallback. That looks like a great resource. I'm definitely ordering a copy! you can also try Apache::FakeSSI (includes with Apache::SSI) but I haven't tried it myself. Does anyone know how to force Apache::SSIChain to use Apache::FakeSSI instead of Apache::SSI? It was giving me fits. Chris -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SOLVED (was 'Using SSI with perl handlers?')
On Mon, 2003-11-17 at 15:59, Christopher P. Lindsey wrote: The problem now is that everything is sent out encoded as text/plain. If I add a line like this AddType text/html .phtml D'oh! I hate responding to my own posts, but minutes after sending this I remembered Apache::PassHtml. Changing it to Files ~ \.phtml$ SetHandler perl-script PerlSetVar Filter On PerlModule Apache::Filter Apache::RegistryFilter Apache::SSI PerlHandler Apache::RegistryFilter Apache::PassHtml Apache::SSI /Files makes everything work hunky-dory. I hate to be a wet blanket, but that looks very wrong to me. Apache::PassHtml does not work with Apache::Filter, so you probably are not running Apache::SSI on these files at all. The problem you were having with headers can be fixed by setting the content-type in your script, which is something you are supposed to do anyway in any web script. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
RE: Question about headers and Apache::Filter
Thanks for the info Perrin, I was able to make it work by adding an AddType. I am still wondering why every example I see with Apache::RegistryFilter and Apache::SSI makes no mention of having to set the header. Robert -Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED] Sent: Monday, November 17, 2003 5:53 PM To: Robert Knaak Cc: [EMAIL PROTECTED] Subject: Re: Question about headers and Apache::Filter On Fri, 2003-11-14 at 14:24, Robert Knaak wrote: It seems that PerlSendHeader On has no effect when you are using Apache::RegistryFilter, how can I get the proper headed type sent? Are you still having trouble with this? It looks to me like you can fix it by adding $r-content_type(text/html) to your scripts, or you can use an AddType directive in httpd.conf if you don't want to edit your scripts. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
RE: Question about headers and Apache::Filter
On Mon, 2003-11-17 at 18:41, Robert Knaak wrote: I am still wondering why every example I see with Apache::RegistryFilter and Apache::SSI makes no mention of having to set the header. The only time you have to set the header is if you were relying on PerlSendHeader instead of setting the content-type in your script. It definitely should mention the incompatibility with PerlSendHeader. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SOLVED (was 'Using SSI with perl handlers?')
I hate to be a wet blanket, but that looks very wrong to me. Apache::PassHtml does not work with Apache::Filter, so you probably are not running Apache::SSI on these files at all. Hi Perrin, You are, of course, right. :) Apache::SSI was being used, but the Content-Type: wasn't being set. My browser (Opera) was just trying to be too smart. After a little nap (hey, I've been spending a lot of hours on this) I looked at things a little more closely. Why PassHtml was making it work with Opera is a mystery to me. The problem you were having with headers can be fixed by setting the content-type in your script, which is something you are supposed to do anyway in any web script. For some reason I'm losing my headers. The script uses CGI.pm; here's the output if I run it on the commandline: Expires: Tue, 18 Nov 2003 04:32:14 GMT Date: Tue, 18 Nov 2003 04:32:14 GMT Pragma: no-cache Content-Type: text/html; charset=ISO-8859-1 However, here's what 'lynx -mime-header -source [URL]' gives me: Date: Tue, 18 Nov 2003 04:40:47 GMT Server: Apache Connection: close Content-Type: text/plain I can use an AddType directive to force .pl files to be sent as text/html, but then I lose my Expires: headers and any others that I may have set. Looks like another long night! (Unless someone has the answer. Please. Someone have the answer!) Thanks for looking at this. Chris -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
ENC: Problem Instaling MOD_PERL for Win32 (Windows 2000)
-Mensagem original- De: Carlos - Fundação MT [mailto:[EMAIL PROTECTED] Enviada em: Monday, November 17, 2003 3:09 PM Para: '[EMAIL PROTECTED]org' Assunto: Problem Instaling MOD_PERL for Win32 (Windows 2000) Good Afternoon, Id like to install mod_perl for windows 2000, but I donno how search the file mod_perl.zip. I need to help for you to install the Module Perl for Apache 1.3.29 and Perl 5.6.1 Build 6xx Best Regards, Carlos Augusto Perez Lima
Re: ENC: Problem Instaling MOD_PERL for Win32 (Windows 2000)
On Mon, 17 Nov 2003, [iso-8859-1] Carlos - Fundao MT wrote: Id like to install mod_perl for windows 2000, but I donno how search the file mod_perl.zip. I need to help for you to install the Module Perl for Apache 1.3.29 and Perl 5.6.1 Build 6xx The page http://perl.apache.org/docs/1.0/os/win32/install.html#PPM_Packages describes how to install mod_perl by the ppm utility for Win32. -- best regards, randy kobes -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
cvs commit: modperl-2.0 Changes
geoff 2003/11/17 15:00:39 Modified:.Changes Log: add :filetype import tag to APR::Const Revision ChangesPath 1.254 +2 -0 modperl-2.0/Changes Index: Changes === RCS file: /home/cvs/modperl-2.0/Changes,v retrieving revision 1.253 retrieving revision 1.254 diff -u -r1.253 -r1.254 --- Changes 17 Nov 2003 01:11:06 - 1.253 +++ Changes 17 Nov 2003 23:00:38 - 1.254 @@ -12,6 +12,8 @@ =item 1.99_12-dev +add :filetype import tag to APR::Const [Geoffrey Young] + Perl sections now proprely set $0 to the name of the configuration file they are in. [Philippe M. Chiasson]
cvs commit: modperl-2.0/xs/APR/Finfo - New directory
geoff 2003/11/17 15:25:06 modperl-2.0/xs/APR/Finfo - New directory
cvs commit: modperl-2.0/xs/tables/current/ModPerl FunctionTable.pm
geoff 2003/11/17 15:27:11
Modified:xs/maps apr_functions.map apr_structures.map apr_types.map
xs/tables/current/ModPerl FunctionTable.pm
Added: xs/APR/Finfo APR__Finfo.h
Log:
add access to $r-finfo() and related APR::Finfo methods,
such as $r-finfo-size(), $r-finfo-mtime(), and
APR::Finfo::stat()
Revision ChangesPath
1.1 modperl-2.0/xs/APR/Finfo/APR__Finfo.h
Index: APR__Finfo.h
===
static MP_INLINE
apr_finfo_t *mpxs_Apache__RequestRec_finfo(request_rec *r)
{
return r-finfo;
}
1.60 +5 -2 modperl-2.0/xs/maps/apr_functions.map
Index: apr_functions.map
===
RCS file: /home/cvs/modperl-2.0/xs/maps/apr_functions.map,v
retrieving revision 1.59
retrieving revision 1.60
diff -u -r1.59 -r1.60
--- apr_functions.map 26 Sep 2003 08:29:26 - 1.59
+++ apr_functions.map 17 Nov 2003 23:27:11 - 1.60
@@ -301,9 +301,12 @@
apr_filepath_root
apr_filepath_set
--MODULE=APR::Finfo
- apr_lstat
+MODULE=APR::Finfo
+-apr_lstat
apr_stat
+
+PACKAGE=Apache::RequestRec
+ mpxs_Apache__RequestRec_finfo
!MODULE=APR::String
apr_collapse_spaces
1.9 +2 -2 modperl-2.0/xs/maps/apr_structures.map
Index: apr_structures.map
===
RCS file: /home/cvs/modperl-2.0/xs/maps/apr_structures.map,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- apr_structures.map19 May 2002 01:05:30 - 1.8
+++ apr_structures.map17 Nov 2003 23:27:11 - 1.9
@@ -28,7 +28,7 @@
list
/apr_bucket
-!apr_finfo_t
+apr_finfo_t
pool
valid
protection
@@ -45,7 +45,7 @@
ctime
fname
name
- filehand
+- filehand
/apr_finfo_t
!apr_sockaddr_t
1.21 +2 -2 modperl-2.0/xs/maps/apr_types.map
Index: apr_types.map
===
RCS file: /home/cvs/modperl-2.0/xs/maps/apr_types.map,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- apr_types.map 18 Mar 2003 06:52:41 - 1.20
+++ apr_types.map 17 Nov 2003 23:27:11 - 1.21
@@ -62,9 +62,9 @@
struct apr_os_dir_t | UNDEFINED
apr_seek_where_t | UNDEFINED
struct apr_pollfd_t | UNDEFINED
-apr_fileperms_t | UNDEFINED
+apr_fileperms_t | IV
struct apr_finfo_t | APR::Finfo
-apr_filetype_e | UNDEFINED
+apr_filetype_e | IV
apr_dev_t| NV
apr_ino_t| IV
1.130 +10 -0 modperl-2.0/xs/tables/current/ModPerl/FunctionTable.pm
Index: FunctionTable.pm
===
RCS file: /home/cvs/modperl-2.0/xs/tables/current/ModPerl/FunctionTable.pm,v
retrieving revision 1.129
retrieving revision 1.130
diff -u -r1.129 -r1.130
--- FunctionTable.pm 6 Nov 2003 20:14:07 - 1.129
+++ FunctionTable.pm 17 Nov 2003 23:27:11 - 1.130
@@ -5632,6 +5632,16 @@
]
},
{
+'return_type' = 'apr_finfo_t *',
+'name' = 'mpxs_Apache__RequestRec_finfo',
+'args' = [
+ {
+'type' = 'request_rec *',
+'name' = 'r'
+ }
+]
+ },
+ {
'return_type' = 'SV *',
'name' = 'mpxs_Apache__RequestRec_pnotes',
'args' = [
cvs commit: modperl-2.0 Changes
geoff 2003/11/17 15:27:46 Modified:.Changes Log: add access to $r-finfo() and related APR::Finfo methods, such as $r-finfo-size(), $r-finfo-mtime(), and APR::Finfo::stat() Revision ChangesPath 1.255 +4 -0 modperl-2.0/Changes Index: Changes === RCS file: /home/cvs/modperl-2.0/Changes,v retrieving revision 1.254 retrieving revision 1.255 diff -u -r1.254 -r1.255 --- Changes 17 Nov 2003 23:00:38 - 1.254 +++ Changes 17 Nov 2003 23:27:46 - 1.255 @@ -12,6 +12,10 @@ =item 1.99_12-dev +add access to $r-finfo() and related APR::Finfo methods, +such as $r-finfo-size(), $r-finfo-mtime(), and +APR::Finfo::stat() [Geoffrey Young] + add :filetype import tag to APR::Const [Geoffrey Young] Perl sections now proprely set $0 to the name of the configuration
cvs commit: modperl-2.0/t/response/TestAPR finfo.pm
geoff 2003/11/17 15:31:02
Added: t/response/TestAPR finfo.pm
Log:
add $r-finfo tests
Revision ChangesPath
1.1 modperl-2.0/t/response/TestAPR/finfo.pm
Index: finfo.pm
===
package TestAPR::finfo;
use strict;
use warnings FATAL = 'all';
use Apache::Test;
use Apache::TestUtil;
use Apache::TestTrace;
use Apache::RequestRec ();
use APR::Finfo ();
use APR::Const -compile = qw(SUCCESS FINFO_NORM REG
WREAD WWRITE WEXECUTE);
use File::Spec::Functions qw(catfile);
use Fcntl qw(:mode);
use Apache::Const -compile = 'OK';
sub handler {
my $r = shift;
plan $r, tests = 17;
{
my $finfo = $r-finfo;
my $isa = $finfo-isa('APR::Finfo');
t_debug \$r-finfo $finfo;
ok $isa;
}
{
my $pool = $r-finfo-pool;
my $isa = $pool-isa('APR::Pool');
t_debug \$r-finfo-pool $pool;
ok $isa;
}
my $file = Apache-server_root_relative(catfile qw(htdocs index.html));
# stat tests
{
# populate the finfo struct first
my $status = APR::Finfo::stat($r-finfo, $file,
APR::FINFO_NORM, $r-pool);
ok t_cmp(APR::SUCCESS,
$status,
stat $file);
# now, get information from perl's stat()
our ($device, $inode, $protection, $nlink, $user, $group,
undef, $size, $atime, $mtime, $ctime) = stat $file;
# compare stat fields between perl and apr_stat
{
no strict qw(refs);
foreach my $method (qw(device inode nlink user group
size atime mtime ctime)) {
ok t_cmp(${$method},
$r-finfo-$method(),
\$r-finfo-$method());
}
}
# match world bits
ok t_cmp($protection S_IROTH,
$r-finfo-protection APR::WREAD,
'$r-finfo-protection() APR::WREAD');
ok t_cmp($protection S_IWOTH,
$r-finfo-protection APR::WWRITE,
'$r-finfo-protection() APR::WWRITE');
ok t_cmp($protection S_IXOTH,
$r-finfo-protection APR::WEXECUTE,
'$r-finfo-protection() APR::WEXECUTE');
}
# tests for stuff not in perl's stat
{
ok t_cmp($file,
$r-finfo-fname,
'$r-finfo-fname()');
ok t_cmp(APR::REG,
$r-finfo-filetype,
'$r-finfo-filetype()');
}
Apache::OK;
}
1;
cvs commit: modperl-2.0/todo release
stas2003/11/17 16:54:10 Modified:todo release Log: some updated for the static build issue Revision ChangesPath 1.2 +5 -1 modperl-2.0/todo/release Index: release === RCS file: /home/cvs/modperl-2.0/todo/release,v retrieving revision 1.1 retrieving revision 1.2 diff -u -u -r1.1 -r1.2 --- release 17 Nov 2003 23:00:34 - 1.1 +++ release 18 Nov 2003 00:54:10 - 1.2 @@ -4,7 +4,11 @@ * static build - if we make it working on OpenBSD, AIX and FreeBSD, then it's not important to fix the DSO issues, otherwise make the - DSO issues a release issue. + DSO issues in (todo/bugs_build) a release issue. + httpd-apreq-2 has recently implemented a static build support, we + could probably try to re-use some of the code that was written to do + that, though they use autoconf, which is not quite what we + want. Anyway it's something to look at. * perl Makefile.PL PREFIX=/foo/bar works fine, however Makefile.PL'll still refuse to build unless MP_INST_APACHE2=1 is passed. It should
Re: cvs commit: modperl-2.0/xs/tables/current/ModPerl FunctionTable.pm
On Mon, 2003-11-17 at 15:27, [EMAIL PROTECTED] wrote:
geoff 2003/11/17 15:27:11
Modified:xs/maps apr_functions.map apr_structures.map apr_types.map
xs/tables/current/ModPerl FunctionTable.pm
Added: xs/APR/Finfo APR__Finfo.h
Log:
add access to $r-finfo() and related APR::Finfo methods,
such as $r-finfo-size(), $r-finfo-mtime(), and
APR::Finfo::stat()
Way to go Geoff
Wonder what dark corner of Las Vegas you are hiding in to get this code
out ;-)
Revision ChangesPath
1.1 modperl-2.0/xs/APR/Finfo/APR__Finfo.h
Index: APR__Finfo.h
===
static MP_INLINE
apr_finfo_t *mpxs_Apache__RequestRec_finfo(request_rec *r)
{
return r-finfo;
}
1.60 +5 -2 modperl-2.0/xs/maps/apr_functions.map
Index: apr_functions.map
===
RCS file: /home/cvs/modperl-2.0/xs/maps/apr_functions.map,v
retrieving revision 1.59
retrieving revision 1.60
diff -u -r1.59 -r1.60
--- apr_functions.map 26 Sep 2003 08:29:26 - 1.59
+++ apr_functions.map 17 Nov 2003 23:27:11 - 1.60
@@ -301,9 +301,12 @@
apr_filepath_root
apr_filepath_set
--MODULE=APR::Finfo
- apr_lstat
+MODULE=APR::Finfo
+-apr_lstat
apr_stat
+
+PACKAGE=Apache::RequestRec
+ mpxs_Apache__RequestRec_finfo
!MODULE=APR::String
apr_collapse_spaces
1.9 +2 -2 modperl-2.0/xs/maps/apr_structures.map
Index: apr_structures.map
===
RCS file: /home/cvs/modperl-2.0/xs/maps/apr_structures.map,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- apr_structures.map 19 May 2002 01:05:30 - 1.8
+++ apr_structures.map 17 Nov 2003 23:27:11 - 1.9
@@ -28,7 +28,7 @@
list
/apr_bucket
-!apr_finfo_t
+apr_finfo_t
pool
valid
protection
@@ -45,7 +45,7 @@
ctime
fname
name
- filehand
+- filehand
/apr_finfo_t
!apr_sockaddr_t
1.21 +2 -2 modperl-2.0/xs/maps/apr_types.map
Index: apr_types.map
===
RCS file: /home/cvs/modperl-2.0/xs/maps/apr_types.map,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- apr_types.map 18 Mar 2003 06:52:41 - 1.20
+++ apr_types.map 17 Nov 2003 23:27:11 - 1.21
@@ -62,9 +62,9 @@
struct apr_os_dir_t | UNDEFINED
apr_seek_where_t | UNDEFINED
struct apr_pollfd_t | UNDEFINED
-apr_fileperms_t | UNDEFINED
+apr_fileperms_t | IV
struct apr_finfo_t | APR::Finfo
-apr_filetype_e | UNDEFINED
+apr_filetype_e | IV
apr_dev_t| NV
apr_ino_t| IV
1.130 +10 -0 modperl-2.0/xs/tables/current/ModPerl/FunctionTable.pm
Index: FunctionTable.pm
===
RCS file: /home/cvs/modperl-2.0/xs/tables/current/ModPerl/FunctionTable.pm,v
retrieving revision 1.129
retrieving revision 1.130
diff -u -r1.129 -r1.130
--- FunctionTable.pm6 Nov 2003 20:14:07 - 1.129
+++ FunctionTable.pm17 Nov 2003 23:27:11 - 1.130
@@ -5632,6 +5632,16 @@
]
},
{
+'return_type' = 'apr_finfo_t *',
+'name' = 'mpxs_Apache__RequestRec_finfo',
+'args' = [
+ {
+'type' = 'request_rec *',
+'name' = 'r'
+ }
+]
+ },
+ {
'return_type' = 'SV *',
'name' = 'mpxs_Apache__RequestRec_pnotes',
'args' = [
