Re: Apache2::Request undefined symbol
Mark Hedges wrote: That's a normal thing. All installed modules put their config into mods-available. Then you use `a2enmod` to manage those symlinks and turn them on or off in mods-enabled. +1 I believe all Debian-based distributions have done this with Apache 2 for a few years now. It scared me quite nicely when I upgraded the first time they did this (on Debian unstable, I believe) and found none of my modules were enabled anymore and my Apache configuration had been overwritten. :) Colin
Re: Apache configuration question - restrict folder access to local machine only
John ORourke wrote: Expertly brought back on topic there, Torsten... if I ask about the price of beans and how it relates to global warming can you give me a mod_perl related answer? :) Price of beans increases due to fuel costs, driven by the economy, affected by global warming... um... all because mod_perl is used on so many servers that data center power requirements have gone through the roof and required more fossil fuel power plants to be built! ;) Not Torsten, Colin
Re: Many handlers in the same module
Jonathan Vanasco wrote: On Mar 28, 2008, at 3:11 PM, Colin Wetherbee wrote: Care to add one, just to see what happens? :) You know you've been working too much on the Business Side when you stop testing stuff like that automatically. sigh... Indeed. :) ok... it works if i have [snip] I think your testing concludes that our InitHandler definitions are interpreted differently by mod_perl. i.e., Mine only works if - is used, but yours works for both - and ::, where - takes precedence over ::. I believe your tested behavior would be the expected behavior. Is that correct? :P Also, I wonder if the difference is caused by the different ways we're adding handlers? I specify mine in the virtual host configuration, and it looks like you specify yours in startup.pl. Colin
Re: Many handlers in the same module
� wrote: Just for the rest of us : does anyone care to summarise what works and works not (inasfar as not necessarily documented and/or intuitive) ? And maybe what the original point of this interesting thread was ? Sure, but I don't think we're finished quite yet. ;) Colin
Re: Many handlers in the same module
Jonathan Vanasco wrote: On Mar 27, 2008, at 8:43 PM, Colin Wetherbee wrote: Hm. Yep. ResponseHandler can interpret the ::ResponseHandler part as being a function within Handler.pm, but that does *not* work for InitHandler. i have it set up using PerlFixupHandler PerlResponseHandler PerlCleanupHandler PerlPostReadRequestHandler I haven't tried init handler Care to add one, just to see what happens? :) do you have , perhaps, a conflict in packages and subs? ie: JetSet/Handler.pm JetSet/Handler/ResponseHandler.pm or something like that, where we need a difference between :: and - ? I don't have anything like that. The only subdirectory under JetSet is called 'static', which just contains a couple .html files. Colin
Re: Many handlers in the same module
Jonathan Vanasco wrote: On Mar 26, 2008, at 9:47 AM, Colin Wetherbee wrote: We seem to have solved the problem, but for the sake of conversation... When I've tried that in the past, mod_perl would always look for handler() within JetSet::Handler::AccessHandler.pm. Wow. I've got 5 sites in production right now... and dating back to 03/04 with multiple specified handlers like that I've never had that issue come up, nor have i planned for it. I could see that happening though Wow... again... I never thought of that. Yep... here it is: [Fri Mar 28 00:37:00 2008] [error] [client 192.168.171.80] failed to resolve handler `JetSet::Handler::InitHandler': Can't locate JetSet/Handler/InitHandler.pm in @INC (@INC contains: /home/cww/sites/js.iron.denterprises.org/htdocs/jet-set /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl . /etc/apache2) at (eval 7) line 3.\n, referer: http://js/jet-set/login From this bit of the virtual host: Location /jet-set PerlSetVar ReloadDirectories /home/cww/sites/js.iron.denterprises.org/htdoc SetHandler perl-script PerlInitHandler Apache2::Reload #PerlInitHandler JetSet::Handler-InitHandler PerlInitHandler JetSet::Handler::InitHandler #PerlResponseHandler JetSet::Handler-ResponseHandler PerlResponseHandler JetSet::Handler::ResponseHandler /Location (Note the PerlSetVar line was truncated by my non-use of line-wrap in vim.) Actually, though, I think I remember ResponseHandler working OK... so, I'm going to put InitHandler back to the way it was (with -) and try again. Hm. Yep. ResponseHandler can interpret the ::ResponseHandler part as being a function within Handler.pm, but that does *not* work for InitHandler. Interesting. For completeness, the above does not work, but the following does. Location /jet-set PerlSetVar ReloadDirectories /home/cww/sites/js.iron.denterprises.org/htdoc SetHandler perl-script PerlInitHandler Apache2::Reload PerlInitHandler JetSet::Handler-InitHandler #PerlResponseHandler JetSet::Handler-ResponseHandler PerlResponseHandler JetSet::Handler::ResponseHandler /Location Where InitHandler() and ResponseHandler() are subs declared within Handler.pm. Colin
Re: Many handlers in the same module
Jonathan Vanasco wrote:
On Mar 19, 2008, at 2:22 PM, Colin Wetherbee wrote:
PerlAccessHandler JetSet::Handler-AccessHandler
PerlResponseHandler JetSet::Handler-ResponseHandler
sub ResponseHandler
{
my (undef, $r) = @_;
# ...
}
what about...
PerlAccessHandler JetSet::Handler::AccessHandler
sub AccessHandler {
my ($r) = @_;
}
We seem to have solved the problem, but for the sake of conversation...
When I've tried that in the past, mod_perl would always look for
handler() within JetSet::Handler::AccessHandler.pm.
Colin
Re: Many handlers in the same module
John ORourke wrote: The only down-side is that (AFAICR) it is creating a new object for each request - my handler is quite expensive to set up, so I have a persistent object and use method handlers like this: Ah, that's quite neat. I might give that a shot. Thanks for the suggestion. Colin
Re: troubleshooting
Beginner wrote: dpkg -l libapache2-mod-perl2 shows: ii libapache2-mod-perl2 2.0.2-2.4 It doesn't mention etch but I think this is the correct version. FYI, here are the versions I get for Debian testing (I believe that's etch at the moment?). [EMAIL PROTECTED]:~$ dpkg -l libapache2-mod-perl\* perl\* apache\* | egrep ^ii ii apache2 2.2.6-2 Next generation, scalable, extendable web se ii apache2-mpm-prefork 2.2.8-1 Traditional model for Apache HTTPD ii apache2-utils 2.2.6-2 utility programs for webservers ii apache2.2-common2.2.8-1 Next generation, scalable, extendable web se ii libapache2-mod-perl22.0.3-2 Integration of perl with the Apache2 web ser ii libapache2-mod-perl2-doc2.0.3-2 Integration of perl with the Apache2 web ser ii perl5.8.8-12 Larry Wall's Practical Extraction and Report ii perl-base 5.8.8-12 The Pathologically Eclectic Rubbish Lister ii perl-doc5.8.8-12 Perl documentation ii perl-mapscript 5.0.0-3 Perl MapServer library ii perl-modules5.8.8-12 Core Perl modules These all work wonderfully together. You probably don't need perl-mapscript, but at least have a look at the rest of them. Colin
Re: troubleshooting
Colin Wetherbee wrote: Beginner wrote: dpkg -l libapache2-mod-perl2 shows: ii libapache2-mod-perl2 2.0.2-2.4 It doesn't mention etch but I think this is the correct version. FYI, here are the versions I get for Debian testing (I believe that's etch at the moment?). [EMAIL PROTECTED]:~$ dpkg -l libapache2-mod-perl\* perl\* apache\* | egrep ^ii This, too: [EMAIL PROTECTED]:~$ dpkg -l \*apr\* | egrep ^ii ii libapache2-mod-apreq2 2.08-5 generic Apache request library - Apache modu ii libapr1 1.2.11-1 The Apache Portable Runtime Library ii libapreq2 2.08-5 generic Apache request library ii libaprutil1 1.2.12+dfsg-2 The Apache Portable Runtime Utility Library Colin
Re: troubleshooting
Colin Wetherbee wrote: Beginner wrote: dpkg -l libapache2-mod-perl2 shows: ii libapache2-mod-perl2 2.0.2-2.4 It doesn't mention etch but I think this is the correct version. FYI, here are the versions I get for Debian testing (I believe that's etch at the moment?). I'm making lots of noise here... my apologies. Debian stable is currently etch, testing is lenny, and unstable is sid. So, my package list was for lenny, not etch. http://www.debian.org/releases/ That said, if you're not using this server for production or mission-critical stuff, lenny might be a good direction to go. :) Colin
Re: Custom Object-Oriented Module using HTML::Template
Roberto � wrote: On Wed, Mar 12, 2008 at 11:02:27PM +, xyon wrote: Hey everyone, Firstly, I apologize I sent the previous email under an incorrect subject line. Yes, but you still hijacked another thread. = In-Reply-To: [EMAIL PROTECTED] Please don't do that. Start a new thread by sending a new message to the list. Don't just repky some random message and change the subject line. At least give him credit for showing plenty of diagnostic information. That's something we rarely see with newbies. :) Colin
Re: return DECLINED or OK?
Ronald Dai. wrote: I learned what is RTFM here which is very interesting :)...I like the Ubuntu Forums policy though...but I always think reading is helpful to any developer...that's why I like both perl and java because I think they are very well documented generously somewhere within my reach on the net Learning how to effectively RTFM is an essential skill for anyone, in any walk of life, in any industry. IMHO, the Ubuntu policy is too fluffy. People will never learn to think for themselves if their hands are held all the time. Then again, that's sort of Ubuntu's market these days, I guess. I've been telling people to RTFM for a long time, and I've never known anyone to become a worse developer or user for it. Colin
Re: return DECLINED or OK?
Ronald Dai. wrote: Actually RTFM would not be a problem for people from academic background (meaning MS or PHD educated) at all since they have to do it all the timebut for people with more team work background these days, it might not be politically very correct... I disagree. Granted, I have a master's degree. But, let's say, as very nearly happened on another mailing list yesterday, someone installs database software and can't figure out how to create a database. I say go look at the manual and here's the specific URL that covers creating new databases. Now, that person knows where to look for information about creating a database, *and* that person also knows where to look for answers to future simple questions. If I had only told that person to type createdb your_database_name, the manual never would have been involved, and that person would have emailed the list again for the next basic question that could have been answered by the manual. I didn't say RTFM in so many words (or letters), but the point was to give the user some reference material. Which, so far, seems to have worked. Colin
Executing CGI programs from within mod_perl
Greetings. I use a program called MapServer to generate images. It's a C binary, and most people seem to run it (essentially) directly as a CGI program. By essentially, I mean the binary is typically requested by JavaScript or Flash or other things like that. I'm doing some dynamic mapping that requires additional CGI variables, though, and I'd like to process and sanitize those from within an existing mod_perl application I have. I wrote a post [0] about this to the MapServer list last night, but nobody has responded, so I figured I'd try over here to see if any of you have some insight as to the problem. Basically, I'd like to run the 'mapserv' binary from within mod_perl, but it requires a CGI environment to be setup for it. Apparently, my environment is missing something it requires. The environment from %ENV is listed in the post to the MapServer list. I seem to remember something about backticks doing some localized environment things, but I couldn't really find anything on it in the archives. Is this something I can do from within mod_perl? Thanks. Colin [0] http://lists.osgeo.org/pipermail/mapserver-users/2008-February/054531.html
Re: Executing CGI programs from within mod_perl
Michael Peters wrote: Colin Wetherbee wrote: Basically, I'd like to run the 'mapserv' binary from within mod_perl Why? Don't you just want to sanitize the data? If so you can do that in a FixUpHandler or even in a separate handler that does an internal_redirect to the mapserv's url. I also want to do cookie processing. And, I think this is going to get more complicated down the road, so I'd like to leave my options open. Colin
Re: apache process size
John ORourke wrote: Might be showing off my lack of unix admin knowledge here but using 'top', it's the value of the 'virt' column - ie. the biggest possible process size if the whole thing was resident. I've been using it to work out how many clients I should limit apache to, but looking at it the 'res' figure never seems to get anywhere near the 'virt' figure. Time to rewrite my assumptions I think! I get about 90 MB virt (70 MB res) per process, running some pretty heavy custom mod_perl templating software with some AJAX stuff that uses (gasp) Python as a back-end via mod_python, along with DBI (DBD::Pg). Sometimes, the load average hits 6.0, but everything always seems to load quickly enough. :) Linux 2.6.17.13, Debian, 2 x Pentium IV 3.0 GHz. Colin
Re: mod_perl / Perl5.10 / Win32 ?
Dami Laurent (PJ) wrote: I don't know where to find answers to the following questions, so better ask the list : - 1) is modperl2 currently compatible with Perl 5.10 ? If not, are some people working on it ? For which target date ? - 2) if the answer is YES, then did anybody compile it into a PPM for Win32 ? Didn't find it at ActiveState nor at uwinnipeg. I believe the following message from this month's archives is still applicable. http://mail-archives.apache.org/mod_mbox/perl-modperl/200802.mbox/[EMAIL PROTECTED] Colin
Re: Problem running Perl scripts with mod_perl from Alias directory
Billeb, Andrew (ATS, IT) wrote: The result is that when I click on a URL like the following (i.e. missing the the /cgi-bin/): _http://localhost/ridhwan/script_name.pl_ the script displays fine….but clicking the submit button doesn't do anythingit just redisplays the same page. But it's the *same script* as in the first link. It's just being accessed through the alias. So, I don't understand why it doesn't work. Could you be more specific here? For example, doesn't do anything and redisplays the same page are contradictory statements. What exactly happens? Colin
Re: mod_perl's make test fails.
Zakk wrote: For the last few days, I've been trying to install mod_perl for my server. It's running Slackware 12.0 with Apache 2.2.8 (with APR 1.2.12) and Perl 5.10.0. I'm under the impression we're still under the don't use Perl 5.10 with mod_perl yet directive. A number of internal changes in Perl 5.10, which was released in December, caused some instability in mod_perl. Colin
Re: mod_perl's make test fails.
Zakk wrote: Date: Fri, 1 Feb 2008 22:21:12 -0500 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: modperl@perl.apache.org Subject: Re: mod_perl's make test fails. Zakk wrote: For the last few days, I've been trying to install mod_perl for my server. It's running Slackware 12.0 with Apache 2.2.8 (with APR 1.2.12) and Perl 5.10.0. I'm under the impression we're still under the don't use Perl 5.10 with mod_perl yet directive. A number of internal changes in Perl 5.10, which was released in December, caused some instability in mod_perl. Colin Okay, I wasn't aware of that. It wasn't mentioned anywhere on the site. So would downgrading Perl to 5.8.8 (using mod_perl 2.0.3) would work, right? Definitely. That's the best way to go for now. Colin
Re: Printing for debugging
Raful Mr Mitchell H wrote:
I have my code pasted below. My module, loaded with Location
directive in Apache2, works well. However, sometimes switches don't
respond correctly to bulk queries of fdbPorts object. What I want to do
is to be able print the value of my variables either to the browser or a
log file. A regular print statement does not work for this. The
relevant variables are in a subroutine called from my sub handler.
I'm not entirely sure where, in those lines of unindented HTML, you're
trying to perform your logging. The only thing I could find quickly was
the following code, but I can't be certain that's the subject of your
question.
if( $arp_session-{ErrorNum} ){ print Got $arp_session-{ErrorStr} for
$router\n; }
In order to print log messages to Apache's (or your virtual host's)
error log, you can use the following.
use Apache2::RequestUtil;
use Apache2::Log;
Apache2::RequestUtil-request-log-error('some_text');
Substituting other log levels (debug, info, warn, etc.) works, as well.
See the following URL for more information.
http://perl.apache.org/docs/2.0/api/Apache2/Log.html#LogLevel_Methods
If this isn't what you're seeking, perhaps you could include a more
concise test case and a more elaborate explanation in your next post?
Colin
Re: Refreshing stored data at administrator's signal
Scott Gifford wrote: Colin Wetherbee [EMAIL PROTECTED] writes: [...] At the moment (and not in a production environment), every time the drop-down list is generated for a web page, the script queries the database to retrieve the entire list of aircraft. I would prefer to retrieve the list of aircraft when each Perl interpreter starts and then not retrieve it again until the administrator sends a signal. For this particular table, the signal would only occur when new aircraft hit the market, like the Boeing 787 will (hopefully) in December of this year. Essentially what you want is an in-memory cache of a possibly slow database query. There are several modules on CPAN that do this; search for cache. I'm not sure what you're suggesting. The first few pages of cache on CPAN have some modules for caching data in memory and on disk and so forth, but I don't see how they relate to my problem. Which is that of notifying all of my application's perl processes when an update has been performed on a table in a database, without having them access the database to determine this on their own. Thanks. Colin
Re: Refreshing stored data at administrator's signal
Clinton Gormley wrote: I'm not sure what you're suggesting. The first few pages of cache on CPAN have some modules for caching data in memory and on disk and so forth, but I don't see how they relate to my problem. Which is that of notifying all of my application's perl processes when an update has been performed on a table in a database, without having them access the database to determine this on their own. My personal favourite is Cache::Memcached, but that's only relevant if you have more than one web server. If not, the file based caches are the fastest (or you could try looking at SQLite or Cache::BerkleyDB or even a memory table in MySQL, but on a different DB server) Memcached sounds like a good idea. I could cache the update timestamps and compare them on each run. I guess I wasn't thinking about cache the right way around. Thanks! Colin
Refreshing stored data at administrator's signal
Greetings. I have an application that accesses some relatively static database tables to create drop-down select lists. As an example, one of these tables is a list of common commercial aircraft. At the moment (and not in a production environment), every time the drop-down list is generated for a web page, the script queries the database to retrieve the entire list of aircraft. I would prefer to retrieve the list of aircraft when each Perl interpreter starts and then not retrieve it again until the administrator sends a signal. For this particular table, the signal would only occur when new aircraft hit the market, like the Boeing 787 will (hopefully) in December of this year. The most UNIX-ish way to do this, I guess, would be to send SIGHUP to each running perl process, causing it to reload its configuration, update its stored lists, and so forth. I'd rather do this in a more Perl-ish or Apache-ish way, though, and I'd also rather be specific about which list it should update. At the moment, there are about 10 such lists, and I can see that number growing to about 20 before the site goes live. At a guess, the lists average about 300 elements each (with the list of aircraft being one of the shorter and less-frequently-updated lists). My ideal solution would be to have an external application (the administrator app or whatever it ends up being) update some flag inside each mod_perl process every time they need to update a list, and then each mod_perl application would see the flag and perform the update. I could do this relatively easily with a combination of threads and file hooks or update sockets or something, but I don't plan on adding threads or sockets to the application, and I think adding that much complexity and overhead for this simple feature would be overkill. Any thoughts? Thanks. Colin
Re: Refreshing stored data at administrator's signal
John ORourke wrote: Colin Wetherbee wrote: At the moment (and not in a production environment), every time the drop-down list is generated for a web page, the script queries the database to retrieve the entire list of aircraft. I would prefer to retrieve the list of aircraft when each Perl interpreter starts and then not retrieve it again until the administrator sends a signal. For this particular table, the signal would only occur when new aircraft hit the market, like the Boeing 787 will (hopefully) in December of this year. The most UNIX-ish way to do this, I guess, would be to send SIGHUP to each running perl process, causing it to reload its configuration, update its stored lists, and so forth. I'd rather do this in a more Perl-ish or Apache-ish way, though, and I'd also rather be specific about which list it should update. Wouldn't a simpler approach be to just restart Apache when you want to update the lists? You could even have the 'add to list' function send SIGUSR1 to the parent Apache, causing a graceful restart. I'm trying to avoid restarting Apache altogether, although I admit it would be a pretty simple solution. Having said that, if running 20 DB queries returning a few hundred records is causing you a speed problem, are you sure the DB is running efficiently? Is this a very high traffic site? Is there a requirement for ultra-fast page generation? I've got pages that make dozens and dozens of DB queries returning hundreds of records and do lots of post-processing, and I can generate pages in under a second much of the time. The point is more like well, this isn't really super-dynamic data, so running a query every time I need it seems like a waste of processor time and disk activity. It's not causing any slow-down right now, though when the site goes live, it certainly could. Colin
Re: MinQueueAge
Tyler Bird wrote: Hi folks I know this is off topic and hopefully if anybody knows the sendmail mailing list address please reply. Yeah, that's pretty off-topic. http://www.sendmail.org/misc/usenet.php http://groups.google.com/group/comp.mail.sendmail/topics Colin
Re: restrict virtual hosts programs
Jeff Pang wrote: I met a strange requirement that, given Apache has two virtual hosts, vhA and vhB, vhA's document root is: /path/a/; vhB's document root is: /path/b/. vhA's programs are running under /path/a/cgi-bin, but actually, the programs of vhA can access vhB's directory (ie,they can open and write some files in /path/b/). vice versa, the programs of vhB can access vhA's directory. This is because all virtual hosts are owned by Apache,if apache is run with nobody user and apache needs to write to some dirs,those dirs must be writable to nobody. That's to say, vhA can write to vhB's dirs,since they are all run with nobody user. How to resolve it with modperl? is it possible? thanks! How about suexec? I used it quite some time ago, and it was awful to use, but it got the job done. http://httpd.apache.org/docs/2.2/mod/mod_suexec.html http://httpd.apache.org/docs/2.2/programs/suexec.html Colin
Re: Un-baking a baked cookie
Peter Haworth wrote: On Sat, 05 Jan 2008 00:56:49 -0500, Colin Wetherbee wrote: On Jan 4, 2008 9:47 PM, Colin Wetherbee [EMAIL PROTECTED] wrote: From the Apache2::Cookie documentation, bake() adds a Set- Cookie header to the outgoing headers table. Is there a way to undo this without manually editing the headers, preferably with Apache2::Cookie methods? I'm trying to work out a way to not have to rely on undoing cookies, but I haven't had any luck so far. It's for a complicated authentication system. Then don't bake them until you're ready to send them. I have a similar situation in which my session information might change during the course of the request, but each step wants to make sure that if it's the last one, those changes get into the cookie. Instead of baking when setting the cookie value, I just stuff it into a hash based on the cookie name (which lets me handle multiple cookies this way should the need arise). My application has a method which calls Apache's send_http_header() method, amongst other things, so I just bake all the saved cookies in this method before calling send_http_header(). I've used your suggestion, along with Hash::Merge, to solve my problem. Thanks! Colin
Re: Un-baking a baked cookie
Perrin Harkins wrote: On Jan 5, 2008 12:56 AM, Colin Wetherbee [EMAIL PROTECTED] wrote: Well, I don't mind editing the headers, but I'd rather use standardized API calls (i.e. through Apache2::Cookie and friends) so that I don't have to worry about what's going on under the hood, updating my code for Apache2 changes, and so forth. Cookies are pretty simple. The main reason to use a library is just to get the formatting right. The actual header manipulation is not likely to change, so I think you're not taking much of a risk by doing it directly. I'll keep that in mind. Thanks again. Colin
Un-baking a baked cookie
Good evening. Is it possible to un-bake a baked cookie? From the Apache2::Cookie documentation, bake() adds a Set-Cookie header to the outgoing headers table. Is there a way to undo this without manually editing the headers, preferably with Apache2::Cookie methods? (As an aside, would somebody mind briefly explaining the difference between the Set-Cookie and Set-Cookie2 headers? Is Set-Cookie2 preferred now? Can it be implemented by just changing instances of bake() to bake2()?) Thanks. Colin
Re: Un-baking a baked cookie
Perrin Harkins wrote: On Jan 4, 2008 9:47 PM, Colin Wetherbee [EMAIL PROTECTED] wrote: From the Apache2::Cookie documentation, bake() adds a Set-Cookie header to the outgoing headers table. Is there a way to undo this without manually editing the headers, preferably with Apache2::Cookie methods? Why don't you want to edit the headers? That seems like the simplest way to do it. Hi, Perrin. Thanks for your response. Well, I don't mind editing the headers, but I'd rather use standardized API calls (i.e. through Apache2::Cookie and friends) so that I don't have to worry about what's going on under the hood, updating my code for Apache2 changes, and so forth. I'm trying to work out a way to not have to rely on undoing cookies, but I haven't had any luck so far. It's for a complicated authentication system. (As an aside, would somebody mind briefly explaining the difference between the Set-Cookie and Set-Cookie2 headers? I had never heard of Set-Cookie2, but a quick Google makes it sound like an RFC that never caught on. I'm of the same opinion. FWIW, the Apache2::Cookie module seems to support it [0]. Colin [0] http://tinyurl.com/2ubw2m
Re: segfault
Raful Mr Mitchell H wrote:
My script looks like this
use Apache2::Request ();
my $req = Apache2::Request- new($r)
my $data = req-{/param-name}/
//
It causes a segfault error. Any ideas?
Hello.
Please send us a bit more of your script. This snippet doesn't say much.
Colin
Re: segfault
Raful Mr Mitchell H wrote:
Here is the complete script
Is this the script that was causing segfaults? It doesn't look anything
like what you originally posted.
#!/usr/bin/perl
package Handlers::Devices;
use DBI;
use HTML::Template;
use Apache2::RequestRec ();
use APR::Request::Param ();
use Apache2::Const -compile = 'OK';
sub handler {
my $r = shift;
my $req = $r-param(chosen_base);
We usually reserve $req for an Apache2::Request object, instantiated as
follows.
my $req = Apache2::Request-new($r);
Then, $req provides CGI parameters...
my $username = $req-param('username');
[snipped the rest]
Does that help?
Colin
Re: Find the values of Apache2::Const
Boysenberry Payne wrote: I found that $r-status() required something other than Apache2::Const in one of my modules and it got me wondering what the Constant values actually were. Now I could go through and print each one I suppose, but I thought looking at them in Apache2::Const.pm would be better, but the package seems to be mostly pod notation. How can I look up the constants, i.e. where are they? This isn't exactly a list of them, but it might point you in the right direction. They're buried pretty well, it seems. http://stuff.mit.edu/afs/sipb/service/httpd/src/mod_perl-2.0.1/src/modules/perl/modperl_constants.c (Also http://tinyurl.com/32y54e) Colin
Re: Find the values of Apache2::Const
Boysenberry Payne wrote: I only ask because I tried a $r-status(Apache2::Const::OK) and got a 500 returned in the header even though my handler returned with Apache::Const::OK also... To avoid the 500 header I had to do $r-status(200); I imagine the status code isn't going to change too soon, so I ought to be okay, right? The HTTP/1.1 status codes are defined in RFC 2616 [0], section 6.1.1. I doubt they will change any time soon, so it should be fine to use the numbers. However, if your constants aren't working like they should, it's probably worth figuring out why. I always include my constants with the following line. Deviating from this specific syntax always seems to break stuff for me. use Apache2::Const -compile = qw(:common); Colin [0] http://www.faqs.org/rfcs/rfc2616.html
Re: Find the values of Apache2::Const
Adam Prime wrote: Boysenberry Payne wrote: I only ask because I tried a $r-status(Apache2::Const::OK) and got a 500 returned in the header even though my handler returned with Apache::Const::OK also... To avoid the 500 header I had to do $r-status(200); I imagine the status code isn't going to change too soon, so I ought to be okay, right? I believe in this situation what you want is $r-status(Apache::Const::HTTP_OK). HTTP_OK and OK are not the same thing at all. Good point. I guess I wasn't reading the original post clearly enough. That would certainly make a difference. Colin
Perl 5.10
Have any of you used mod_perl with Perl 5.10 yet? Are there any gotchas to consider? I'm still waiting on the release of the Debian packages. Colin
Re: Can output filter return page not found?
Marc M. Adkins wrote: Can I not return Apache2::Const::NOT_FOUND from handler()? I've never used filters for this, but you can certainly return NOT_FOUND from a handler. Colin
No log() in Apache2::RequestRec?
Based on some documentation I read [0] [1], I am trying to use the
following function to write messages to my virtual host's error log.
30 sub Debug(@)
31 {
32 my $r = Apache2::RequestUtil-request;
33 $r-log-debug(@_);
34 }
I have tried several variations of this, restarting the server as
necessary, and I get the following error.
[Fri Dec 14 23:57:52 2007] [error] [client 192.168.171.80] Can't locate
object method log via package Apache2::RequestRec at
/home/cww/sites/js.iron.denterprises.org/htdocs/jet-set/JetSet/Debug.pm
line 33.\n
I remember using code similar to this for logging in the past, and it
worked fine. Unfortunately, I don't have (or can't find) that code anymore.
This is Apache/2.2.6 (Debian) mod_apreq2-20051231/2.6.0 mod_perl/2.0.3
Perl/v5.8.8.
I would appreciate any pointers.
Thanks.
Colin
[0] http://perl.apache.org/docs/2.0/api/Apache2/RequestUtil.html#C_request_
[1] http://perl.apache.org/docs/2.0/api/Apache2/Log.html#LogLevel_Methods
Re: No log() in Apache2::RequestRec?
Fred Moyer wrote: Colin Wetherbee wrote: [Fri Dec 14 23:57:52 2007] [error] [client 192.168.171.80] Can't locate object method log via package Apache2::RequestRec at /home/cww/sites/js.iron.denterprises.org/htdocs/jet-set/JetSet/Debug.pm line 33.\n use Apache2::Log (); should take care of it. Well, that was easy enough. Thanks. Colin
Re: modperl on Win32 is still happening
Foo JH wrote: 3. Fast to cook, good to eat That's my favorite part of mod_perl. It goes down well with cookies, too, but tastes awful with Java. ;) And, you know, to keep this on topic, I like the idea that mod_perl on Windows can be a springboard of sorts for people who may eventually be driven to use mod_perl on other platforms. Supporting Windows with technologies like mod_perl seems like a kind of viral evangelism, and as long as mod_perl continues to work well on Windows, Windows-centric people will continue to be interested in mod_perl. Colin
Re: Using dtrace to determine which modules aren't loaded at startup time
Fred Moyer wrote: I've been having fun with dtrace, and I most recently used it to see what files are being accessed by mod_perl during requests. I've preloaded all the modules in my application that I know about into startup.pl, but when I startup my httpd server and make a request, I got some unexpected results. I abhor sounding ignorant, but I wonder if Linux analogues to dtrace and rwsnoop exist? The results of your fun are very interesting, and I am curious to investigate my own processes. Thank you. Colin
Unqualified segmentation fault from Apache2::Request-new()
Greetings.
I accidentally made the mistake of calling Apache2::Request-new()
without passing $r, and it turns out that causes Apache to segfault and
not return anything to the browser. I'm only pointing this out because
it seems like there should be a more graceful way of handling this.
### Code
package Test::Handler;
use Apache2::RequestRec;
use Apache2::Const -compile = qw(OK);
sub handler
{
my ($r) = @_;
my $req = Apache2::Request-new();
return Apache2::Const::OK;
}
1;
### End Code
### Log (LogLevel debug)
[Thu Dec 06 02:16:46 2007] [notice] Apache/2.2.3 (Debian)
mod_apreq2-20051231/2.6.0 mod_perl/2.0.3 Perl/v5.8.8 configured --
resuming normal operations
[Thu Dec 06 02:16:46 2007] [info] Server built: Dec 2 2007 18:11:50
[Thu Dec 06 02:16:46 2007] [debug] prefork.c(993): AcceptMutex: sysvsem
(default: sysvsem)
[Thu Dec 06 02:16:51 2007] [notice] child pid 22461 exit signal
Segmentation fault (11)
### End Log
Colin
Re: Unqualified segmentation fault from Apache2::Request-new()
Colin Wetherbee wrote: use Apache2::RequestRec; use Apache2::Const -compile = qw(OK); To be clear, this also occurs with 'use Apache2::Request' at the top. :) Colin
Re: Connection Pooling
Mag Gam wrote: Is it possible to do database connection pooling with mod_perl? Currently, all of my source code has a my $dbh. Is it possible to have my database stuff in a pool, and I just include it somehow? DBI::Pool is a partially complete module for doing this. Tim Bunce and Stas Bekman (I think?) have been working on it, on and off [1]. From Tim's DBI road map [2]: Connection pooling in a threaded application, such as mod_perl, is difficult because DBI handles cannot be passed between threads. An alternative mechanism for passing connections between threads has been defined, and an experimental connection pool module implemented using it, but development has stalled. If anyone has any more recent information on DBI::Pool or related efforts, I'd be interested in it, too. Colin [1] http://www.nntp.perl.org/group/perl.dbi.dev/2007/04/msg4952.html [2] http://search.cpan.org/~timb/DBI/Roadmap.pod
Re: Connection Pooling
Perrin Harkins wrote: If you have a reverse proxy, and still have too many connections, you can look at either SQL Relay or the DBI::Gofer stuff in the latest DBI releases. DBI::Gofer was created to solve the issue of too many connections for Shopzilla.com. DBD::Gofer looks like an excellent solution for this problem. I have been putting off some development because I didn't want to write my own pooling server. Thanks for the suggestion. Colin
Re: Internal Server Error
Jeff Pang wrote:
Try change the codes to:
sub handler {
my $r = shift;
...
If his handler is called as a method, $class is an appropriate first
variable to shift out of @_. Using ($class, $r) = @_ is a perfectly
legitimate way of taking care of that.
Colin
Re: Can't install mod_perl
Raymond Wan wrote: I'm not an expert on this, but looked into this briefly as I was worried about the level of support. From asking around, it seems that you can install 32-bit Linux on a 64-bit machine, but of course, you lose all the benefits of the 64 bits (access to larger disks and more memory per process). As an example, when I purchased my 64-bit machine, I was given the option to have Windows XP 32-bit or Windows XP 64-bit pre-installed for me. So yes, I guess a 32-bit OS can be installed. This is getting off-topic, but to put this issue to rest, I can confirm that both 32-bit Debian and 32-bit Windows XP run on 64-bit AMD processors. In the end, though, it's a bit silly to run a 32-bit OS on a 64-bit processor, since you're wasting all that extra, fancy 64-bit stuff. Colin
[mp2] Apache2::Reload doesn't reload
It seems like I've tried everything, and I can't get Apache2::Reload to
reload my modules.
I have a handler in a module called JetSet::Handler. That module
depends on a number of other modules, which I've tried to include with
'use', with limited success. It seems, sometimes, symbols act just fine
and reload when they should, but other times, I have to restart Apache
in order to get the symbols to reload.
I have run the Reload debugger, and it says everything is reloading just
like it should. But, I believe my problem is described in the
Apache2::Reload documentation; Apache keeps the old function pointer
around from the first 'use', even though the changed function now has a
new pointer.
The Apache2::Reload documentation also says Registry (which I'm not
actually explicitly using) doesn't play nicely with Exporter when 'use'
is used, so I tried the 'require';'import()' method described in the
documentation. With this, I'm unable to import my symbols. For example:
# In Handler.pm:
require JetSet::Debug; JetSet::Debug-import();
# ...
JetSet::Debug::DebugLevel(JetSet::Debug::DEBUG_WARN);
# End
Where DEBUG_WARN is declared either by sub DEBUG_WARN() { 3 }; or with
'use constant' in Debug.pm. It is then exported in @EXPORT or
@EXPORT_OK. Any combination of these things gives the following error.
# From error_log:
failed to resolve handler `JetSet::Handler': Bareword
JetSet::Debug::DEBUG_WARN not allowed while strict subs in use at
/home/cww/sites/rain/htdocs/jet-set/JetSet/Handler.pm line 19.
# End
I read in the list archives that doing away with Exporter altogether
might be the preferred way of dealing with this. Implementing my
modules as objects instead of exporting functions, it seems, might
eliminate the not-exporting errors and make Reload work correctly:
http://www.gossamer-threads.com/lists/modperl/modperl/82283#82283
I'm not opposed to doing that, but in that case, how does one deal with
things like constants? Perhaps I would just have to keep all my
constants in a single Exporter-style file and then restart Apache every
time I change it? Frankly, that sounds like a pretty lousy way to have
to deal with this.
Here are some snippets that might help with the diagnosis.
# From my virtual host configuration:
PerlRequire /home/cww/sites/rain/htdocs/perl-static/startup.pl
PerlModule Apache2::Reload
PerlInitHandler Apache2::Reload
PerlSetVar ReloadDirectories /home/cww/sites/rain/htdocs
Location /jet-set
SetHandler perl-script
PerlResponseHandler JetSet::Handler
/Location
# End
# startup.pl:
use lib qw(/home/cww/sites/rain/htdocs/jet-set);
1;
# End
# Apache2 version string:
Apache/2.2.3 (Debian) mod_ssl/2.2.3 OpenSSL/0.9.8e
mod_apreq2-20051231/2.6.0 mod_perl/2.0.2 Perl/v5.8.8 Server at rain Port 80
# End
Thank you for your assistance.
Colin
Re: [mp2] Apache2::Reload doesn't reload
Jonathan Vanasco wrote:
sub handler {
$page= myapp::Page-new();
$page-whatever;
}
So, Page.pm defines an object... do you have Page.pm including other
Exporter-style modules? And, do those work properly?
Thanks.
Colin
Re: [mp2] The right way to use CGI parameters in a handler
Jonathan Vanasco wrote:
As I said in my original post, I tried to use Apache2::Request, but
after creating that object, I couldn't print anything anymore.
Perhaps someone could give me a hint on how to implement it?
could you print beforehand?
'print' might not be tied to the same output.
Printing beforehand wouldn't allow me to use the CGI parameters to
determine the output. :)
this might not be right based on your compile.
print 'foo: ' . $cgi-param('foo') . br /\n;
try:
$r-print( 'foo: ' . $cgi-param('foo') . br /\n );
No dice.
# BEGIN CODE BLOCK
my $req = Apache2::Request-new($r);
$r-content_type('text/html');
$r-print(testbr /\n);
# END CODE BLOCK
The content-type doesn't even show up in this case.
If I put the $r-content_type() and $r-print() before the $req object
is created, *still* nothing shows up.
Colin
Re: [mp2] The right way to use CGI parameters in a handler
Colin Wetherbee wrote:
# BEGIN CODE BLOCK
my $req = Apache2::Request-new($r);
$r-content_type('text/html');
$r-print(testbr /\n);
# END CODE BLOCK
OK, problem solved.
I didn't have mod_apreq enabled. For what it's worth, I don't recall
seeing anything about enabling mod_apreq in the documentation; it just
said enable mod_perl, and showers of gold will fall from the sky or
something. :P
Thanks for your help, everyone.
Colin
[mp2] The right way to use CGI parameters in a handler
Hello!
It's been about four years since I've used mod_perl to any great extent,
and I'm afraid I'm somewhat rusty. I'm trying to create a handler that
can parse CGI parameters, but I'm unsure of the most modern way of doing
that.
I know Apache2::Request is supposed to be able to grab CGI parameters;
is that better than using CGI.pm? How about these APR modules that
seem to wind their way into the framework?
When I tried creating an Apache2::Request-new($r) object to use to get
CGI parameters, I found that everything I tried to print after the
object's instantiation wouldn't show up anywhere. All the pages served
were zero bytes, and I couldn't even print to STDERR.
Here's a simple handler I wrote. It works, but I'm afraid I might be
doing something incorrectly by mixing Apache2 and CGI. I'm wondering
how it would look if someone who was more up-to-date on mod_perl wrote
it? :)
# BEGIN CODE BLOCK
use Apache2::Const -compile = qw(OK);
use CGI;
sub handler
{
my ($r) = @_;
my $cgi = CGI-new($r);
$r-content_type('text/html');
if (defined $cgi-param('foo'))
{
print 'foo: ' . $cgi-param('foo') . br /\n;
}
return Apache2::Const::OK;
}
# END CODE BLOCK
Thanks. :)
Colin
[mp2] PerlSwitches -I not working?
Greetings. Following reading Stas's last email to Scot, I poked around on the configuration directives page and saw that PerlSwitches -I/foo is a convenient replacement for 'use lib'. I removed 'use lib' from a script and put the following in my virtual host section: PerlSwitches -I/var/www/hydrogen.denterprises.org/exec/perl This doesn't appear to end up in @INC because I get the following in my error log (which shows that /var/www/... is not in @INC): [Fri Oct 15 21:23:33 2004] [error] 20945: ModPerl::Registry: Can't locate Hydrogen/Const.pm in @INC (@INC contains: /usr/lib/perl5/Apache2 /etc/perl /usr/local/lib/perl/5.8.4 /usr/local/share/perl/5.8.4 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl . /etc/apache2/ /etc/apache2/lib/perl) at /var/www/suexec/hydrogen.denterprises.org/hydrogen.pl line 21.\nBEGIN failed--compilation aborted at /var/www/suexec/hydrogen.denterprises.org/hydrogen.pl line 21.\n Is PerlSwitches functionality still experimental? Colin -- Colin W. Wetherbee http://hydrogen.denterprises.org/ -- 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: Whats wrong in HTML::TableExtract with modperl
Siyad Ahmed Naina said: ModPerl::Registry: HTML::Parser object version 3.35 does not match bootstrap parameter 3.34 at This is a module version mismatch. Perhaps you have an old (but still recent, from the looks of it) version of mod_perl in your path somewhere? My suggestion is to upgrade all relevant software to the latest versions. Colin -- Colin W. Wetherbee http://hydrogen.denterprises.org/ -- 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
[mp2] HTTP status code w/ ModPerl::Registry
Greetings. Seems I'm confused about how to get mod_perl to send status codes other than 200 OK. I want to have my Perl script, upon getting the wrong CGI parameters, to give a status 404. Then, the ErrorDocument for 404 goes back to that same Perl script but with the CGI parameter ?page=error404. ErrorDocument is currently set up like so: ErrorDocument 404 /exec/hydrogen.pl?page=error404 This works fine when I'm not having the script generate the 404 error. For example, if I visit http://foo/this_page_does_not_exist, then I get the ?page=error404 error page. Beautiful. However, if I access hydrogen.pl?page=this_page_does_not_exist, it needs to output a 404 status and get on with it. Presently, I just get a blank page or IE tells me there is no page. I'm using ModPerl::Registry, so I can't just return Apache::NOT_FOUND, which is how I'm apparently supposed to do it, according to what little documentation I could find. At the moment, when the Perl script is asked for a page it can't find, it does this: $r-status(Apache::NOT_FOUND); $r-print(); exit; I have no idea whether this is the right way to do it. The documentation on HTTP status codes under mod_perl 2 is quite sparse. Any thoughts? Thank you very much. Colin -- Colin W. Wetherbee http://hydrogen.denterprises.org/ -- 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
