Re: mod_perl vs. C for high performance Apache modules
> So I'm trying to show that mod_perl doesn't suck, and that it is, in fact, > a reasonable choice. Though within these limits it is still reasonable to > point out the development cycle, emotionally it is the least compelling > form of argument, because the investor has a hard time removing from > consideration that given our particular situation, there was a very fast > solution in using his C-based routines. Well, that is the primary reason for using Perl over C, and you really have to count maintenance and the relative likelihood of C-ish bugs like buffer overflows as part of it. Well-coded C should be faster than Perl, but Perl is fast enough for nearly any web-based application. If this guy saw CPU spikes, he probably had something else wrong, like running out of memory. You might find this article aboout C and Perl performance useful: http://www.perl.com/pub/a/2001/06/27/ctoperl.html - Perrin
Re: mod_perl vs. C for high performance Apache modules
"... years ago ..." Are you even sure he evaluated mod_perl and not Perl CGI scripts?? Launching the interpreter and compiling every time might spike the CPU. Like others have said, you would really have to benchmark the mod_perl and Apache that you're using now; both have improved considerably over the years. You can point to the success stories others have mentioned to show that it really is one of the standard industry solutions that works well in many high-traffic situations. He's clearly arguing from outdated data and emotion. Also, if you delivered what you said you would deliver, that ought to be the end of it. If the site is performing according to expectations and promises, then he doesn't have any real basis to complain. If it would truly deliver tangible advantages to the client to rewrite it in C, or incorporate some of his C code in your work (Perl and C can get along sometimes), then you might consider giving him a quote to rewrite it. Ask him to put up or shut up. A gentler approach might be, "Given we did what we did (and it works), what do you really want us to do now? What should happen from this point forward?" If there isn't a constructive answer to that, then all you're dealing with is a temper tantrum. ---Wes Sheldahl ( father of four young'uns ) Jeff Yoak <[EMAIL PROTECTED]> on 12/14/2001 03:58:51 PM To: Thomas Eibner <[EMAIL PROTECTED]> cc: [EMAIL PROTECTED] (bcc: Wesley Sheldahl/Lex/Lexmark) Subject: Re: mod_perl vs. C for high performance Apache modules [snip] So he's upset. Everyone acknowledges that given our particular circumstances, it would have been better to build upon what we already had, but because of his previous experience he feels that mod_perl wasn't even a responsible choice even within the limits of our lack of knowledge of his software and its availability. [snip] Cheers, Jeff
Re: mod_perl vs. C for high performance Apache modules
All, I wasn't sure what volume of response to expect when I originally wrote. Thank you all for the comments that you all are making. They are helping. Given that the response is fairly high, I'm waiting for stuff to roll in rather than replying to each of you. Don't think it is falling on unappreciating ears. :-) To respond to a few recurring comments / questions: Me? I've spent most of the last four years working on mod_perl-based stuff and most of the last eight working with Perl. Actually I've worked with folks who were involved with some of the projects you've mentioned, having been at idealab!, a parent of eToys and CitySearch. One of the original (THE original?) developer at CitySearch was probably the most helpful mentor / teacher I've ever worked with. I programmed in C a lot early in my career, but at this point I couldn't write anything substantial without brushing up, and frankly wouldn't care to. It just isn't as fun to work with C. But then, the argument, "But if you used C, you wouldn't get to work with ME!" may not convince some of these people with their values all screwed up... ;-) The project? What I consider to be standard web junk. About 30% ecommerce combined with lots of database-driven, interactive content, some authentication foo and things like that. The thing is that it is in the adult industry and the investor in question turns on the hose... well... there will be lots of traffic. Mistakes and misunderstandings? Sure. And yes, as some of you have pointed out publicly or privately, not my fault. I was kept very insulated from the people who were familiar with the alternatives. My involvement at this point is to try to smooth things over and keep the project functional. These immediate problems aside, the people involved are great to work with and if everyone feels better about the situation and things move forward in the best possible way from here, there will be a lot of valuable work for me. So I'm trying to help. More than you cared to hear about and terribly off-topic for the list? Sure. But you did sorta ask, and somehow it seemed rude to not reply. Forgive me and thanks for providing all of your commentary. Cheers, Jeff -- Jeff Yoak 626-705-6996
Re: mod_perl vs. C for high performance Apache modules
Dave Hodgkinson wrote on Fri, Dec 14 2001 (20:54:22 +): > "Perrin Harkins" <[EMAIL PROTECTED]> writes: > > According to something I once read by David Filo, Yahoo also had to tweak > > the FreeBSD code because they had trouble scaling *TCP/IP*! I would say > > their experience is not typical. > > Increasing the number of file handles, I'd wager. That was an issue on you really don't have to tweak any FreeBSD code for that, just do sysctl -w kern.maxfiles=10 and the file table will grow up to the new limit. > 2.x linux kernels too. that was an issue with 2.0.x, since 2.2.x you can do it with echo 10 > /proc/sys/fs/file-max cheers, -- Toni Andjelkovic <[EMAIL PROTECTED]>
Re: mod_perl vs. C for high performance Apache modules
Toni Andjelkovic <[EMAIL PROTECTED]> writes: > > 2.x linux kernels too. > > that was an issue with 2.0.x, since 2.2.x > you can do it with That was what I meant...decimal point in the wrong place... :-) -- David Hodgkinson, Wizard for Hirehttp://www.davehodgkinson.com Editor-in-chief, The Highway Star http://www.deep-purple.com Deep Purple Family Tree news http://www.slashrock.com Interim Technical Director, Web Architecture Consultant for hire
RE: mod_perl vs. C for high performance Apache modules
On Fri, 14 Dec 2001, Thomas Moore wrote: > I spoke to the technical lead at Yahoo who said mod_perl > will not scale as well as c++ when you get to their > level of traffic, but for a large ecommerce site > mod_perl is fine. the old "memory is cheap" rationalization doesn't go over very well at that scale either, eh.
Re: mod_perl vs. C for high performance Apache modules
-- Jeff Yoak <[EMAIL PROTECTED]> on 12/14/01 12:58:51 -0800 > This is something different. The investor is in a related business, and has > developed substantially similar software for years. And it is really good. > What's worse is that my normal, biggest argument isn't compelling in this > case, that by the time this would be done in C, I'd be doing contract work on > Mars. The investor claims to have evaluated Perl vs. C years ago, to have > witnessed that every single hit on the webserver under mod_perl causes a CPU > usage spike that isn't seen with C, and that under heavy load mod_perl > completely falls apart where C doesn't. (This code is, of course, LONG gone > so I can't evaluate it for whether the C was good and the Perl was screwy.) > At any rate, because of this, he's spent years having good stuff written in > C. Unbeknownst to either me or my client, both this software and its > developer were available to us, so in this case it would have been faster, > cheaper and honestly even better, by which I mean more fully-featured. Constructing the $r object in perl-space is an overhead that mod_perl causes. This overhead has been managed more effectively in recent versions of perl/mod_perl. A study done "a few years ago" probably involved machines with significantly less core and CPU horsepower than the average kiddie-games PC does today. Net result is that any overhead caused by mod_perl in the previous study may well have been either mitigated with better code or obviated by faster hardware [how's that for a sentence?]. Net result is that the objection is probably based on once- valid but now out of date analysis. -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582
Re: mod_perl vs. C for high performance Apache modules
>So I'm trying to show that mod_perl doesn't suck, and that it is, in >fact, a reasonable choice. I think one of the selling points for mod_perl is its extensibility: modules can be written in C. Depending on the C code you have access to, a good solution might be to try to wrap it into mod_perl modules. Tim
Re: mod_perl vs. C for high performance Apache modules
The original poster talked about C++ CGI programs. I have been using mod_perl since 0.7x days and I can tell you there is no way a fork+exec CGI program no matter what language its written in will come anywhere close to a perl handler written against the mod_perl Apache API in execution speed (when they are doing equivalnet types of work). Using C++ to build web applications is something developers who grew up in the heyday of client server would think is a good idea. In the internet web applications business by the time you get a C++ program debugged and ready to roll the market has evolved and your software is out of date. C++ is a good language for systems programming, databases, etc., but web apps need shorter life cycles. I had an investor question similar to the one we are talking about 3 years ago. I was questioned as to why we used Apache, mod_perl, and mysql instead of C++ and Oracle's DB and Web Devel kit. Needless to say our mod_perl systems have thrived while most of the investor's other investments have had their expensive hardware auctioned off on Ebay recently. The essence of mod_perl is that it allows to to take an idea and build a working prototype very quickly. When you prove that the prototype works you don't need to rewrite - mod_perl scales up better than any other web application technology available - period. -jon On Fri, 14 Dec 2001 [EMAIL PROTECTED] wrote: > > > -- Jeff Yoak <[EMAIL PROTECTED]> on 12/14/01 12:58:51 -0800 > > > This is something different. The investor is in a related business, and has > > developed substantially similar software for years. And it is really good. > > What's worse is that my normal, biggest argument isn't compelling in this > > case, that by the time this would be done in C, I'd be doing contract work on > > Mars. The investor claims to have evaluated Perl vs. C years ago, to have > > witnessed that every single hit on the webserver under mod_perl causes a CPU > > usage spike that isn't seen with C, and that under heavy load mod_perl > > completely falls apart where C doesn't. (This code is, of course, LONG gone > > so I can't evaluate it for whether the C was good and the Perl was screwy.) > > At any rate, because of this, he's spent years having good stuff written in > > C. Unbeknownst to either me or my client, both this software and its > > developer were available to us, so in this case it would have been faster, > > cheaper and honestly even better, by which I mean more fully-featured. > > Constructing the $r object in perl-space is an overhead > that mod_perl causes. This overhead has been managed more > effectively in recent versions of perl/mod_perl. A study > done "a few years ago" probably involved machines with > significantly less core and CPU horsepower than the average > kiddie-games PC does today. Net result is that any overhead > caused by mod_perl in the previous study may well have been > either mitigated with better code or obviated by faster > hardware [how's that for a sentence?]. > > Net result is that the objection is probably based on once- > valid but now out of date analysis. > > -- > Steven Lembark 2930 W. Palmer > Workhorse Computing Chicago, IL 60647 >+1 800 762 1582 > -- C. Jon Larsen Chief Technology Officer, Richweb.com (804.307.6939) SMTP: [EMAIL PROTECTED] (http://richweb.com/cjl_pgp_pub_key.txt) Richweb.com: Designing Open Source Internet Business Solutions since 1995 Building Safe, Secure, Reliable Cisco-Powered Networks since 1995
Re: mod_perl vs. C for high performance Apache modules
For some really high performance sites, compiled C is the way to go. It's faster and as long as you remove all compilers from the machines in question, it's also more secure. Having said that, I will also add that the downside is that in order to keep pace with your competitors who are writing code in Perl, PHP, and Python, it is going to cost you some serious dollars. You have to have deep pockets and in house coders to make it worth looking at, which normally limits this kind of thing to the Fortune 100. For the entire rest of the planet, perl is a perfectly good solution. IMHO, Jimi - Original Message - From: "Perrin Harkins" <[EMAIL PROTECTED]> To: "Thomas Eibner" <[EMAIL PROTECTED]>; "Jeff Yoak" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, December 14, 2001 3:32 PM Subject: Re: mod_perl vs. C for high performance Apache modules > > So I'm trying to show that mod_perl doesn't suck, and that it is, in fact, > > a reasonable choice. Though within these limits it is still reasonable to > > point out the development cycle, emotionally it is the least compelling > > form of argument, because the investor has a hard time removing from > > consideration that given our particular situation, there was a very fast > > solution in using his C-based routines. > > Well, that is the primary reason for using Perl over C, and you really have > to count maintenance and the relative likelihood of C-ish bugs like buffer > overflows as part of it. > > Well-coded C should be faster than Perl, but Perl is fast enough for nearly > any web-based application. If this guy saw CPU spikes, he probably had > something else wrong, like running out of memory. > > You might find this article aboout C and Perl performance useful: > http://www.perl.com/pub/a/2001/06/27/ctoperl.html > > - Perrin >
Re: mod_perl vs. C for high performance Apache modules
On Fri, 14 Dec 2001, Jeff Yoak wrote: > All, > > I wasn't sure what volume of response to expect when I originally > wrote. Thank you all for the comments that you all are making. They are > helping. Given that the response is fairly high, I'm waiting for stuff to > roll in rather than replying to each of you. Don't think it is falling on > unappreciating ears. :-) > To respond to a few recurring comments / questions: > > Me? I've spent most of the last four years working on mod_perl-based stuff > and most of the last eight working with Perl. Actually I've worked with > folks who were involved with some of the projects you've mentioned, having > been at idealab!, a parent of eToys and CitySearch. One of the original > (THE original?) developer at CitySearch was probably the most helpful > mentor / teacher I've ever worked with. I programmed in C a lot early in > my career, but at this point I couldn't write anything substantial without > brushing up, and frankly wouldn't care to. It just isn't as fun to work > with C. But then, the argument, "But if you used C, you wouldn't get to > work with ME!" may not convince some of these people with their values all > screwed up... ;-) Actually that would be my argument. When you're getting investors in, the primary thing they should be looking to buy into is the quality of the people there, not necessarily the code, because only one out of those two can be fixed easily (even in our current times, totally replacing a programming team is a difficult thing to do). I write C. I write Perl. And I combine them both to good effect. But, I wouldn't even consider writing anything but time critical routines in C - I do as much as possible in Perl for the following reasons: - It's fast enough. - It's safer. - It has a built in test harness (Test::Harness). - It's more fun. - It's faster to develop in. - It's OO, and that saves me time and effort. - It has an infinitely better community than C. The last point is probably my favourite, though probably means bugger all to an investor. -- <:->Get a smart net
Re: mod_perl vs. C for high performance Apache modules
While this advocacy thread is hot, please remember my request to send me your success stories so we have more material others can use to prove their point to their investors, bosses, girlfriends, moms :) I've received only three new stories since my request (I didn't put them online yet, they will go into the new site). If you do send them to me (or list), please use a plain text and follow this format: URL: Title: Contact Person: Traffic: (hits/day/month/whatever) Success Story: and anything else you wish to tell. Check if your story is already online and send an update if there is something to change. See http://perl.apache.org/stories/ and http://perl.apache.org/sites.html. Thanks! _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: mod_perl vs. C for high performance Apache modules
I know this sounds kind of simple minded but why not bench test the site, set everything up in the office get a good switch plug the site into 1 port and 5-10 client boxes with some load testing software and plug it in to the same switch and beat the crap out of it. After you do this for a while and find all the hot spots show it to the customer and go here it works. marc - Original Message - From: "Matt Sergeant" <[EMAIL PROTECTED]> To: "Jeff Yoak" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Saturday, December 15, 2001 3:24 AM Subject: Re: mod_perl vs. C for high performance Apache modules > On Fri, 14 Dec 2001, Jeff Yoak wrote: > > > All, > > > > I wasn't sure what volume of response to expect when I originally > > wrote. Thank you all for the comments that you all are making. They are > > helping. Given that the response is fairly high, I'm waiting for stuff to > > roll in rather than replying to each of you. Don't think it is falling on > > unappreciating ears. :-) > > To respond to a few recurring comments / questions: > > > > Me? I've spent most of the last four years working on mod_perl-based stuff > > and most of the last eight working with Perl. Actually I've worked with > > folks who were involved with some of the projects you've mentioned, having > > been at idealab!, a parent of eToys and CitySearch. One of the original > > (THE original?) developer at CitySearch was probably the most helpful > > mentor / teacher I've ever worked with. I programmed in C a lot early in > > my career, but at this point I couldn't write anything substantial without > > brushing up, and frankly wouldn't care to. It just isn't as fun to work > > with C. But then, the argument, "But if you used C, you wouldn't get to > > work with ME!" may not convince some of these people with their values all > > screwed up... ;-) > > Actually that would be my argument. When you're getting investors in, the > primary thing they should be looking to buy into is the quality of the > people there, not necessarily the code, because only one out of those two > can be fixed easily (even in our current times, totally replacing a > programming team is a difficult thing to do). > > I write C. I write Perl. And I combine them both to good effect. But, I > wouldn't even consider writing anything but time critical routines in C - > I do as much as possible in Perl for the following reasons: > > - It's fast enough. > - It's safer. > - It has a built in test harness (Test::Harness). > - It's more fun. > - It's faster to develop in. > - It's OO, and that saves me time and effort. > - It has an infinitely better community than C. > > The last point is probably my favourite, though probably means bugger all > to an investor. > > -- > > <:->Get a smart net >
RE: mod_perl vs. C for high performance Apache modules
On Fri, 2001-12-14 at 14:27, Thomas Moore wrote: > I spoke to the technical lead at Yahoo who said mod_perl will not scale as > well as c++ when you get to their level of traffic, but for a large Isn't that coming from a company using Python? I see that most of their URLs include a tell-tale ".py". Of course, whether that's really Python or not Matt
Re: mod_perl vs. C for high performance Apache modules
On Mon, Dec 17, 2001 at 10:32:58AM -0600, Matthew Kennedy wrote: > On Fri, 2001-12-14 at 14:27, Thomas Moore wrote: > > I spoke to the technical lead at Yahoo who said mod_perl will not scale as > > well as c++ when you get to their level of traffic, but for a large > > Isn't that coming from a company using Python? > > I see that most of their URLs include a tell-tale ".py". Of course, > whether that's really Python or not searching join.yahoo.com I notice 12 job descriptions contain the word perl, and only 2 that contain the word python.. FWIW, the only place I notice the .py extension is maps.yahoo.com. -- Paul Lindner [EMAIL PROTECTED]| | | | | | | | | | mod_perl Developer's Cookbook http://www.modperlcookbook.org Human Rights Declaration http://www.unhchr.ch/udhr/index.htm
Re: mod_perl vs. C for high performance Apache modules
... > work on Mars. The investor claims to have evaluated Perl vs. C years ago, > to have witnessed that every single hit on the webserver under mod_perl > causes a CPU usage spike that isn't seen with C, and that under heavy load ]- this seems to me like non-compiled script, module or eventually running under Apache::PerlRun :"))
Re: How to show mem usage of all modules?
Check Apache::Status, it gives you several info. On Tue, 2002-04-09 at 15:53, pawelp wrote: > Hi > Is there an easy way to show mem usage of all loaded modules ? > > Thanks > Pawel Piecuch > -- João Pedro Gonçalves 'I have never let my schooling interfere with my education.' - Mark Twain
[2.x] Windows interpreter-wide locking due to modules?
I have installed Randy Kobes' 5-10-2002 Apache-2/modperl-2 Win32 binaries on a Win2k Professional P3 uniprocessor development machine. I have left all of the startup.pl script as is. Everything works great--however, with some scripts I seem to still suffer from 1.3-style locks on the perl interpeter that prevent some other scripts from being served until a given dynamic request completes. I've poked around a bit and found that simple scripts (ones not using modules) will still be executed while another long-running process is executing (thus multithreading properly)--so I'm figuring it's probably a module issue (or I'm simply confused). The two modules I'm running predominantly are DBI 1.14 (with DBD::DB2 .74) and CGI 2.74, and I have verified that two scripts running simultaneously with these two modules will result in one blocking until the other completes. Any/all ideas most welcome--and my sincerest thanks to Randy for his 1.3 and 2.0 binaries and other incredibly helpful docs/builds/info/etc. James
Apache::DBI and CGI::Application with lots of modules.
Hi,
I am glad to see the list traffic has been picking up lately. It makes me
have higher hope about posting this.
First some background info.
I have a fairly large CGI::Application module about 30 run modes that pretty
much follows the example mailform module. I am also using HTML::Template
within the module. I am running on, FreeBSD 4.6 1G mem mysql 4.02 with
Innodb tables.
A typical run mode looks like this.
sub doug_holds {
my $self = shift;
my $q = $self->query();
my $holdtype = $q->param('holdstate');
my $holdsearch = new holds();
$holdsearch->HoldType($holdtype); # set hold type for the query
my $header = parse_header($self);
return $header . $holdsearch->getAllHolds();
}
Of course many of other subs look like this
sub customer_name_search {
my $self = shift;
my $index_page = $self->param('CUSTOMER_NAME_SEARCH_TMPL');
my $output='';
my $tmpl_obj = $self->load_tmpl($index_page,
die_on_bad_params => 0,
cache => 1,
stack_debug =>$debug
) or confess("could not create template");
$tmpl_obj->param(base => $self->param('base'));
$tmpl_obj->param(RUNMODE => 'customer_display');
$tmpl_obj->param(USER => $selected_user);
my $header = parse_header($self);
return $header . $tmpl_obj->output;
}
But that isn't relavent to my problem.
In the first sub, I create a new holds instance. Each of these modules like
holds work like this
package Holds;
use strict;
use Carp;
use warnings;
use QueryPrint;
use vars qw($dbh $processed_hnd $status_hnd);
use gentimeid; # generate time id based
sub new {
my $invocant = shift;
my $class = ref($invocant) || $invocant;
my $self = { @_ };
bless ($self, $class);
$dbh = db_connect();
#die "$self->{OrdNum}, $self->{HoldReason}";
return $self;
}
sub OrdNum {
my $self = shift;
if (@_) { $self->{OrdNum} = shift }
return $self->{OrdNum};
}
sub GetProcessed {
my $self = shift;
This has a bug, somtimes the cached query doesn't stick around.
$processed_hnd->execute($self->{OrdNum}) or confess ("can't execute
processed");
my ($isprocessed) = $processed_hnd->fetchrow_array;
$processed_hnd->finish();
if ($isprocessed){
$self->{ProcessStatus} = 1;
return "#4EEE94";
}else{
$self->{ProcessStatus} = 0;
return "FF";
}
}
..
sub db_connect {
require DBI;
my $dbname = 'CS';
my ($dbuser, $dbpasswd) = ('myuser', 'mypass');
my $dbh = DBI->connect("DBI:mysql:$dbname", $dbuser, $dbpasswd)
or die "can't connect: $DBI::errstr\n";
# we need these waiting for queries, so we are going to prepare them ahead of
time, and yes
# horror of horror they will be global. Sorry Mom I tried :(
$processed_hnd = $dbh->prepare_cached("select ord_tpak_processed from orders
where ord_num=?") or confess("can't get tpak processed");
$status_hnd = $dbh->prepare_cached("select is_hold_set,holdstate from
holds where ord_num=?") or confess("can't get hold status");
#DBI->trace(2,"/usr/local/apache/htdocs/out.log");
return $dbh;
}
Most of the modules just have simple subs called db_connect that don't have
prepared statments sitting like this. I did this because I have to check the
status of a LOT of rows and return the display fast. This seemed to work
well at the time. It was defiantly faster that preparing the statement over
and over.
I am running under mod perl 1.x Apache 1.3x, and loading my CGI::App module
and other modules from a start.pl
I am using Apache::DBI and connect_on_init. So I have these problems, they
all seem to be related, but how??
1. Connections are getting lost. I get errors in the log about fetch without
an execute which indicate this. Either the user sees an internal server
error, or else I believe DBI will try to reconnect and the query will then
succeed. But that slows things down when it happens. All I have to do to
these kinds of errors is reload a page very quickly. click, click, click fast..
2. Every once in a while I get an out of memory error.
3. My main search result page is getting cached, the closure type of
problem. ***Sometimes*** All I have read says that because I am using oop
modules and use strict along with use vars that should not happen. I have
not gotten a
[mp2.0] How do I port modules using Apache::SIG?
I'm attempting to run Scoop 0.9 (scoop.kuro5hin.org) under Apache2/mod_perl 2.0 running on Windows 2000, but the application was written for Apache/mp 1.x, so it uses Apache::SIG (and possibly other) modules that are no longer in mod_perl. The mod_perl developer documentation for porting from 1.x to 2.x doesn't really cover the missing modules, other than to say you can use Apache::compat to allow use of deprecated methods. This doesn't do the job here, which makes sense because the SIG module isn't even installed on my system. Is there any resource that discusses the changes between mod_perl 1.x and 2.x in more detail than the current developer document? The key point here is what has been deprecated/removed/rearchitected in mod_perl 2.x? and how do I replace it?
[mp2] Having to reload apache when perl modules change
Hi again group. A quick question (but this might not be the right place). If this is the wrong place to ask, please point me in the direction of the right place. I have a web app written using mod_perl2 and apache::ASP. When I change the code in a perl module, I have to restart apache to make the changes appear to all children. Is there a way of avoiding this - maybe with an apache directive - so that all modules are re-read by all children without a restart ? Thanks Richard
modperl 2.0 problems with Apache::Cookie and related modules.
Hi, I am trying to configure a working apache2/modperl2 setup, unfortunately I can not seemt to get a critical module Apache::Cookie to install, I keep getting this error. Can't locate Apache/MyConfig.pm in @INC (@INC contains: /usr/local/lib/perl5/5.8.0/i686-linux-thread-multi /usr/local/lib/perl5/5.8.0 /usr/local/lib/perl5/site_perl/5.8.0/i686-linux-thread-multi /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl .) at Makefile.PL line 27. BEGIN failed--compilation aborted at Makefile.PL line 27. any ideas what might be going on here. Thanks --bash
introducing a set of modules to create dynamic websites
Hello, I'm from switzerland and I'm quite new to this list; greetings to all (mod)perl mongers ;-) I always were interested to write some stuff to produce dynamic websites easily. Therefore I firstly began to write perl (mod_cgi) stuff to do this. But about a year a go I learned about mod_perl and fell in love ;-) The last project I did was quite interesting and is still going on. It required a lot of work, so I decided to build it on top of a flexible framset. This work has evolved into a IMO fairly solid and good framework to produce dynamic websites and I would like to share these modules with the public. I know there are allready some modules that provides ways to do simliar things, but (hopefully) my modules work a bit different. Basically I would like to know if there is some interest for these modules. It would be too much to write all features down here, but I want to give you a short overview : Basically we have users, groups, session and repositories. Repositories are used to store files with user permissions. I first have to load/init those things within the handler and can then begin to generate the output. I use _one_ "taglib" method-call to do this. Basically it's quite the same like struts tags from java. That means you can do loops, ifs and more within your templates. This way you easily can implement logics within your templates. There are also ways to display dates, format input fields, display input arguments, etc. I also includes (my)sql support (with DBI) which can be "accessed" through special tags within your templates. Xapian is also included as the search backend. If you know html you should be able to "configure" the templates and the taglib calls and if you know perl you also can easily extend the taglibs to provide other/new features. There are also methods to localize things (ie. date output) and a configuration "API" (you can easily "map" methods/variables to configuration options). I wrote many abstraction layers to get a flexible way to replace a certain way of ie storing data. With the config package you just need to load a config file rather then calling all config methods from all loaded packages yourself. Also included is a wysiwyg editor to create html content. This also easily can be "personalized" by editing simple text files. It's not really a realtime wysiwig editor, but you fairly can estimate how your results will be; and if your flexlib files are ok, the content will be valid html :-) I was also able to do a flextag that lets you choose from adresses from a sql databse. This way you can configure a powerfull set of html fragmets your editors can use. This way you are also in control of the look of all fragments (ie. links or lists etc). But you can also limit you editors if you explicit define the input fields they can edit (this can be image, text or any other flextag). There are a lot more features which would be worth to mention, but it seems to be too much. I allready wrote about 50 pages of documentation and if there is some interest I also would setup a website for this. Maybe some interesting facts: - one http process takes about 5MB at start and can grow up to 10-20MB (just for these modules, apache normally will take 3-5MB for himself). - I use caching as often as possible. You can tell taglibs that they should use caching. Caching actually is implemented on file-system. I use /dev/shm/ so it's still within ram and doesn't need seeks. - I have a page with ~4 sql statements and one "complicated" content file and ~50kb template code and ~100 tags. On a PII 300 celeron it takes 0.60 seconds to generate the first hit and after everything is cached 0.15seconds. I even do cache most sql statements and cache is also invalidated on updates :-) - It is designed for mod_perl 1.x; don't know how much work it would be to port it to. - there are actually 42 package files with a size of 631KB You should know that some edges may not scale that well (yet?). Basically the user implementation seems not to scale that well (I use simple files on filesystem). Fetching memberlist seems to be really inefficient that way (do not know how well the OS can cache these things). The data for content (and other) files are designed to be xml files, but I switched to my own format which stores the same information as xml can (or at least as far as I need xml), but it's faster to read, maybe datadumper modules are even faster, dind't try that out yet. The whole thing still can be run under mod_cgi, and that maybe is why some things do not scale that well. I know, the whole mail is quite confused as I mixed quite a lot of info into it. But basically I really just would like to know if there is an interest in such a thing. Maybe you even like to know some more details, so please ask :-) I also can g
Re: gaining access to config directives of other modules
dorian wrote: i know Apache::Module can get at all the installed modules and their directives, and even the spec of those directives, but what about the actual values of those directives? i notice Apache::Module is old, but i don't see anything else out there that looks like it will come close to doing the job. insight is welcome. Apache::Module is really cool, old or not, but probably isn't really production material based on the underlying wizardry. this thread offers a few different solutions, in increasing level of segfault probability :) http://marc.theaimsgroup.com/?l=apache-modperl&m=103791699126881&w=2 HTH --Geoff
Re: Apache modules and mod_perl threads in same process?
Marc M. Adkins wrote: For Apache 2.0.46 / mod_perl 1.99.10-dev: If I have an Apache module configured in httpd.conf, will the module code be executing in the same process as the mod_perl code? If there are multiple Apache processes (on W2K I always see 2) will the module code exist in all processes? I'm assuming that you are talking about threaded mpms (winnt in your case?) Then the answer is yes. Whenever the perchild mpm will be completed, it'll be possible to do grouping. However I'm not sure how applicable that would be to winFU platforms. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache modules and mod_perl threads in same process?
Yes, should be the same code. You could, of course, do wierd things in your perl code to pick up different libraries, but I can't imagine you would do that purposefully. dale - Original Message - From: "Marc M. Adkins" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, June 07, 2003 1:21 AM Subject: Apache modules and mod_perl threads in same process? > For Apache 2.0.46 / mod_perl 1.99.10-dev: > > If I have an Apache module configured in httpd.conf, will the module code be > executing in the same process as the mod_perl code? If there are multiple > Apache processes (on W2K I always see 2) will the module code exist in all > processes? > > mma
Re: modules that work with both modperl1 and 2
On Mon, 2003-06-09 at 12:12, Shannon Eric Peevey wrote:
> PS Am having problems with the compile time loading of modules depending
> on the existence of either modperl1 or 2... "use" dies and "require" is
> not importing the symbols correctly at runtime...
If you read the docs for "use" (perldoc -f use), you will see that "use"
is just like:
BEGIN { require Module; import Module LIST; }
If you want to import things correctly when using require, you have to
call import yourself.
- Perrin
Re: modules that work with both modperl1 and 2
Perrin Harkins wrote:
On Mon, 2003-06-09 at 12:12, Shannon Eric Peevey wrote:
PS Am having problems with the compile time loading of modules depending
on the existence of either modperl1 or 2... "use" dies and "require" is
not importing the symbols correctly at runtime...
If you read the docs for "use" (perldoc -f use), you will see that "use"
is just like:
BEGIN { require Module; import Module LIST; }
If you want to import things correctly when using require, you have to
call import yourself.
- Perrin
Yeah, I've been messing with that, but it seems to me that I need
something similar to a preprocessor directive, where I can load the
appropriate "use MODULE" lines into the module bases upon which version
of modperl they have installed. Is it possible to use the BEGIN {}
subroutine as this?
speeves
cws
Re: modules that work with both modperl1 and 2
On Mon, 2003-06-09 at 13:57, Shannon Eric Peevey wrote:
> Yeah, I've been messing with that, but it seems to me that I need
> something similar to a preprocessor directive, where I can load the
> appropriate "use MODULE" lines into the module bases upon which version
> of modperl they have installed. Is it possible to use the BEGIN {}
> subroutine as this?
You don't need a preprocessor. You can call require inside an if/else
conditional, unlike use() statements which run at compile time and skip
the conditional logic.
For example:
if ($mod_perl::VERSION >= 1.99) {
require Apache2::Module;
import Apache2::Module;
} else {
require Apache1::Module;
import Apache1::Module;
}
You can put that whole construct in a BEGIN block if you want to. That
will make it run before the rest of the code in the current package.
- Perrin
Re: modules that work with both modperl1 and 2
Perrin Harkins wrote:
On Mon, 2003-06-09 at 13:57, Shannon Eric Peevey wrote:
Yeah, I've been messing with that, but it seems to me that I need
something similar to a preprocessor directive, where I can load the
appropriate "use MODULE" lines into the module bases upon which version
of modperl they have installed. Is it possible to use the BEGIN {}
subroutine as this?
You don't need a preprocessor. You can call require inside an if/else
conditional, unlike use() statements which run at compile time and skip
the conditional logic.
For example:
if ($mod_perl::VERSION >= 1.99) {
require Apache2::Module;
import Apache2::Module;
} else {
require Apache1::Module;
import Apache1::Module;
}
You can put that whole construct in a BEGIN block if you want to. That
will make it run before the rest of the code in the current package.
- Perrin
Ok, I'm back... :( Here is the code, modified to use "require":
use mod_perl;
# setting the constants to help identify which version of mod_perl
# is installed
use constant MP2 => ($mod_perl::VERSION >= 1.99);
# test for the version of mod_perl, and use the appropriate libraries
# if (!MP2) { use Apache::Constants qw(:common); }
if (MP2) {
require Apache::Const;
import Apache::Access;
require Apache::Access;
import Apache::Access;
require Apache::Connection;
import Apache::Connection;
require Apache::Log;
import Apache::Log;
require Apache::RequestRec;
import Apache::RequestRec;
require Apache::RequestUtil;
import Apache::RequestUtil;
}
Here is the code that is coughing up the error:
102 #Look for user based on UIDAttr
103
104my $attrs = ['dn'];
105 $mesg = $ldap->search(
106 base => $basedn,
107 scope => 'sub',
108 filter => "($uidattr=$user)",
109 attrs => $attrs
110 );
111
112 if (my $error = $mesg->code())
113{
114 $r->note_basic_auth_failure;
115 MP2 ? $r->log_error("user $user: LDAP Connection Failed:
$error",$r->uri) : $r->log_reason("us
er $user: LDAP Connection Failed: $error",$r->uri);
116 MP2 ? return Apache::Log->HTTP_UNAUTHORIZED : return
Apache::Constants->HTTP_UNAUTHORIZED;
117}
118
119unless ($mesg->count())
120{
121 $r->note_basic_auth_failure;
122 MP2 ? $r->log_error("user $user: user entry not found
for filter: $uidattr=$user",$r->uri) : $
r->log_reason("user $user: user entry not found for filter:
$uidattr=$user",$r->uri);
123 MP2 ? return Apache::Log->HTTP_UNAUTHORIZED : return
Apache::Constants->HTTP_UNAUTHORIZED;
124}
And, here is the error that I am getting in the Apache2 logs, (using
mod_perl 1.99_09)
[Mon Jun 09 13:45:30 2003] [error] user asdf: user entry not found for
filter: uid=asdf/
[Mon Jun 09 13:45:30 2003] [error] [client 127.0.0.1] Can't locate
object method "HTTP_UNAUTHORIZED" via package "Apache::Log" (perhaps you
forgot to load "Apache::Log"?) at
/usr/local/share/perl/5.6.1/Apache/AuthNetLDAP.pm line 123.
As you can see, it is running everything up to the HTTP_UNAUTHORIZED
constant...
If you have any ideas, I would greatly appreciate it. :)
Thanks,
speeves
cws
PS. As a matter of fact, I get the same error when using "use"
instead... (Possibly a screwed perl or mod_perl installation? I'm
running debian woody, apache 2.0.46, perl 5.6.1, mod_perl 1.99_09.)
Re: modules that work with both modperl1 and 2
Shannon Eric Peevey wrote:
Perrin Harkins wrote:
On Mon, 2003-06-09 at 13:57, Shannon Eric Peevey wrote:
To answer your original question, Apache::Peek on CPAN now works with both
mod_perl versions. And while it uses separate implementations for each
version, the test suite uses the same code to test both.
Yeah, I've been messing with that, but it seems to me that I need
something similar to a preprocessor directive, where I can load the
appropriate "use MODULE" lines into the module bases upon which
version of modperl they have installed. Is it possible to use the
BEGIN {} subroutine as this?
You don't need a preprocessor. You can call require inside an if/else
conditional, unlike use() statements which run at compile time and skip
the conditional logic.
For example:
if ($mod_perl::VERSION >= 1.99) {
require Apache2::Module;
import Apache2::Module;
} else {
require Apache1::Module;
import Apache1::Module;
}
You can put that whole construct in a BEGIN block if you want to. That
will make it run before the rest of the code in the current package.
- Perrin
Ok, I'm back... :( Here is the code, modified to use "require":
use mod_perl;
# setting the constants to help identify which version of mod_perl
# is installed
use constant MP2 => ($mod_perl::VERSION >= 1.99);
# test for the version of mod_perl, and use the appropriate libraries
# if (!MP2) { use Apache::Constants qw(:common); }
if (MP2) {
require Apache::Const;
import Apache::Access;
require Apache::Access;
import Apache::Access;
require Apache::Connection;
import Apache::Connection;
require Apache::Log;
import Apache::Log;
require Apache::RequestRec;
import Apache::RequestRec;
require Apache::RequestUtil;
import Apache::RequestUtil;
}
You don't need to import anything, since none of these modules import
anything. Just require will do.
Here is the code that is coughing up the error:
102 #Look for user based on UIDAttr
103
104my $attrs = ['dn'];
105 $mesg = $ldap->search(
106 base => $basedn,
107 scope => 'sub',
108 filter => "($uidattr=$user)",
109 attrs => $attrs
110 );
111
112 if (my $error = $mesg->code())
113{
114 $r->note_basic_auth_failure;
115 MP2 ? $r->log_error("user $user: LDAP Connection Failed:
$error",$r->uri) : $r->log_reason("us
er $user: LDAP Connection Failed: $error",$r->uri);
116 MP2 ? return Apache::Log->HTTP_UNAUTHORIZED : return
Apache::Constants->HTTP_UNAUTHORIZED;
this should be:
return MP2 ? Apache::HTTP_UNAUTHORIZED : Apache::Constants::HTTP_UNAUTHORIZED;
and before the handler (at the top of your module) you need to add:
BEGIN {
if (MP2) {
require Apache::Const;
Apache::Const->import(-compile => 'HTTP_UNAUTHORIZED');
}
else {
require Apache::Constants;
Apache::Constants->import('HTTP_UNAUTHORIZED');
}
}
See:
http://search.cpan.org/src/STAS/Apache-Peek-1.01/t/response/TestApachePeek/basic.pm
117}
118
119unless ($mesg->count())
120{
121 $r->note_basic_auth_failure;
122 MP2 ? $r->log_error("user $user: user entry not found for
filter: $uidattr=$user",$r->uri) : $
r->log_reason("user $user: user entry not found for filter:
$uidattr=$user",$r->uri);
123 MP2 ? return Apache::Log->HTTP_UNAUTHORIZED : return
Apache::Constants->HTTP_UNAUTHORIZED;
124}
And, here is the error that I am getting in the Apache2 logs, (using
mod_perl 1.99_09)
[Mon Jun 09 13:45:30 2003] [error] user asdf: user entry not found for
filter: uid=asdf/
[Mon Jun 09 13:45:30 2003] [error] [client 127.0.0.1] Can't locate
object method "HTTP_UNAUTHORIZED" via package "Apache::Log" (perhaps you
forgot to load "Apache::Log"?) at
/usr/local/share/perl/5.6.1/Apache/AuthNetLDAP.pm line 123.
As you can see, it is running everything up to the HTTP_UNAUTHORIZED
constant...
If you have any ideas, I would greatly appreciate it. :)
Thanks,
speeves
cws
PS. As a matter of fact, I get the same error when using "use"
instead... (Possibly a screwed perl or mod_perl installation? I'm
running debian woody, apache 2.0.46, perl 5.6.1, mod_perl 1.99_09.)
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: modules that work with both modperl1 and 2
Stas Bekman wrote:
Shannon Eric Peevey wrote:
Perrin Harkins wrote:
On Mon, 2003-06-09 at 13:57, Shannon Eric Peevey wrote:
To answer your original question, Apache::Peek on CPAN now works with
both mod_perl versions. And while it uses separate implementations for
each version, the test suite uses the same code to test both.
Yeah, I've been messing with that, but it seems to me that I need
something similar to a preprocessor directive, where I can load the
appropriate "use MODULE" lines into the module bases upon which
version of modperl they have installed. Is it possible to use the
BEGIN {} subroutine as this?
You don't need a preprocessor. You can call require inside an if/else
conditional, unlike use() statements which run at compile time and skip
the conditional logic.
For example:
if ($mod_perl::VERSION >= 1.99) {
require Apache2::Module;
import Apache2::Module;
} else {
require Apache1::Module;
import Apache1::Module;
}
You can put that whole construct in a BEGIN block if you want to. That
will make it run before the rest of the code in the current package.
- Perrin
Ok, I'm back... :( Here is the code, modified to use "require":
use mod_perl;
# setting the constants to help identify which version of mod_perl
# is installed
use constant MP2 => ($mod_perl::VERSION >= 1.99);
# test for the version of mod_perl, and use the appropriate libraries
# if (!MP2) { use Apache::Constants qw(:common); }
if (MP2) {
require Apache::Const;
import Apache::Access;
require Apache::Access;
import Apache::Access;
require Apache::Connection;
import Apache::Connection;
require Apache::Log;
import Apache::Log;
require Apache::RequestRec;
import Apache::RequestRec;
require Apache::RequestUtil;
import Apache::RequestUtil;
}
You don't need to import anything, since none of these modules import
anything. Just require will do.
Here is the code that is coughing up the error:
102 #Look for user based on UIDAttr
103
104my $attrs = ['dn'];
105 $mesg = $ldap->search(
106 base => $basedn,
107 scope => 'sub',
108 filter => "($uidattr=$user)",
109 attrs => $attrs
110 );
111
112 if (my $error = $mesg->code())
113{
114 $r->note_basic_auth_failure;
115 MP2 ? $r->log_error("user $user: LDAP Connection
Failed: $error",$r->uri) : $r->log_reason("us
er $user: LDAP Connection Failed: $error",$r->uri);
116 MP2 ? return Apache::Log->HTTP_UNAUTHORIZED : return
Apache::Constants->HTTP_UNAUTHORIZED;
this should be:
return MP2 ? Apache::HTTP_UNAUTHORIZED :
Apache::Constants::HTTP_UNAUTHORIZED;
and before the handler (at the top of your module) you need to add:
BEGIN {
if (MP2) {
require Apache::Const;
Apache::Const->import(-compile => 'HTTP_UNAUTHORIZED');
}
else {
require Apache::Constants;
Apache::Constants->import('HTTP_UNAUTHORIZED');
}
}
See:
http://search.cpan.org/src/STAS/Apache-Peek-1.01/t/response/TestApachePeek/basic.pm
117}
118
119unless ($mesg->count())
120{
121 $r->note_basic_auth_failure;
122 MP2 ? $r->log_error("user $user: user entry not found
for filter: $uidattr=$user",$r->uri) : $
r->log_reason("user $user: user entry not found for filter:
$uidattr=$user",$r->uri);
123 MP2 ? return Apache::Log->HTTP_UNAUTHORIZED : return
Apache::Constants->HTTP_UNAUTHORIZED;
124}
And, here is the error that I am getting in the Apache2 logs, (using
mod_perl 1.99_09)
[Mon Jun 09 13:45:30 2003] [error] user asdf: user entry not found
for filter: uid=asdf/
[Mon Jun 09 13:45:30 2003] [error] [client 127.0.0.1] Can't locate
object method "HTTP_UNAUTHORIZED" via package "Apache::Log" (perhaps
you forgot to load "Apache::Log"?) at
/usr/local/share/perl/5.6.1/Apache/AuthNetLDAP.pm line 123.
As you can see, it is running everything up to the HTTP_UNAUTHORIZED
constant...
If you have any ideas, I would greatly appreciate it. :)
Thanks,
speeves
cws
PS. As a matter of fact, I get the same error when using "use"
instead... (Possibly a screwed perl or mod_perl installation? I'm
running debian woody, apache 2.0.46, perl 5.6.1, mod_perl 1.99_09.)
Hi!
That did it!!! Thank you so much for your patience and help with all
that I am working on here. After I test these changes on modperl 1
tomorrow, I should be able to upload it to CPAN, and it will be ready
for prime-time... (fingers crossed ;) )
Most humbly yours,
speeves
cws
Re: modules that work with both modperl1 and 2
speeves wrote: Stas Bekman wrote: [...] http://search.cpan.org/src/STAS/Apache-Peek-1.01/t/response/TestApachePeek/basic.pm That did it!!! Thank you so much for your patience and help with all that I am working on here. After I test these changes on modperl 1 tomorrow, I should be able to upload it to CPAN, and it will be ready for prime-time... (fingers crossed ;) ) Based on your porting experience if you have additions/corrections to these two documents: http://perl.apache.org/docs/2.0/user/porting/porting.html http://perl.apache.org/docs/2.0/user/porting/compat.html please submit those here. BTW, I have updated the info on the constants: http://perl.apache.org/docs/2.0/user/porting/compat.html#mod_perl_1_0_and_2_0_Constants_Coexistence __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: modules that work with both modperl1 and 2
Stas Bekman wrote:
speeves wrote:
Stas Bekman wrote:
[...]
http://search.cpan.org/src/STAS/Apache-Peek-1.01/t/response/TestApachePeek/basic.pm
This source code was the saving grace for me. If we could add the link
to:
http://search.cpan.org/src/STAS/Apache-Peek-1.01/t/response/TestApachePeek/basic.pm
into the documentation, that would be great.
hat did it!!! Thank you so much for your patience and help with all
that I am working on here. After I test these changes on modperl 1
tomorrow, I should be able to upload it to CPAN, and it will be ready
for prime-time... (fingers crossed ;) )
Based on your porting experience if you have additions/corrections to
these two documents:
http://perl.apache.org/docs/2.0/user/porting/porting.html
http://perl.apache.org/docs/2.0/user/porting/compat.html
please submit those here.
BTW, I have updated the info on the constants:
http://perl.apache.org/docs/2.0/user/porting/compat.html#mod_perl_1_0_and_2_0_Constants_Coexistence
__
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
Also, it would probably be nice to have a link from:
http://perl.apache.org/docs/2.0/user/porting/porting.html#Making_Code_Conditional_on_Running_mod_perl_Version
to
http://perl.apache.org/docs/2.0/user/porting/compat.html#mod_perl_1_0_and_2_0_Constants_Coexistence
that would help the "porter" to understand the overall picture of what
needs to be done to allow the single code-base to work with both
mod_perls...
Finally, I found that the PAUSE server did not recognize the $VERSION
number, (returned as undef), until I placed it above the BEGIN {} block
as following:
package Apache::AuthNetLDAP;
use strict;
use vars qw($VERSION @ISA @EXPORT @EXPORT_OK);
use Net::LDAP;
use mod_perl;
require Exporter;
@ISA = qw(Exporter AutoLoader);
# Items to export into callers namespace by default. Note: do not export
# names by default without a very good reason. Use EXPORT_OK instead.
# Do not simply export all your public functions/methods/constants.
@EXPORT = qw(
);
$VERSION = '0.21';
# setting the constants to help identify which version of mod_perl
# is installed
use constant MP2 => ($mod_perl::VERSION >= 1.99);
# test for the version of mod_perl, and use the appropriate libraries
BEGIN {
if (MP2) {
require Apache::Const;
require Apache::Access;
require Apache::Connection;
require Apache::Log;
require Apache::RequestRec;
require Apache::RequestUtil;
Apache::Const->import(-compile => 'HTTP_UNAUTHORIZED','OK');
} else {
require Apache::Constants;
Apache::Constants->import('HTTP_UNAUTHORIZED','OK');
}
}
# Preloaded methods go here.
#handles Apache requests
sub handler {
...
}
Thanks again for all of your help! If you know of any modules that need
porting in a like manner, feel free to contact me and I would be happy
to help out.
speeves
cws
Re: modules that work with both modperl1 and 2
Shannon Eric Peevey wrote:
Stas Bekman wrote:
This source code was the saving grace for me. If we could add the link
to:
http://search.cpan.org/src/STAS/Apache-Peek-1.01/t/response/TestApachePeek/basic.pm
into the documentation, that would be great.
No need to, I've already merged it into the docs:
http://perl.apache.org/docs/2.0/user/porting/compat.html#mod_perl_1_0_and_2_0_Constants_Coexistence
Also, it would probably be nice to have a link from:
http://perl.apache.org/docs/2.0/user/porting/porting.html#Making_Code_Conditional_on_Running_mod_perl_Version
to
http://perl.apache.org/docs/2.0/user/porting/compat.html#mod_perl_1_0_and_2_0_Constants_Coexistence
that would help the "porter" to understand the overall picture of what
needs to be done to allow the single code-base to work with both
mod_perls...
done, thanks for the suggestion.
Finally, I found that the PAUSE server did not recognize the $VERSION
number, (returned as undef), until I placed it above the BEGIN {} block
as following:
Yes, not before the BEGIN block, but before any other occurence of the string
VERSION. Some claim that this is a bug, others that it's a feature. Depends on
who you ask.
BTW, to verify your module that its version is parsable correctly by PAUSE,
you don't need to submit it to pause, but use:
perl -MExtUtils::MakeMaker -le 'print MM->parse_version(shift)' 'file'
as explained at:
http://pause.perl.org/pause/query?ACTION=pause_04about#conventions
I've added a note about this to the porting docs.
package Apache::AuthNetLDAP;
[...]
$VERSION = '0.21';
# setting the constants to help identify which version of mod_perl
# is installed
use constant MP2 => ($mod_perl::VERSION >= 1.99);
[...]
Thanks again for all of your help! If you know of any modules that need
porting in a like manner, feel free to contact me and I would be happy
to help out.
I think there are quite a few modules that need porting. Just go to CPAN pick
one and go with it. Probably first contact the author so you don't step on
their toes.
I'm planning on adding more docs as I doing porting myself, and if others find
new tricks and useful additions to the existing docs don't hesitate to post
them here, just like Shannon did. Which is *very* helpful! Thank you Shannon!
I'm also thinking about creating several modules to ease the porting, I'll
post more on this when I'll get around writing some first prototypes.
__
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
Problems with dynamically-loaded perl modules under Solaris 2.5.1
I'm having problems with modules that use DynaLoader (Data::Dumper and Storable, specifically) under mod_perl on Solaris machines. These modules work fine in standalone scripts, or when run under mod_cgi or mod_fastcgi, but as soon as I put a "use Storable" in a mod_perl handler, I get this in my error log: [Tue Oct 26 11:21:33 1999] [error] Can't load '/usr/local/lib/perl5/site_perl/5.005/sun4-solaris/auto/Storable/Storable.so' for module Storable: ld.so.1: ./httpd: fatal: relocation error: file /usr/local/lib/perl5/site_perl/5.005/sun4-solaris/auto/Storable/Storable.so: symbol main: referenced symbol not found at /usr/local/lib/perl5/5.00503/sun4-solaris/DynaLoader.pm line 169. BTW I get an identical message if I put a "use Storable" inside a section in my httpd.conf. After searching the mailing list archive, I see that this sort of thing can happen if mod_perl was compiled against the "wrong" version of perl on the system. So just to make sure, I removed all remnants of an older 5.004 install, remade mod_perl, and I'm still getting the errors. My setup: Solaris 2.5.1 (Sparc) gcc 2.95 perl 5.005_03 (compiled with above gcc, as were the below) apache 1.3.9 (with all modules compiled statically) mod_perl 1.21 (EVERYTHING=1) mod_fastcgi 2.2.2 I'm not having this problem with an otherwise nearly identical setup under Redhat Linux 5.x (the differences being OS, of course, and gcc 2.7.2.3). Any help appreciated.
Re: Problems with dynamically-loaded perl modules under Solaris2.5.1
On Wed, 27 Oct 1999, Francesc Guasch wrote: > what's the ld version you use ?, make sure you compiled perl using the > solaris hints you can find in the perl sources. I've got GNU ld 2.9.1, but the perl Configure said GNU ld won't build perl, so it used /usr/ccs/bin/ld (version 3.0). I compiled perl using all the "solaris_2" hints except I chose NOT to use perl's malloc. Just to restate this, everything works wonderfully otherwise with this version of perl. It's only a problem when I do something like "use Data::Dumper;" inside a mod_perl handler. Update: I downgraded to perl 5.004_05, and suddenly everything works. I'd like to use 5.005_03 though. Any clues?
Re: Problems with dynamically-loaded perl modules under Solaris2.5.1
I did some experimenting with my Solaris2.5.1/mod_perl/Data::Dumper/Storable problem that I wrote about last week. A grid: | mod_perl 1.21 | 1.21-dev (19991101174047) -+---+-- perl5.004_05 | works fine| didn't try perl5.005_03 | doesn't work | doesn't work perl5.005_62 | won't compile | works fine! All versions of perl compiled with all solaris hints. So is this a 5.005_03-specific bug? Any word on 5.005_04?
Re: Problems with dynamically-loaded perl modules under Solaris2.5.1
are you still stuck on this? did you link mod_perl static or dso? if dso, try static. you can also try configuring Perl with -Dusemymalloc=n, but that comes with a large performance hit. I've never had a problem with solaris and any combo of mod_perl/Perl On Mon, 1 Nov 1999, Dan Rench wrote: > > I did some experimenting with my Solaris2.5.1/mod_perl/Data::Dumper/Storable > problem that I wrote about last week. A grid: > > > | mod_perl 1.21 | 1.21-dev (19991101174047) > -+---+-- > perl5.004_05 | works fine| didn't try > perl5.005_03 | doesn't work | doesn't work > perl5.005_62 | won't compile | works fine! > > > All versions of perl compiled with all solaris hints. > > So is this a 5.005_03-specific bug? Any word on 5.005_04? >
Re: Problems with dynamically-loaded perl modules under Solaris2.5.1
On Mon, 13 Dec 1999, Doug MacEachern wrote: > are you still stuck on this? Yes. To reiterate: Solaris 2.5.1 sparc, gcc 2.95, perl 5.005_03 (configured with Solaris hints), mod_perl 1.21, apache 1.3.9, mod_fastcgi 2.2.2. Everything works fine EXCEPT when I try to "use" a dynamically loaded module (Data::Dumper or Storable, for example) inside a mod_perl handler. I have no trouble using these modules in regular perl scripts, mod_cgi scripts, or mod_fastcgi scripts. > did you link mod_perl static or dso? if dso, try static. All of my Apache modules are compiled statically. > you can also try configuring Perl with -Dusemymalloc=n, > but that comes with a large performance hit. I've tried it both ways, using perl's malloc or Solaris', and both give me the same result in my error logs: [Tue Dec 14 08:36:01 1999] [error] Can't load '/usr/local/lib/perl5/5.00503/sun4-solaris/auto/Data/Dumper/Dumper.so' for module Data::Dumper: ld.so.1: /usr/local/web/bin/httpd: fatal: relocation error: symbol not found: main: referenced in /usr/local/lib/perl5/5.00503/sun4-solaris/auto/Data/Dumper/Dumper.so at /usr/local/lib/perl5/5.00503/sun4-solaris/DynaLoader.pm line 169. All I need to do is add "use Data::Dumper;" in a handler to trigger this. And as I mentioned in my previous messages, this same setup works fine under Linux and FreeBSD. I can also get the problem to go away on Solaris by downgrading perl to 5.004_05 or upgrading it to 5.005_62. A co-worker who understands Perl internals better than I do seems to have tracked it down to a problem with Dynaloader's dlopen() call, though looking at ext/Dynaloader/dl_dlopen.xs in the various Perl sources there have apparently been no changes to it since 1994(?!). So maybe the problem lies elsewhere. Perl has caused my C skills to atrophy so we're getting into territory I don't really understand. Would something like gdb help diagnose the problem?
Re: Problems with dynamically-loaded perl modules under Solaris2.5.1
Recently I experienced similar problems on Solaris. I had to rebuild perl as shared libperl.so Perl library for mod_perl to work -- see perl intall manpages. Dan Rench wrote: > > On Mon, 13 Dec 1999, Doug MacEachern wrote: > > > are you still stuck on this? > > Yes. To reiterate: > > Solaris 2.5.1 sparc, gcc 2.95, perl 5.005_03 (configured with Solaris hints), > mod_perl 1.21, apache 1.3.9, mod_fastcgi 2.2.2. > > Everything works fine EXCEPT when I try to "use" a dynamically loaded module > (Data::Dumper or Storable, for example) inside a mod_perl handler. I have no > trouble using these modules in regular perl scripts, mod_cgi scripts, or > mod_fastcgi scripts. > > > did you link mod_perl static or dso? if dso, try static. > > All of my Apache modules are compiled statically. > > > you can also try configuring Perl with -Dusemymalloc=n, > > but that comes with a large performance hit. > > I've tried it both ways, using perl's malloc or Solaris', and both > give me the same result in my error logs: > > [Tue Dec 14 08:36:01 1999] [error] Can't load >'/usr/local/lib/perl5/5.00503/sun4-solaris/auto/Data/Dumper/Dumper.so' for module >Data::Dumper: ld.so.1: /usr/local/web/bin/httpd: fatal: relocation error: symbol not >found: main: referenced in >/usr/local/lib/perl5/5.00503/sun4-solaris/auto/Data/Dumper/Dumper.so at >/usr/local/lib/perl5/5.00503/sun4-solaris/DynaLoader.pm line 169. > > All I need to do is add "use Data::Dumper;" in a handler to trigger this. > > And as I mentioned in my previous messages, this same setup works fine under > Linux and FreeBSD. I can also get the problem to go away on Solaris by > downgrading perl to 5.004_05 or upgrading it to 5.005_62. > > A co-worker who understands Perl internals better than I do seems to have > tracked it down to a problem with Dynaloader's dlopen() call, though looking > at ext/Dynaloader/dl_dlopen.xs in the various Perl sources there have > apparently been no changes to it since 1994(?!). So maybe the problem lies > elsewhere. Perl has caused my C skills to atrophy so we're getting into > territory I don't really understand. Would something like gdb help diagnose > the problem? -- Eugene Miretskiy <[EMAIL PROTECTED]> InVision, INC. (516) 543-1000x219 http://www.invision.net
(Fwd) Template-Plugin-DBI 0.09 (DBI and HTML modules)
Here's a message from SAM explaining where to find the module. A --- Forwarded mail from [EMAIL PROTECTED] From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Template-Plugin-DBI 0.09 Date: Mon, 20 Dec 1999 15:21:23 - I have release an updated version of Template-Plugin-DBI which fixes quite a few previous problems. Things that now work correctly: Nested Queries. Queries without a record set (insert, delete etc). Prepare and Execute as separate stages I have added a lot of extra tests to ensure that going forward all of this continues to work as expected. In fixing some of the above problems the method for sub-classing this module has changed, but this should be for the last time. See t/subclass.t for an example of how it now works. Thanks to Andy for the latest set of changes to Template Toolkit which have made much of the test harness for the plugin much easier. Also for beating me up to release the version that he has been testing for a while. I have uploaded it to CPAN under authors/id/S/SA/SAM However until it reaches all mirrors you can find it here: ftp://ftp.knowledgepool.com/pub/perl/Template-Plugin-DBI/Template-Plugin-DBI -0.09.tar.gz Regards SAM ---End of forwarded mail from [EMAIL PROTECTED] -- Andy Wardley <[EMAIL PROTECTED]> Signature regenerating. Please remain seated. <[EMAIL PROTECTED]> For a good time: http://www.kfs.org/~abw/
Re: Problems with dynamically-loaded perl modules under Solaris2.5.1
On Thu, 16 Dec 1999, Eugene Miretskiy wrote: > Recently I experienced similar problems on Solaris. > > I had to rebuild perl as shared libperl.so Perl library for mod_perl > to work -- see perl intall manpages. Thanks! This appears to have fixed my problem (though it may have broken CPAN.pm -- it keeps saying "Package comes without Makefile.PL" even though it does -- but this is off-topic -- forget I even mentioned it). "Compile statically" is like a mantra* on this list (at least when it comes to apache modules), so it never occurred to me that building perl itself like this would work better than the static build. * another mantra of course being "don't use Redhat's prebuilt RPMs"
Re: Problems with dynamically-loaded perl modules under Solaris2.5.1
On Thu, 16 Dec 1999, Dan Rench wrote: > On Mon, 13 Dec 1999, Doug MacEachern wrote: > > > are you still stuck on this? > > Yes. To reiterate: > > Solaris 2.5.1 sparc, gcc 2.95, perl 5.005_03 (configured with Solaris hints), > mod_perl 1.21, apache 1.3.9, mod_fastcgi 2.2.2. > > Everything works fine EXCEPT when I try to "use" a dynamically loaded module > (Data::Dumper or Storable, for example) inside a mod_perl handler. I have no > trouble using these modules in regular perl scripts, mod_cgi scripts, or > mod_fastcgi scripts. this sounds an awful lot like the common solaris linker vs. gnu linker problem. what does 'perl -V:ld' say your linker is? make sure it's gnu (gcc) and that Apache is using the same.
Re: Problems with dynamically-loaded perl modules under Solaris2.5.1
On Tue, 21 Dec 1999, Doug MacEachern wrote: > this sounds an awful lot like the common solaris linker vs. gnu linker > problem. what does 'perl -V:ld' say your linker is? make sure it's gnu > (gcc) and that Apache is using the same. $ perl -V:ld ld='gcc'; What I don't understand is that when I "./Configure" perl it always says: NOTE: You are using GNU ld(1). GNU ld(1) will not build Perl. I'm arranging to use /usr/ccs/bin/ld by including -B/usr/ccs/bin/ in your gcc -B/usr/ccs/bin/ command. (Note that the trailing "/" is required.) ...so it tells me that it can't use GNU ld, and then does it anyway, apparently. Perl's Configure script also warns me that my GNU make has its set-GID bit set and I should remove it. So I "chmod 755 make". Then I get: *** WHOA THERE!!! *** Your C compiler "gcc -B/usr/ccs/bin/ -B/usr/ccs/bin/" doesn't seem to be working! You'd better start hunting for one and let me know about it. This topic is veering away from mod_perl (though the problem only manifests itself under mod_perl for me), so I'm going back to the libperl.so solution suggested earlier since that seems to work. Whatever the problem is, it appears to be fixed in the development version of Perl at least.
Re: Problems with dynamically-loaded perl modules under Solaris2.5.1
Dan Rench wrote: > > On Tue, 21 Dec 1999, Doug MacEachern wrote: > > > this sounds an awful lot like the common solaris linker vs. gnu linker > > problem. what does 'perl -V:ld' say your linker is? make sure it's gnu > > (gcc) and that Apache is using the same. > > $ perl -V:ld > ld='gcc'; > > What I don't understand is that when I "./Configure" perl it always says: > > NOTE: You are using GNU ld(1). GNU ld(1) will not build Perl. > I'm arranging to use /usr/ccs/bin/ld by including -B/usr/ccs/bin/ > in your gcc -B/usr/ccs/bin/ command. (Note that the trailing "/" is required.) This is exactly the same problem I experienced before I got libperl.so solution to work. > > ...so it tells me that it can't use GNU ld, and then does it anyway, > apparently. > > Perl's Configure script also warns me that my GNU make has its set-GID bit > set and I should remove it. So I "chmod 755 make". Then I get: > > *** WHOA THERE!!! *** > Your C compiler "gcc -B/usr/ccs/bin/ -B/usr/ccs/bin/" doesn't seem to be working! > You'd better start hunting for one and let me know about it. > > This topic is veering away from mod_perl (though the problem only manifests > itself under mod_perl for me), so I'm going back to the libperl.so solution > suggested earlier since that seems to work. Whatever the problem is, it > appears to be fixed in the development version of Perl at least. -- Eugene Miretskiy <[EMAIL PROTECTED]> InVision, INC. (516) 543-1000x219 http://www.invision.net
Problems with custom config directives in user written modules
I cannot seem to get custom configuration directives to work in
apache (1.3.11) modperl (1.21). I would presume the examples in the
book do not work either. I found someone having similar problems
in the list archives, to which Doug provided a workaround which also
does not work.
Any advice about this issue is helpful. Please reply to me directly as
well.
In Makefile.PL:
my @directives = (
...
{ name=> 'Directive4',
errmsg => 'Anything',
args_how=> 'RAW_ARGS',
req_override=> 'OR_ALL',
},
);
In the httpd.conf file:
require Apache::TestDirective;
delete $INC{'Apache/TestDirective.pm'};
#PerlModule Apache::TestDirective
Directive4 foo
What comes back:
Invalid command 'Directive4', perhaps mis-spelled or defined by a
module not included in the server configuration
Other details are...Modperl built with:
perl Makefile.PL APACHE_SRC=/usr/local/webadmin/${APACHE} DO_HTTPD=1
USE_APACI=1 PREP_HTTPD=1 EVERYTHING=1 PERL_TRACE=1
and Apache built with:
./configure \
"--with-layout=Apache" \
"--prefix=/usr/local/www" \
"--enable-module=most" \
"--enable-shared=max" \
"--activate-module=src/modules/extra/mod_macro.c" \
"--activate-module=src/modules/perl/libperl.a" \
$ bin/httpd -V
Server version: Apache/1.3.11 (Unix)
Server built: Jan 30 2000 17:23:31
Server's Module Magic Number: 19990320:6
Server compiled with
-D HAVE_MMAP
-D USE_MMAP_SCOREBOARD
-D USE_MMAP_FILES
-D USE_FLOCK_SERIALIZED_ACCEPT
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D HTTPD_ROOT="/usr/local/webadmin"
-D SUEXEC_BIN="/usr/local/webadmin/bin/suexec"
-D DEFAULT_PIDLOG="logs/httpd.pid"
-D DEFAULT_SCOREBOARD="logs/httpd.scoreboard"
-D DEFAULT_LOCKFILE="logs/httpd.lock"
-D DEFAULT_XFERLOG="logs/access_log"
-D DEFAULT_ERRORLOG="logs/error_log"
-D TYPES_CONFIG_FILE="conf/mime.types"
-D SERVER_CONFIG_FILE="conf/httpd.conf"
-D ACCESS_CONFIG_FILE="conf/access.conf"
-D RESOURCE_CONFIG_FILE="conf/srm.conf"
$ bin/httpd -l
Compiled-in modules:
http_core.c
mod_so.c
mod_macro.c
mod_perl.c
$ perl -V
Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
Platform:
osname=freebsd, osvers=3.3-release, archname=i386-freebsd
uname='freebsd somehost.org 3.3-release freebsd 3.3-release #0: sun nov 21
22:33:17 pst 1999 [EMAIL PROTECTED]:usrsrcsyscompilekern i386 '
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef useperlio=undef d_sfio=undef
Compiler:
cc='cc', optimize='-O', gccversion=2.7.2.3
cppflags='-I/usr/local/include -DPERL_EMERGENCY_SBRK -DDEBUGGING_MSTATS
-DPACK_MALLOC -DTWO_POT_OPTIMIZE'
ccflags ='-I/usr/local/include -DPERL_EMERGENCY_SBRK -DDEBUGGING_MSTATS
-DPACK_MALLOC -DTWO_POT_OPTIMIZE '
stdchar='char', d_stdstdio=undef, usevfork=true
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
alignbytes=4, usemymalloc=y, prototype=define
Linker and Libraries:
ld='cc', ldflags ='-Wl,-E -L/usr/local/lib'
libpth=/usr/lib /usr/local/lib
libs=-ldb -lm -lc -lcrypt
libc=/usr/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
cccdlflags='-DPIC -fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Built under freebsd
Compiled at Nov 22 1999 16:25:57
%ENV:
PERL5LIB="/home/dave/lib/perl"
@INC:
/home/dave/lib/perl
/usr/local/lib/perl5/5.00503/i386-freebsd
/usr/local/lib/perl5/5.00503
/usr/local/lib/perl5/site_perl/5.005/i386-freebsd
/usr/local/lib/perl5/site_perl/5.005
--
Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED]
>>> The opinions expressed above are entirely my own <<<
True freedom requires taking responsibility for your own life. That
frightens the hell out of too many people. They prefer to have Big
Brother holding a safety net for them, and they'll sell their own
birthright and their children's as well to keep it. --F. Paul Wilson
HELP: modules/ssi...FAILED before any test output arrived
Hello, I'm trying to compile Apache 1.3.12 and mod_perl 1.23 against perl 5.005_02 I'm using this to build mod_perl/Apache: perl Makefile.PL USE_APACI=1 \ EVERYTHING=1 \ APACHE_PREFIX=$PREFIX \ APACHE_SRC=$APACHE/src \ DO_HTTPD=1 \ APACI_ARGS=--enable-module=so,--enable-shared=perl And make test returns the following error (and surrounding lines) modules/src.....ok modules/ssi.FAILED before any test output arrived modules/stage...skipping test on this platform I'm not sure how to troubleshoot this problem. Any suggestions? I've kept the entire output from makefile.pl, make, and make test if you want to view any information from them. --James
IGNORE: modules/ssi...FAILED before any test output arrived
Hello, Sorry, I missed the line in the output stating DSO and PERLSSI don't play nice together. I should have paid more attention. My apologies. --James
Re: [RFC: performance] Preloading Perl Modules at Server Startup
> "SB" == Stas Bekman <[EMAIL PROTECTED]> writes: SB> But an even better approach is to create a separate startup file SB> (where you code in plain perl) and put there things like: SB> use DBI; SB> use Carp; SB> Then you C this startup file in I with the SB> C directive, placing it before the rest of the mod_perl SB> configuration directives: SB> PerlRequire /path/to/start-up.pl You should recommend use DBI (); use Carp (); so that no symbols are imported into the name space of the start-up.pl script as it is unlikely to be needed there. Also, I'd recommend using libapreq's Apache::Request if you don't need the content generating parts of CGI.pm... which leads to an enhancement I'd like to see Doug add to libapreq's functionality: Currently, you need to do a call like this if you're using Apache::Request inside a Registry script: my $ar = Apache::Request->new(Apache->request()) or die "Whoa Nelly!"; I'd like to see the Apache::Request->new() method automatically call Apache->request() if no parameters are passed to it. Inside a Apache->handler, it is easy since you already have a Apache->request object passed to you, but in Registry, it is a lot of extra typing.
RE: [RFC: performance] Preloading Perl Modules at Server Startup
> -Original Message- > From: Vivek Khera [mailto:[EMAIL PROTECTED]] > Sent: Monday, June 05, 2000 10:09 AM > To: mod_perl list > Subject: Re: [RFC: performance] Preloading Perl Modules at Server > Startup > > > >>>>> "SB" == Stas Bekman <[EMAIL PROTECTED]> writes: > > SB> But an even better approach is to create a separate startup file > SB> (where you code in plain perl) and put there things like: > > SB> use DBI; > SB> use Carp; > > SB> Then you C this startup file in I with the > SB> C directive, placing it before the rest of > the mod_perl > SB> configuration directives: > > SB> PerlRequire /path/to/start-up.pl > > > You should recommend > > use DBI (); > use Carp (); > > so that no symbols are imported into the name space of the start-up.pl > script as it is unlikely to be needed there. > > Also, I'd recommend using libapreq's Apache::Request if you don't need > the content generating parts of CGI.pm... which leads to an > enhancement I'd like to see Doug add to libapreq's functionality: > > Currently, you need to do a call like this if you're using > Apache::Request inside a Registry script: > > my $ar = Apache::Request->new(Apache->request()) or die > "Whoa Nelly!"; my $apr = Apache::Request->new(shift); requires less typing and still has the desired effect in Regitry scripts or handlers... --Geoff > > I'd like to see the Apache::Request->new() method automatically call > Apache->request() if no parameters are passed to it. Inside a > Apache->handler, it is easy since you already have a Apache->request > object passed to you, but in Registry, it is a lot of extra typing. >
RE: [RFC: performance] Preloading Perl Modules at Server Startup
[snip] > > > > Also, I'd recommend using libapreq's Apache::Request if you > don't need > > the content generating parts of CGI.pm... which leads to an > > enhancement I'd like to see Doug add to libapreq's functionality: > > > > Currently, you need to do a call like this if you're using > > Apache::Request inside a Registry script: > > > > my $ar = Apache::Request->new(Apache->request()) or die > > "Whoa Nelly!"; > > my $apr = Apache::Request->new(shift); did I really just say that? I guess that doesn't work for Registry scripts after all... sorry for the FUD :) --Geoff > > requires less typing and still has the desired effect in > Regitry scripts or > handlers... > > --Geoff > > > > > I'd like to see the Apache::Request->new() method automatically call > > Apache->request() if no parameters are passed to it. Inside a > > Apache->handler, it is easy since you already have a Apache->request > > object passed to you, but in Registry, it is a lot of extra typing. > > >
RE: [RFC: performance] Preloading Perl Modules at Server Startup
> -Original Message- > From: Geoffrey Young [mailto:[EMAIL PROTECTED]] > Sent: Monday, June 05, 2000 10:30 AM > To: 'Vivek Khera'; mod_perl list > Subject: RE: [RFC: performance] Preloading Perl Modules at Server > Startup > > > > [snip] > > > > > > Also, I'd recommend using libapreq's Apache::Request if you > > don't need > > > the content generating parts of CGI.pm... which leads to an > > > enhancement I'd like to see Doug add to libapreq's functionality: > > > > > > Currently, you need to do a call like this if you're using > > > Apache::Request inside a Registry script: > > > > > > my $ar = Apache::Request->new(Apache->request()) or die > > > "Whoa Nelly!"; > > > > my $apr = Apache::Request->new(shift); > > > did I really just say that? > > I guess that doesn't work for Registry scripts after all... > sorry for the > FUD :) ok, it does work... I'll stop posting now... > > --Geoff > > > > > > requires less typing and still has the desired effect in > > Regitry scripts or > > handlers... > > > > --Geoff > > > > > > > > I'd like to see the Apache::Request->new() method > automatically call > > > Apache->request() if no parameters are passed to it. Inside a > > > Apache->handler, it is easy since you already have a > Apache->request > > > object passed to you, but in Registry, it is a lot of > extra typing. > > > > > >
Re: [RFC: performance] Preloading Perl Modules at Server Startup
On Mon, 5 Jun 2000, Vivek Khera wrote: > > "SB" == Stas Bekman <[EMAIL PROTECTED]> writes: > > SB> But an even better approach is to create a separate startup file > SB> (where you code in plain perl) and put there things like: > > SB> use DBI; > SB> use Carp; > > SB> Then you C this startup file in I with the > SB> C directive, placing it before the rest of the mod_perl > SB> configuration directives: > > SB> PerlRequire /path/to/start-up.pl > > > You should recommend > > use DBI (); > use Carp (); > > so that no symbols are imported into the name space of the start-up.pl > script as it is unlikely to be needed there. that's right. > Also, I'd recommend using libapreq's Apache::Request if you don't need > the content generating parts of CGI.pm... which leads to an > enhancement That's a topic of another section. > I'd like to see Doug add to libapreq's functionality: > > Currently, you need to do a call like this if you're using > Apache::Request inside a Registry script: > > my $ar = Apache::Request->new(Apache->request()) or die "Whoa Nelly!"; > > I'd like to see the Apache::Request->new() method automatically call > Apache->request() if no parameters are passed to it. Inside a > Apache->handler, it is easy since you already have a Apache->request > object passed to you, but in Registry, it is a lot of extra typing. As Geoff has mentioned it works already with shift() ... seems ok to me. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: Patch for easy testing of Apache::* modules (resend)
Hi all,
Here's a resend of the Apache::test patch that I sent yesterday, this time
sent as type text/plain from a Unix mailer. Rick Myers noted that the
version I sent before was encoded with Macintosh BinHex, which is probably
not the most appropriate choice for this list. ;-)
-Ken
Index: test.pm
===
RCS file: /home/cvspublic/modperl/lib/Apache/test.pm,v
retrieving revision 1.16
diff -u -r1.16 test.pm
--- test.pm 2000/03/06 20:38:22 1.16
+++ test.pm 2000/07/17 05:18:12
@@ -44,6 +44,156 @@
*Apache::Constants::bootstrap = sub {};
}
+sub write_httpd_conf {
+my $pkg = shift;
+my %args = (conf_file => 't/httpd.conf', @_);
+my $DIR = `pwd`; chomp $DIR;
+
+local *CONF;
+open CONF, ">$args{conf_file}" or die "Can't create $args{conf_file}: $!";
+print CONF <);
+ $response ||= $default;
+} until (!$mustfind || (-e $response || !print("$response not found\n")));
+
+return $response;
+}
+
+sub get_test_params {
+my $pkg = shift;
+
+print("\nFor testing purposes, please give the full path to an httpd\n",
+ "with mod_perl enabled. The path defaults to \$ENV{APACHE}, if present.");
+
+my %conf;
+
+my $httpd = $ENV{'APACHE'} || which('apache') || which('httpd') ||
+'/usr/lib/httpd/httpd';
+
+$httpd = _ask("\n", $httpd, 1);
+system "$Config{lns} $httpd t/httpd";
+
+if (lc _ask("Search existing config file for dynamic module dependencies?", 'n')
+eq 'y') {
+ my %compiled;
+ for (`t/httpd -V`) {
+ if (/([\w]+)="(.*)"/) {
+ $compiled{$1} = $2;
+ }
+ }
+ $compiled{SERVER_CONFIG_FILE} =~ s,^,$compiled{HTTPD_ROOT}/,
+ unless $compiled{SERVER_CONFIG_FILE} =~ m,^/,;
+
+ my $file = _ask(" Config file", $compiled{SERVER_CONFIG_FILE}, 1);
+ $conf{modules} = $pkg->_read_existing_conf($file);
+}
+
+# Get default user (apache doesn't like to run as root, special-case it)
+my $defuser = ($< && getpwuid $<) || 'nobody';
+$conf{user} = _ask("User to run tests under", $defuser);
+
+my $defgroup = ($defuser eq 'nobody' ? 'nobody' : getgrgid((getpwnam
+$conf{user})[3]));
+$conf{group} = _ask("Group to run tests under", $defgroup);
+
+$conf{port} = _ask("Port to run tests under", 8228);
+
+return %conf;
+}
+
+sub _read_existing_conf {
+# Returns some config text
+shift;
+my ($server_conf) = @_;
+
+
+open SERVER_CONF, $server_conf or die "Couldn't open $server_conf: $!";
+my @lines = grep {!m/^\s*#/} ;
+close SERVER_CONF;
+
+my @modules = grep /^\s*(Add|Load)Module/, @lines;
+my ($server_root) = (map /^\s*ServerRoot\s*(\S+)/, @lines);
+
+# Rewrite all modules to load from an absolute path.
+foreach (@modules) {
+ s!(\s)([^/\s]\S+/)!$1$server_root/$2!;
+}
+
+# Directories where apache DSOs live.
+my (@module_dirs) = map {m,(/\S*/),} @modules;
+
+# Have to make sure that dir, autoindex and perl are loaded.
+my @required = qw(dir autoindex perl);
+
+my @l = `t/httpd -l`;
+my @compiled_in = map /^\s*(\S+)/, @l[1..@l-2];
+
+my @load;
+foreach my $module (@required) {
+ if (!grep /$module/i, @compiled_in, @modules) {
+ push @load, $module;
+ }
+}
+
+# Finally compute the directives to load modules that need to be loaded.
+ MODULE:
+foreach my $module (@load) {
+ foreach my $module_dir (@module_dirs) {
+ if (-e "$module_dir/mod_$module.so") {
+ push @modules, "LoadModule ${module}_module
+$module_dir/mod_$module.so\n"; next MODULE;
+ } elsif (-e "$module_dir/lib$module.so") {
+ push @modules, "LoadModule ${module}_module
+$module_dir/lib$module.so\n"; next MODULE;
+ } elsif (-e "$module_dir/ApacheModule\u$module.dll") {
+ push @modules, "LoadModule ${module}_module
+$module_dir/ApacheModule\u$module.dll\n"; next MODULE;
+ }
+ }
+}
+
+print "found the following modules: \n@modules";
+return join '', @modules;
+}
+
+# Find an executable in the PATH.
+sub which {
+foreach (map { "$_/$_[0]" } split /:/, $ENV{PATH}) {
+ next unless m,^/,;
+ return $_ if -x;
+}
+}
+
+
sub test {
my $s = $_[1] ? "ok $_[0]\n" : "not ok $_[0]\n";
if
Re: Patch for easy testing of Apache::* modules (resend)
On Mon, 17 Jul 2000, Ken Williams wrote: > Hi all, > > Here's a resend of the Apache::test patch that I sent yesterday, this time > sent as type text/plain from a Unix mailer. Rick Myers noted that the > version I sent before was encoded with Macintosh BinHex, which is probably > not the most appropriate choice for this list. ;-) looks great ken, applied, thanks! btw, when i first skimmed the patch, i thought it modified the mod_perl Makefile.PL test foo, which is why i was holding off.
Re: Patch for easy testing of Apache::* modules (resend)
[EMAIL PROTECTED] (Doug MacEachern) wrote: >On Mon, 17 Jul 2000, Ken Williams wrote: > >> Hi all, >> >> Here's a resend of the Apache::test patch that I sent yesterday, this time >> sent as type text/plain from a Unix mailer. Rick Myers noted that the >> version I sent before was encoded with Macintosh BinHex, which is probably >> not the most appropriate choice for this list. ;-) > >looks great ken, applied, thanks! >btw, when i first skimmed the patch, i thought it modified the >mod_perl Makefile.PL test foo, which is why i was holding off. Awesome, it looks like you've applied my two biggest patches. Now I'll go off and make sure they work =). ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: Patch for easy testing of Apache::* modules (resend)
[EMAIL PROTECTED] (Doug MacEachern) wrote:
>On Mon, 17 Jul 2000, Ken Williams wrote:
>
>> Hi all,
>>
>> Here's a resend of the Apache::test patch that I sent yesterday, this
>> time sent as type text/plain from a Unix mailer. Rick Myers noted
>> that the version I sent before was encoded with Macintosh BinHex,
>> which is probably not the most appropriate choice for this list. ;-)
>
>looks great ken, applied, thanks!
>btw, when i first skimmed the patch, i thought it modified the
>mod_perl Makefile.PL test foo, which is why i was holding off.
In looking over the changes, I found that I've done a little more work
since the last patch I sent. I didn't send it on because I wasn't sure
whether the first patch would be accepted or not. Anyway, I beefed up
the fetch() method and documented it. It's fully backward compatible,
so no changes are necessary to existing code that calls fetch(). I also
added/fixed tiny pieces in my previous work here and there.
===
RCS file: /home/cvspublic/modperl/lib/Apache/test.pm,v
retrieving revision 1.17
diff -u -r1.17 test.pm
--- lib/Apache/test.pm 2000/09/28 21:16:13 1.17
+++ lib/Apache/test.pm 2000/10/02 05:38:43
@@ -57,7 +57,7 @@
User $args{user}
Group $args{group}
ServerName localhost
-DocumentRoot $DIR/t/eg
+DocumentRoot $DIR/t
$args{modules}
@@ -73,7 +73,10 @@
AddType text/html .html
# Look in ./blib/lib
-PerlModule ExtUtils::testlib
+#PerlModule ExtUtils::testlib
+
+ use lib "$DIR/blib/lib", "$DIR/t/lib";
+
$args{include}
EOF
@@ -82,6 +85,7 @@
}
sub _ask {
+# Just a function for asking the user questions
my ($prompt, $default, $mustfind) = @_;
my $response;
@@ -193,8 +197,8 @@
}
}
-
sub test {
+shift() if UNIVERSAL::isa($_[0], __PACKAGE__);
my $s = $_[1] ? "ok $_[0]\n" : "not ok $_[0]\n";
if($ENV{MOD_PERL}) {
Apache->request->print($s);
@@ -205,21 +209,26 @@
}
sub fetch {
-my($ua, $url);
-if(@_ == 1) {
- $url = shift;
- $ua = $UA;
-}
-else {
- ($ua, $url) = @_;
-}
-unless ($url =~ /^http/) {
- $url = "http://$net::httpserver${url}";
-}
+# Old code calls fetch() as a function, new code as a method
+shift() if UNIVERSAL::isa($_[0], __PACKAGE__);
+my ($ua, $url) = (@_ == 1 ? ($UA, shift()) : @_);
+my $request = ref $url ? $url : {uri=>$url};
+
+# Set some defaults
+$ENV{PORT} ||= 8529; # For mod_perl's own tests
+$request->{method} ||= 'GET';
+$request->{content} = '' unless exists $request->{content};
+$request->{uri} = "http://localhost:$ENV{PORT}$request->{uri}"
+ unless $request->{uri} =~ /^http/;
+$request->{headers}{Content_Type} = 'application/x-www-form-urlencoded'
+ if (!$request->{headers} and $request->{method} eq 'POST'); # Is this
+necessary?
+
+# Create & send the request
+$request->{headers} = new HTTP::Headers(%{$request->{headers}||{}});
+my $req = new HTTP::Request(@{$request}{'method','uri','headers','content'});
+my $response = $ua->request($req);
-my $request = new HTTP::Request('GET', $url);
-my $response = $ua->request($request, undef, undef);
-$response->content;
+return wantarray ? ($response->content, $response) : $response->content;
}
sub simple_fetch {
@@ -340,6 +349,7 @@
}
sub MM_test {
+# Writes the test section for the Makefile
shift(); # Don't need package name
my %conf = @_;
@@ -569,9 +579,58 @@
*MY::test = sub { Apache::test->MM_test(%params) };
+=head2 fetch
+
+ Apache::test->fetch($request);
+ Apache::test->fetch($user_agent, $request);
+
+Call this method in a test script in order to fetch a page from the
+running web server. If you pass two arguments, the first should be an
+LWP::UserAgent object, and the second should specify the request to
+make of the server. If you only pass one argument, it specifies the
+request to make.
+
+The request can be specified either by a simple string indicating the
+URI to fetch, or by a hash reference, which gives you more control
+over the request. The following keys are recognized in the hash:
+
+=over 4
+
+=item * uri
+
+The URI to fetch from the server. If the URI does not begin with
+"http", we prepend "http://localhost:$PORT" so that we make requests
+of the test server.
+
+=item * method
+
+The request method to use. Default is 'GET'.
+
+=item * content
+
+The request content body. Typically used to simulate HTML fill-out
+form submission for POST requests. Default is null.
+
+=item * headers
+
+A hash of headers you want s
Re: Patch for easy testing of Apache::* modules (resend)
On Mon, 2 Oct 2000, Ken Williams wrote:
> In looking over the changes, I found that I've done a little more work
> since the last patch I sent. I didn't send it on because I wasn't sure
> whether the first patch would be accepted or not. Anyway, I beefed up
> the fetch() method and documented it. It's fully backward compatible,
> so no changes are necessary to existing code that calls fetch(). I also
> added/fixed tiny pieces in my previous work here and there.
thanks ken, i applied this patch, but it broke modules/cgi 3-4,7, because
it calls fetch() in an array context. i applied the bandaid below to get
by for now. maybe it would be better for your more robust version of
fetch() to be called get(), and the old fetch() becomes a wrapper around
that?
Index: lib/Apache/test.pm
===
RCS file: /home/cvs/modperl/lib/Apache/test.pm,v
retrieving revision 1.18
diff -u -r1.18 test.pm
--- lib/Apache/test.pm 2000/10/02 20:25:13 1.18
+++ lib/Apache/test.pm 2000/10/02 21:05:29
@@ -210,7 +210,8 @@
sub fetch {
# Old code calls fetch() as a function, new code as a method
-shift() if UNIVERSAL::isa($_[0], __PACKAGE__);
+my $want_response;
+$want_response = shift() if UNIVERSAL::isa($_[0], __PACKAGE__);
my ($ua, $url) = (@_ == 1 ? ($UA, shift()) : @_);
my $request = ref $url ? $url : {uri=>$url};
@@ -228,7 +229,7 @@
my $req = new HTTP::Request(@{$request}{'method','uri','headers','content'});
my $response = $ua->request($req);
-return wantarray ? ($response->content, $response) : $response->content;
+return $want_response ? $response : $response->content;
}
sub simple_fetch {
Re: Patch for easy testing of Apache::* modules (resend)
On Mon, 2 Oct 2000, Ken Williams wrote:
ken, i have a feature request too :) i would like to be able to test if
mod_include is linked static with httpd, otherwise Makefile.PL will
disable PERL_SSI. a hash of parsed `httpd -l`, something like:
my $static_modules = Apache::test->http_static_modules;
if ($static_modules->{mod_include}) {
...
}
thanks!
Re: Patch for easy testing of Apache::* modules (resend)
[EMAIL PROTECTED] (Doug MacEachern) wrote:
>ken, i have a feature request too :) i would like to be able to test if
>mod_include is linked static with httpd, otherwise Makefile.PL will
>disable PERL_SSI. a hash of parsed `httpd -l`, something like:
>
>my $static_modules = Apache::test->http_static_modules;
>
>if ($static_modules->{mod_include}) {
>...
>}
Okey dokey Doug, here's a patch. I cleaned up _read_existing_conf()
too because it was pretty hard to understand.
===
RCS file: /home/cvspublic/modperl/lib/Apache/test.pm,v
retrieving revision 1.19
diff -u -r1.19 test.pm
--- test.pm 2000/10/02 21:06:19 1.19
+++ test.pm 2000/10/10 06:47:00
@@ -138,13 +138,12 @@
}
sub _read_existing_conf {
-# Returns some config text
-shift;
-my ($server_conf) = @_;
+# Returns some "(Add|Load)Module" config lines, generated from the
+# existing config file and a few must-have modules.
+my ($self, $server_conf) = @_;
-
open SERVER_CONF, $server_conf or die "Couldn't open $server_conf: $!";
-my @lines = grep {!m/^\s*#/} ;
+my @lines = grep {!m/^\s*\#/} ;
close SERVER_CONF;
my @modules = grep /^\s*(Add|Load)Module/, @lines;
@@ -154,41 +153,47 @@
foreach (@modules) {
s!(\s)([^/\s]\S+/)!$1$server_root/$2!;
}
-
-# Directories where apache DSOs live.
-my (@module_dirs) = map {m,(/\S*/),} @modules;
-
-# Have to make sure that dir, autoindex and perl are loaded.
-my @required = qw(dir autoindex perl);
-my @l = `t/httpd -l`;
-my @compiled_in = map /^\s*(\S+)/, @l[1..@l-2];
+my $static_mods = $self->static_modules('t/httpd');
my @load;
-foreach my $module (@required) {
- if (!grep /$module/i, @compiled_in, @modules) {
+# Have to make sure that dir, autoindex and perl are loaded.
+foreach my $module (qw(dir autoindex perl)) {
+ unless ($static_mods->{"mod_$module"} or grep /$module/i, @modules) {
+ warn "Will attempt to load mod_$module dynamically.\n";
push @load, $module;
}
}
+# Directories where apache DSOs live.
+ my @module_dirs = map {m,(/\S*/),} @modules;
+
# Finally compute the directives to load modules that need to be loaded.
MODULE:
foreach my $module (@load) {
foreach my $module_dir (@module_dirs) {
- if (-e "$module_dir/mod_$module.so") {
- push @modules, "LoadModule ${module}_module
$module_dir/mod_$module.so\n"; next MODULE;
- } elsif (-e "$module_dir/lib$module.so") {
- push @modules, "LoadModule ${module}_module
$module_dir/lib$module.so\n"; next MODULE;
- } elsif (-e "$module_dir/ApacheModule\u$module.dll") {
- push @modules, "LoadModule ${module}_module
$module_dir/ApacheModule\u$module.dll\n"; next
MODULE;
+ foreach my $filename ("mod_$module.so", "lib$module.so",
+"ApacheModule\u$module.dll") {
+ if (-e "$module_dir/$filename") {
+ push @modules, "LoadModule ${module}_module
+$module_dir/$filename\n"; next MODULE;
+ }
}
}
+ warn "Warning: couldn't find anything to load for 'mod_$module'.\n";
}
-
- print "found the following modules: \n@modules";
+
+print "Adding the following dynamic config lines: \n@modules";
return join '', @modules;
}
+sub static_modules {
+# Returns a hashref whose keys are each of the modules compiled
+# statically into the given httpd binary.
+my ($self, $httpd) = @_;
+
+my @l = `$httpd -l`;
+return {map {lc($_) => 1} map /(\S+)\.c/, @l};
+}
+
# Find an executable in the PATH.
sub which {
foreach (map { "$_/$_[0]" } split /:/, $ENV{PATH}) {
@@ -628,6 +633,14 @@
response. In a list context, fetch() returns the content and the
HTTP::Response object itself. This can be handy if you need to check
the response headers, or the HTTP return code, or whatever.
+
+=head2 static_modules
+
+ Example: $mods = Apache::test->static_modules('/path/to/httpd');
+
+This method returns a hashref whose keys are all the modules
+statically compiled into the given httpd binary. The corresponding
+values are all 1.
=head1 EXAMPLES
===
------
Ken Williams Last Bastion of Euclidity
[EMAIL PROTECTED]The Math Forum
Re: Patch for easy testing of Apache::* modules (resend)
On Tue, 10 Oct 2000, Ken Williams wrote:
> [EMAIL PROTECTED] (Doug MacEachern) wrote:
> >ken, i have a feature request too :) i would like to be able to test if
> >mod_include is linked static with httpd, otherwise Makefile.PL will
> >disable PERL_SSI. a hash of parsed `httpd -l`, something like:
> >
> >my $static_modules = Apache::test->http_static_modules;
> >
> >if ($static_modules->{mod_include}) {
> >...
> >}
>
> Okey dokey Doug, here's a patch. I cleaned up _read_existing_conf()
> too because it was pretty hard to understand.
applied, thanks ken!
Probably [OT] Are there any Simple Generic Server modules
Dear All This is a little OT - but bear with me. I am looking for a simple generic server (prefably OO) that I can use for my NON OO stuff. I have writen my own, but I am after ideas One project I've got involves getting HTML (template)files via LWP, and uploads them into an IPC cache for HTML::Template. It needs to accept signals so that Apache can HUP it to go get new templates. Using a generic server class can enable me to get the code out of apache. Any clues welcome. Thanks. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: make problem - mod_perl.h not found by Apache::modules
On Sat, 27 Jan 2001, Lynn Winebarger wrote: > >Hi. I'm having problems getting mod_perl (1.24<_01>) to compile. > I'm using perl 5.6.0, apache 1.3.14, RH Linux 6.2/Intel (with upgrades). > This is odd since I've previously built mod_perl successfully as a DSO > (and the problem appears to be in the configure - I don't get far enough > in the make to be worried about run-time incompatibilies with 1.3.14). > Of course, I don't have the options used in the previous mod_perl build. > WITH_APXS=/usr/local/apache/bin/apxs > USE_APXS=1 > DYNAMIC=1 skip the DYNAMIC=1 option, i don't think it works in combonation with USE_APXS=1
(beginner) Win32 installation / "Writing Apache Modules in Perl & C"
Ref: using Win 98 / Apache 1.3.14 on c:\program files\apache group\apache / Perl 5.6 on c:\perl I'm trying to get a working Win32 installation of mod_perl using "Writing Apache Modules with Perl and C" but, as with most O'Reilly Perl books, it's written for a Unix audience. Apache site doesn't seem to have any Win32 installation notes either. I have ApacheModulePerl.dll located in Apache/modules but the book refers to other modules (Apache::Registry) which come with "the mod_perl distribution". I only found the .dll with the Win32 distribution so do I have to locate these other parts of the distribution elsewhere? The book also refers to perl.conf on several occasions but I can't find any explanation as to where this is located and what relation this bears to httpd.conf which is where I thought all the configuration takes place. Finally, on p.27 the authors say I have to " ... copy the contents of the lib subdirectory into your Perl library tree." Which lib subdirectory and which Perl library tree? What do I copy from and to where? There isn't a lib directory in Apache root. Regards Garry
Any way to make StatINC work for imported modules?
Hi, I'm using mod_perl without the registry, because it seems a bit faster and, well, more elegant. This means, in essence, that the configuration is: PerlInitHandler Apache::StatINC PerlSetEnv PERL5LIB /home/burkhold/perl/local/share/perl/5.6.0 SetHandler 'perl-script' PerlHandler 'Foo::Foo' Now, Foo.pm, containing Foo::Foo is found at the PERL5LIB location specified. If I add: use Bar::Bar to Foo.pm (in the path specified by PERL5LIB above), although Foo.pm is properly reloaded, I get an error that Bar::Bar is not found. It looks like StatINC only attempts to reload files referenced in the initial configuration and files referenced by the initial configuration; anyone know how to make it load new files without restarting the server? Is it a bug? (It seems like a bug). Thanks for any help, //Thomas Thomas K. Burkholder [EMAIL PROTECTED]
Modules `use`d by PerlModule vanishing after startup? (resend)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I didn't get a single response to this the first time around, so I'm resending it. This remains an issue for me. I have recently been working on a framework for moving our applications to mod_perl but I've run into a very odd problem. I load our program's main Apache handler, with: PerlModule IQGroup::IQCoordinator And then set it up as a PerlHandler for a virtual host. But when I attempt to load the program, it fails and throws this into the error log: [Thu Aug 9 14:29:05 2001] [error] Can't locate object method "GetCurrentRequest" via package "IQGroup::Core::ApacheRequest" (perhaps you forgot to load "IQGroup::Core::ApacheRequest"?) at /usr/lib/perl5/5.6.1/IQGroup/IQCoordinator.pm line 60. Except it IS being loaded, it's the first module `use`d by our PerlHandler. A trace on the Apache process even shows the module being read at startup. When I insert Apache::Status and take a look at the symbol table, it shows the IQGroup::Core::ApacheRequest namespace, but with no symbols in it! Even more odd, the modules that it in turn uses DO show up, all symbols intact. Now, if I load the handler in the startup file: use IQGroup::IQCoordinator; then everything loads properly, although I get a slew of "subroutine blah redefined" messages in the error log when it hits the PerlModule directive. This doesn't seem like intended behavior (nothing I read suggests it's supposed to work like this)...so what's eating my module's symbol table? - -- Stephen Clouse <[EMAIL PROTECTED]> Senior Programmer, IQ Coordinator Project Lead The IQ Group, Inc. <http://www.theiqgroup.com/> -BEGIN PGP SIGNATURE- Version: PGP 6.5.8 iQA/AwUBO4bXeAOGqGs0PadnEQLfdACff866KfM7hpQFsTyn5ajB+LxN/MIAnAwK lPpIGKwIlCaWZqL/gNSMkIdM =Fwes -END PGP SIGNATURE-
Re: Problem using Perl Modules under mod_perl / PerlSetVar not working
Hello again,
first, thank you for the support. Your suggestions helped alot and reading
the documentation you pointed me to, caused me to read further at
http://perl.apache.org/preview/modperl-docs/dst_html/docs/1.0/guide/perl.html#Using_Non_Hardcoded_Configuration_Module_Nameswhich
covers exactly the problem I have.
(By the way: there's a typo at line 1 of the startup.pl script:
I think
use Apache:
should be
use Apache;
right?)
But following that guideline resulted in the next problem, I could not yet
solve on my own:
PerlSetVar seems not to work for me! The part of interest in my httpd.conf
looks like this:
Alias /contest /www/u-dev/contest
PerlModule Apache::Registry
PerlModule Apache::DBI
PerlTaintCheck On
PerlSetVar BlaTest BlaVal
SetHandler perl-script
PerlHandler Apache::Registry
PerlRequire /www/u-dev/contest/mod_perl_init.pl
Options ExecCGI
PerlSendHeader Off
allow from all
The mod_perl_init.pl script looks like this:
use Apache;
my $s = Apache->server;
print $s->server_hostname || "Error";
print $s->dir_config('BlaTest') || "Error";
Now what happens at server startup is that the hostname gets printed
correctly, but instead of the value of BlaTest (should be BlaVal) "Error" is
printed.
I use Apache 1.3.20 with mod_perl 1.26 under SuSE-Linux 7.3 with kernel
2.4.10
Any idea what could cause this behavior?
Again: thanks alot
S.Stuckenbrock
> Per Stas Bekman wrote:
>> At 21:12 19.04.2002, Sören Stuckenbrock wrote:
>>
>>> Hi there,
>>>
>>> mod_perl-newbie needs help!
>>> I have a nasty problem using Perl Modules under mod_perl.
>>> I've developed a CGI-Application, that retrieves its configuration
>>> values from a module that gets included (with "use") in every Script
>>> of the application.
>>> So far no problem.
>>>
>>> But when I try to set up more than one instance of the application on
>>> the same (virtual) server under different paths, with different
>>> configuration values in the config-module (which I must do) mod_perl
>>> mixes up the different configuration-modules. Every httpd-child only
>>> loads the configuraion module of the applications instance that it
>>> first served a request for.
>>> If the same process serves a request for a different instance later,
>>> it always uses the config-module of the instance it first served a
>>> request for,
>>> because it thinks it already has loaded the right module.
>>
>>
>> This is because once you use a module (say My::Config), it won't be
>> reloaded as that package name has already been loaded. If your
>> configuration files are different, and in different locations, you
>> should be giving them different names: say My::App1::Config,
>> My::App2::Config, etc. THen you won't have that problem.
>
> For more explanations see this item:
>
http://perl.apache.org/preview/modperl-docs/dst_html/docs/1.0/guide/porting.html#Reloading_Modules_and_Required_Files>
> And Per Einar's suggestion too, but the problem you are having is
> actually explained in the above item. The one below talks about
> different problems, which you want to read as well.
>
>> See
>>
http://perl.apache.org/preview/modperl-docs/dst_html/docs/1.0/guide/porting.html#Writing_Configuration_Files>>
for more information.
>>
>>
>>
>
>
>
> --
>
>
> __ 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
--
netendance GmbH
Sören Stuckenbrock
Fränkische Straße 38
30455 Hannover
Telefon: 49 (0) 511/4733773
Fax: 49 (0) 511/4733776
Mobil : 49 (0) 173/6000319
http://www.netendance.de
RE: Problem using Perl Modules under mod_perl / PerlSetVar not working
>(By the way: there's a typo at line 1 of the startup.pl >script: I think use Apache: should be use Apache; >right?) Good catch! :-) >But following that guideline resulted in the next problem, I >could not yet solve on my own: > >PerlSetVar seems not to work for me! The part of interest in >my httpd.conf looks like this: > >Alias /contest /www/u-dev/contest >PerlModule Apache::Registry >PerlModule Apache::DBI >PerlTaintCheck On > > PerlSetVar BlaTest BlaVal > SetHandler perl-script > PerlHandler Apache::Registry > PerlRequire /www/u-dev/contest/mod_perl_init.pl > Options ExecCGI > PerlSendHeader Off > allow from all > Try putting "PerlSetVar" AFTER "PerlHandler". Jonathan M. Hollin - WYPUG Co-ordinator West Yorkshire Perl User Group http://wypug.pm.org/ http://wypug.digital-word.com/
Re: Problem using Perl Modules under mod_perl / PerlSetVar not working
> PerlSetVar seems not to work for me! The part of interest in my httpd.conf
> looks like this:
>
> Alias /contest /www/u-dev/contest
> PerlModule Apache::Registry
> PerlModule Apache::DBI
> PerlTaintCheck On
>
>PerlSetVar BlaTest BlaVal
>SetHandler perl-script
>PerlHandler Apache::Registry
>PerlRequire /www/u-dev/contest/mod_perl_init.pl
>Options ExecCGI
>PerlSendHeader Off
>allow from all
>
>
> The mod_perl_init.pl script looks like this:
>
> use Apache;
> my $s = Apache->server;
> print $s->server_hostname || "Error";
> print $s->dir_config('BlaTest') || "Error";
>
> Now what happens at server startup is that the hostname gets printed
> correctly, but instead of the value of BlaTest (should be BlaVal) "Error" is
> printed.
>
you can't use $s (the server record) to capture PerlSetVar that exist on a
per-directory basis (within a or block). try
Apache->request->dir_config('BlaTest');
instead. you should use $s->dir_config() for items set on a per-server basis
only, not per-directory.
--Geoff
RE: Problem using Perl Modules under mod_perl / PerlSetVar not working
>>PerlSetVar seems not to work for me! The part of interest in >>my httpd.conf looks like this: >> >>Alias /contest /www/u-dev/contest >>PerlModule Apache::Registry >>PerlModule Apache::DBI >>PerlTaintCheck On >> >> PerlSetVar BlaTest BlaVal >> SetHandler perl-script >> PerlHandler Apache::Registry >> PerlRequire /www/u-dev/contest/mod_perl_init.pl >> Options ExecCGI >> PerlSendHeader Off >> allow from all >> > > Try putting "PerlSetVar" AFTER "PerlHandler". Nope, using: Alias /contest /www/u-dev/contest PerlModule Apache::Registry PerlModule Apache::DBI PerlTaintCheck On SetHandler perl-script PerlHandler Apache::Registry PerlSetVar BlaTest BlaVal PerlRequire /www/u-dev/contest/mod_perl_init.pl Options ExecCGI PerlSendHeader Off allow from all doesn't work any better... Thanks Soeren -- netendance GmbH Sören Stuckenbrock Fränkische Straße 38 30455 Hannover Telefon: 49 (0) 511/4733773 Fax: 49 (0) 511/4733776 Mobil : 49 (0) 173/6000319 http://www.netendance.de
Re: Problem using Perl Modules under mod_perl / PerlSetVar not working
Hello Stas, I have a question regarding your mod_perl documentation. The method you described under: http://perl.apache.org/preview/modperl-docs/dst_html/docs/1.0/guide/perl.html#Using_Non_Hardcoded_Configuration_Module_Names Should this work to differentiate between the Config-Modules of two projects on the same (virtual) server under different s or does this only work for eg. two virtual servers? Using it for different s does not work for me :( Sorry for permanently bugging you Soeren -- netendance GmbH Sören Stuckenbrock Fränkische Straße 38 30455 Hannover Telefon: 49 (0) 511/4733773 Fax: 49 (0) 511/4733776 Mobil : 49 (0) 173/6000319 http://www.netendance.de
Re: Problem using Perl Modules under mod_perl / PerlSetVar not working
Sören Stuckenbrock wrote: > Hello Stas, > > I have a question regarding your mod_perl documentation. > > The method you described under: > >http://perl.apache.org/preview/modperl-docs/dst_html/docs/1.0/guide/perl.html#Using_Non_Hardcoded_Configuration_Module_Names > Should this work to differentiate between the Config-Modules of two projects > on the same (virtual) server under different s or does this only > work for eg. two virtual servers? > Using it for different s does not work for me :( That's correct, see:http://perl.apache.org/preview/modperl-docs/dst_html/docs/1.0/guide/porting.html#Name_collisions_with_Modules_and_libs __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Problem using Perl Modules under mod_perl / PerlSetVar not working
Sören Stuckenbrock wrote: >>>PerlSetVar seems not to work for me! The part of interest in >>>my httpd.conf looks like this: >>> >>> Alias /contest /www/u-dev/contest >>> PerlModule Apache::Registry >>> PerlModule Apache::DBI >>> PerlTaintCheck On >>> >>> PerlSetVar BlaTest BlaVal >>> SetHandler perl-script >>> PerlHandler Apache::Registry >>> PerlRequire /www/u-dev/contest/mod_perl_init.pl >>> Options ExecCGI >>> PerlSendHeader Off >>> allow from all >>> >> >>Try putting "PerlSetVar" AFTER "PerlHandler". > > > Nope, using: > > Alias /contest /www/u-dev/contest > PerlModule Apache::Registry > PerlModule Apache::DBI > PerlTaintCheck On > >SetHandler perl-script >PerlHandler Apache::Registry >PerlSetVar BlaTest BlaVal >PerlRequire /www/u-dev/contest/mod_perl_init.pl >Options ExecCGI >PerlSendHeader Off >allow from all > > > doesn't work any better... As the folks said you need to use $r->dir_config if you want to pull the Location specific value. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Problem using Perl Modules under mod_perl / PerlSetVar not working
>> Nope, using: >> >> Alias /contest /www/u-dev/contest >> PerlModule Apache::Registry >> PerlModule Apache::DBI >> PerlTaintCheck On >> >>SetHandler perl-script >>PerlHandler Apache::Registry >>PerlSetVar BlaTest BlaVal >>PerlRequire /www/u-dev/contest/mod_perl_init.pl >>Options ExecCGI >>PerlSendHeader Off >>allow from all >> >> >> doesn't work any better... > > As the folks said you need to use $r->dir_config if you want to pull > the Location specific value. Does this mean I have to add this to my scripts directly and can't do it at Server-Startup in my startup.pl? Regards Soeren -- netendance GmbH Sören Stuckenbrock Fränkische Straße 38 30455 Hannover Telefon: 49 (0) 511/4733773 Fax: 49 (0) 511/4733776 Mobil : 49 (0) 173/6000319 http://www.netendance.de
Re: Problem using Perl Modules under mod_perl / PerlSetVar not working
Sören Stuckenbrock wrote: >>>Nope, using: >>> >>>Alias /contest /www/u-dev/contest >>>PerlModule Apache::Registry >>>PerlModule Apache::DBI >>>PerlTaintCheck On >>> >>> SetHandler perl-script >>> PerlHandler Apache::Registry >>> PerlSetVar BlaTest BlaVal >>> PerlRequire /www/u-dev/contest/mod_perl_init.pl >>> Options ExecCGI >>> PerlSendHeader Off >>> allow from all >>> >>> >>>doesn't work any better... >> >>As the folks said you need to use $r->dir_config if you want to pull >>the Location specific value. > > > Does this mean I have to add this to my scripts directly and can't do it at > Server-Startup in my startup.pl? Those set in the Location aren't accessible via $s. A simple reason is in the following example: PerlSetVar BlaTest BlaValA PerlSetVar BlaTest BlaValB how $s is supposed to know which one do you want? So if you need to access dir_config at the server startup, you must define PerlSetVar at the top level (or vhost) and access with $s->dir_config() If you define within Location, you can only get to these at the request time. Another possible workaround is to use Perl to create the configuration and in this case you can do whatever you want with the configuration hash that you have created, as you can store and reuse that data at the startup or during the requests, see the configuration chapter in the guide. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Problem using Perl Modules under mod_perl / PerlSetVar not working
At 12:52 22.04.2002, Sören Stuckenbrock wrote:
> >> Nope, using:
> >>
> >> Alias /contest /www/u-dev/contest
> >> PerlModule Apache::Registry
> >> PerlModule Apache::DBI
> >> PerlTaintCheck On
> >>
> >>SetHandler perl-script
> >>PerlHandler Apache::Registry
> >>PerlSetVar BlaTest BlaVal
> >>PerlRequire /www/u-dev/contest/mod_perl_init.pl
> >>Options ExecCGI
> >>PerlSendHeader Off
> >>allow from all
> >>
> >>
> >> doesn't work any better...
> >
> > As the folks said you need to use $r->dir_config if you want to pull
> > the Location specific value.
>
>Does this mean I have to add this to my scripts directly and can't do it at
>Server-Startup in my startup.pl?
Here's what Geoffrey Young said, you seem to have missed it:
> you can't use $s (the server record) to capture PerlSetVar that exist on
a per-directory basis (within a or block). try
> Apache->request->dir_config('BlaTest');
>
> instead. you should use $s->dir_config() for items set on a per-server
basis only, not per-directory.
As far as I understand him, you can use Apache->request inside the
startup.pl script (try it!)
--
Per Einar Ellefsen
[EMAIL PROTECTED]
Re: Problem using Perl Modules under mod_perl / PerlSetVar not working
> Here's what Geoffrey Young said, you seem to have missed it:
>
> > you can't use $s (the server record) to capture PerlSetVar that exist
> on a per-directory basis (within a or block). try
> > Apache->request->dir_config('BlaTest');
> >
> > instead. you should use $s->dir_config() for items set on a
> per-server basis only, not per-directory.
>
> As far as I understand him, you can use Apache->request inside the
> startup.pl script (try it!)
no, you can't use Apache->request from a startup.pl script - I must have
missed the startup.pl requirement in the original post.
but the rest is true, though, and Stas provided more details in a later
post as well. additionally, recipe 17.1 in the cookbook talks about
this exact issue.
HTH
--Geoff
Re: [2.x] Windows interpreter-wide locking due to modules?
On Thu, 16 May 2002, James Luberda wrote:
> I have installed Randy Kobes' 5-10-2002 Apache-2/modperl-2 Win32
> binaries on a Win2k Professional P3 uniprocessor development machine. I
> have left all of the startup.pl script as is. Everything works
> great--however, with some scripts I seem to still suffer from 1.3-style
> locks on the perl interpeter that prevent some other scripts from being
> served until a given dynamic request completes. I've poked around a bit
> and found that simple scripts (ones not using modules) will still be
> executed while another long-running process is executing (thus
> multithreading properly)--so I'm figuring it's probably a module issue
> (or I'm simply confused). The two modules I'm running predominantly are
> DBI 1.14 (with DBD::DB2 .74) and CGI 2.74, and I have verified that two
> scripts running simultaneously with these two modules will result in one
> blocking until the other completes.
>
> Any/all ideas most welcome--and my sincerest thanks to Randy for his 1.3
> and 2.0 binaries and other incredibly helpful docs/builds/info/etc.
Thanks :) ... Is this a registry script you're finding the
blocking with, or within your own custom handler? I just tried
the following script (Win2000, ActivePerl 631):
===
use strict;
use DBI;
use CGI qw(:all);
print header, start_html, h3('TEST'), '';
my $dbh = DBI->connect('DBI:mysql:what', 'user', 'passwd',
{RaiseError => 1, PrintError => 1});
my $query = "SELECT x FROM y WHERE z LIKE 'ABC%'";
my $sth = $dbh->prepare($query);
$sth->execute;
while (my $name = $sth->fetchrow_array) {
print "$name\n";
}
$sth->finish;
sleep(10);
print "", end_html;
===
under ModPerl::Registry, with the following directives:
===
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
Options +ExecCGI
PerlOptions +GlobalRequest
PerlOptions +ParseHeaders
===
and didn't see any blocking ... Does an equivalent of the above
work for you?
If not, you might try the most recent Apache2 stuff (May 13) -
Doug made a whole bunch of enhancements to the Win32 side of
mod_perl-2 recently, and perhaps one of those is related to this.
Are you using Apache::DBI? If so, try disabling it and seeing
if that helps.
best regards,
randy
Re: Apache::DBI and CGI::Application with lots of modules.
I'm just going to point out a few problems. These are not all related
to your questions.
>package Holds;
>
The case of "Holds" doesn't match the example sub you posted above. I'm
assuming that was a typo.
>use strict;
>use Carp;
>use warnings;
>use QueryPrint;
>use vars qw($dbh $processed_hnd $status_hnd);
>use gentimeid; # generate time id based
>
>
>sub new {
>my $invocant = shift;
>my $class = ref($invocant) || $invocant;
>
That looks like voodoo code copied from a man page. If you call this as
Holds->new(), you don't need that junk about ref. (And most people
recommend against the "new Holds" syntax.)
>my $self = { @_ };
>bless ($self, $class);
>$dbh = db_connect();
>
You don't seem to need this. You aren't using the database handle for
anything in this sub and you aren't gaining anything by calling it here.
>sub GetProcessed {
>
>my $self = shift;
>
> This has a bug, somtimes the cached query doesn't stick around.
>
If you lose your database connection, Apache::DBI will reconnect. Any
prepared queries will be lost. You *must* prepare every time, but see
below...
>sub db_connect {
>
>require DBI;
>
You don't need that. You should have already loaded it in startup.pl.
>my $dbname = 'CS';
>my ($dbuser, $dbpasswd) = ('myuser', 'mypass');
>
Probably should be in a config file, rather than buried in here.
>my $dbh = DBI->connect("DBI:mysql:$dbname", $dbuser, $dbpasswd)
> or die "can't connect: $DBI::errstr\n";
>
> # we need these waiting for queries, so we are going to prepare them ahead of
> time, and yes
> # horror of horror they will be global. Sorry Mom I tried :(
> $processed_hnd = $dbh->prepare_cached("select ord_tpak_processed from orders
>where ord_num=?") or confess("can't get tpak processed");
> $status_hnd = $dbh->prepare_cached("select is_hold_set,holdstate from
>holds where ord_num=?") or confess("can't get hold status");
> #DBI->trace(2,"/usr/local/apache/htdocs/out.log");
> return $dbh;
>
Don't put those in globals. The prepare_cached call already stores them
for the life of your database connection. Apache::DBI will keep that
connection alive (in a global hash) as long as it can and reconnect if
the connection is lost. If the connection does get lost, the statement
handles in these globals will stop working. You do recreate them every
time since you call this sub every time, but you could lose the
connection between the time this sub is called and the time you use
these handles.
> 2. Every once in a while I get an out of memory error.
>
You can control process growth over time in a number of ways. They are
documented in the mod_perl guide.
>3. My main search result page is getting cached, the closure type of
>problem.
>
Are you using any modules that have subs with sub ref prototypes, like
Error.pm? That can do it.
>All I have read says that because I am using oop
>modules and use strict along with use vars that should not happen.
>
It's actually really easy to create closures. Here is a closure:
my $holdtype = $q->param('holdstate');
display_holdtype();
sub display_holdtype {
print "holdtype: $holdtype in process $$\n";
}
This will always print whatever the value was the first time, no matter
what you change it to later. (The first time for that process, that
is.) Watch out for things like that. You should always pass params
explicitly.
>4. I know the way I have done these db connects is sloppy. But I can't seem
>to find a better way. Could I make one db_connect sub,and inherite it all
>though my modules?
>
Make one sub that returns a database handle and use it from everywhere.
Doesn't need to be inherited, you can just stick it in a module that
all the other modules call.
Hope some of that was helpful,
Perrin
Re: Apache::DBI and CGI::Application with lots of modules.
Perrin, I am going to read over this closely, thanks for all of the advice! What frustrats me about the search getting cached/closure thing is that I just don't have any global variables that have anything to do at all with the search results. I have read over and over examples with closures, recognize the example you included as one, but I still can't seem to find it in my own code. I guess I need to take a fresh look again. I did -X httpd and it is happening every time. I think part of what is getting me is I have used mod_perl for smaller things, but now it is a pretty big system. I don't seem to be able to get away with as much :) Also, I am really trying to bring my code level up a notch, but as you pointed out, there are some things I am doing that I don't really understand well enough yet. Thanks, Eric http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone) "Inquiry is fatal to certainty." -- Will Durant
Re: Apache::DBI and CGI::Application with lots of modules.
Hi,
Here is the kind of thing that is driving me nuts. Please see:
http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Remed
ies_for_Inner_Subroutines
If what this says is true, then either I don't have a closure type problem,
or else what is says isn't true. It says that
if I have this situation, I will get a warning. I am not getting any
warnings, but I am getting this behaviour with my search queries "getting stuck"
The only thing I do is again, copied from the perltoot
package Searches;
use strict;
use Carp;
use vars qw($dbh);
use gentimeid; # generate time id based
use Calc_Price; # get totals
use warnings;
# use DBIx::XHTML_Table; # maybe later
use QueryPrint;
#use Data::Dumper;
# These searches are restricted to user level searches, there will be a
admin level search for
# managment reports
$dbh = db_connect();
# requires a $q query object to be init.
sub new {
my $self = {};
my $proto = shift;
my $class = ref($proto) || $proto;
$self->{queryobject} = undef;
$self->{isDomestic} = undef;
$self->{isInternational} = undef;
$self->{isShippingSame} = undef;
$self->{CustIsInserted} = undef;
$self->{OrderIsInserted} = undef;
$self->{CustNum} = undef;
$self->{OrderNum} = undef;
bless ($self, $class);
return $self;
}
sub queryobject {
my $self = shift;
if (@_) { $self->{queryobject} = shift }
return $self->{queryobject};
}
Other stuff not used yet
sub LookupOrder {
my $self = shift;
my $q = $self->{queryobject};
my $output = '';
my $hasparameter = 0;
... Build a query from CGI.pm vars passed in though queryobject
...
$order_name_qu .= " ORDER BY $orderby "; # the query string is here
if ($hasparameter == 1) { # if something was filled in the search form
my $sth = $dbh->prepare($order_name_qu) or confess("Main search
failed $order_name_qu");
$sth->execute() or confess("Main search failed $order_name_qu");
my $headers = $sth->{'NAME'};
my @rows= $sth->fetchall_arrayref();
my $resulthtml = new QueryPrint(ResultSet => @rows,
Action => 'customer',
ColumnList => $headers);
my $html = $resulthtml->SetAction(); # sets a template type in the
QueryPrint module
$output = $resulthtml->QueryPrint();
$sth->finish();
#warn "QUERY - $order_name_qu";
undef @rows;
undef $resulthtml;
undef $order_name_qu;
return $output;
} else {
return "no query to do";
}
Then this is all called from my CGI::Application module
sub customer_display{
my $self = shift;
my $q = $self->query();
my $customersearch = new Searches();
$customersearch->queryobject($q); # set the query
my $header = parse_header($self);
return $header . $customersearch->LookupCustName();
}
So going nuts now, where is the problem? My QueryPrint module is pretty
much the same, so if this is ok, it should be as well.
Thanks,
Eric
>Are you using any modules that have subs with sub ref prototypes, like
>Error.pm? That can do it.
>
>>All I have read says that because I am using oop
>>modules and use strict along with use vars that should not happen.
>>
>
>It's actually really easy to create closures. Here is a closure:
>
>my $holdtype = $q->param('holdstate');
>display_holdtype();
>
>sub display_holdtype {
>print "holdtype: $holdtype in process $$\n";
>}
>
>This will always print whatever the value was the first time, no matter
>what you change it to later. (The first time for that process, that
>is.) Watch out for things like that. You should always pass params
>explicitly.
>
>>4. I know the way I have done these db connects is sloppy. But I can't seem
>>to find a better way. Could I make one db_connect sub,and inherite it all
>>though my modules?
>>
>
>Make one sub that returns a database handle and use it from everywhere.
> Doesn't need to be inherited, you can just stick it in a module that
>all the other modules call.
>
>Hope some of that was helpful,
>Perrin
>
(250) 655 - 9513 (PST Time Zone)
"Inquiry is fatal to certainty." -- Will Durant
Re: Apache::DBI and CGI::Application with lots of modules.
Eric Frazier wrote: > Here is the kind of thing that is driving me nuts. Please see: > http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Remed > ies_for_Inner_Subroutines > > If what this says is true, then either I don't have a closure type problem, > or else what is says isn't true. That documentation refers to one particular problem involving nested subs. You don't need to have nested subs to have closures, and closures may not even be the problem. You need to do some debugging. Narrow things down by verifying your assumptions one by one. Is CGI.pm really giving you the values you expect? (Some people have experienced issues with params not being reset when using CGI.pm in certain ways.) Is your SQL query being built correctly each time? Is the data that you're passing to the template correct? Throw in some warn statements. Run it in the debugger if you need to. - Perrin
Re: Apache::DBI and CGI::Application with lots of modules.
At 11:58 AM 10/14/02 -0400, Perrin Harkins wrote: >Eric Frazier wrote: >> Here is the kind of thing that is driving me nuts. Please see: >> http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Remed >> ies_for_Inner_Subroutines >> >> If what this says is true, then either I don't have a closure type problem, >> or else what is says isn't true. > >That documentation refers to one particular problem involving nested >subs. You don't need to have nested subs to have closures, and closures >may not even be the problem. > >You need to do some debugging. Narrow things down by verifying your >assumptions one by one. Is CGI.pm really giving you the values you >expect? (Some people have experienced issues with params not being >reset when using CGI.pm in certain ways.) Is your SQL query being built >correctly each time? I have checked the above, and I have lots of warns spaced around so I can watch things in the error log. Is the data that you're passing to the template >correct? That I am not so sure of. I will do some more investigation. It seems like the only variables that could be causing this are the result set from the query and the scalar which holds the html template. I feel like I know absolutly nothing now :( I installed Apache::DB but don't yet know what to make of it. Thanks again, Eric Throw in some warn statements. Run it in the debugger if you >need to. > >- Perrin > (250) 655 - 9513 (PST Time Zone) "Inquiry is fatal to certainty." -- Will Durant
Re: Apache::DBI and CGI::Application with lots of modules.
Perrin,
I am starting to feel guilty about bugging you so much, but you are the only
person to have responded, and I watch the list enough to value your advice
quite a bit.
>>sub new {
>>my $invocant = shift;
>>my $class = ref($invocant) || $invocant;
>>
>
>That looks like voodoo code copied from a man page. If you call this as
>Holds->new(), you don't need that junk about ref. (And most people
>recommend against the "new Holds" syntax.)
>
>>my $self = { @_ };
>>bless ($self, $class);
>>$dbh = db_connect();
>>
>
>You don't seem to need this. You aren't using the database handle for
>anything in this sub and you aren't gaining anything by calling it here.
I wanted the DBH to be global since just about every sub in Holds does a
query of some sort. I guess it doesn't matter either way if I do the connect
in the new() vs up top outside of a sub.
What is the problem with the my $holdcheck = new Holds() type of syntax?
I never read anything about that either way.
>
>>sub GetProcessed {
>>
>>my $self = shift;
>>
>> This has a bug, somtimes the cached query doesn't stick around.
>>
>
>If you lose your database connection, Apache::DBI will reconnect. Any
>prepared queries will be lost. You *must* prepare every time, but see
>below...
>
>>sub db_connect {
>>
>>require DBI;
>>
>
>You don't need that. You should have already loaded it in startup.pl.
>
>>my $dbname = 'CS';
>>my ($dbuser, $dbpasswd) = ('myuser', 'mypass');
>>
>
>Probably should be in a config file, rather than buried in here.
>
>>my $dbh = DBI->connect("DBI:mysql:$dbname", $dbuser, $dbpasswd)
>> or die "can't connect: $DBI::errstr\n";
>>
>> # we need these waiting for queries, so we are going to prepare them
ahead of
>> time, and yes
>> # horror of horror they will be global. Sorry Mom I tried :(
>> $processed_hnd = $dbh->prepare_cached("select ord_tpak_processed from
orders
>>where ord_num=?") or confess("can't get tpak processed");
>> $status_hnd = $dbh->prepare_cached("select is_hold_set,holdstate from
>>holds where ord_num=?") or confess("can't get hold status");
>> #DBI->trace(2,"/usr/local/apache/htdocs/out.log");
>> return $dbh;
>>
>
>Don't put those in globals. The prepare_cached call already stores them
>for the life of your database connection. Apache::DBI will keep that
>connection alive (in a global hash) as long as it can and reconnect if
>the connection is lost. If the connection does get lost, the statement
>handles in these globals will stop working. You do recreate them every
>time since you call this sub every time, but you could lose the
>connection between the time this sub is called and the time you use
>these handles.
>
I did this, I was a little scared about calling $dbh->finish() but I did
what you said, and yes life is good I don't notice a speed difference.
>>4. I know the way I have done these db connects is sloppy. But I can't seem
>>to find a better way. Could I make one db_connect sub,and inherite it all
>>though my modules?
>>
>
>Make one sub that returns a database handle and use it from everywhere.
> Doesn't need to be inherited, you can just stick it in a module that
>all the other modules call.
I have no idea why I put off doing that for so long. But that is done now as
well.
>
>Hope some of that was helpful,
>Perrin
>
(250) 655 - 9513 (PST Time Zone)
"Inquiry is fatal to certainty." -- Will Durant
Re: Apache::DBI and CGI::Application with lots of modules.
Eric Frazier wrote: > I wanted the DBH to be global since just about every sub in Holds does a > query of some sort. Three options: 1) Pass it to every sub 2) Make a utility sub that returns a dbh and call it from each sub. (Sounds like you already made one of these.) 3) Stuff it in $r->pnotes(), where it will get cleaned up after each request. > What is the problem with the my $holdcheck = new Holds() type of syntax? > I never read anything about that either way. It's been discussed quite a bit in various places. It is now documented in the perlobj man page: http://perldoc.com/perl5.8.0/pod/perlobj.html#Indirect-Object-Syntax - Perrin
Re: Apache::DBI and CGI::Application with lots of modules.
On Mon, 14 Oct 2002, Eric Frazier wrote:
> >That looks like voodoo code copied from a man page. If you call this as
> >Holds->new(), you don't need that junk about ref. (And most people
> >recommend against the "new Holds" syntax.)
>
> I wanted the DBH to be global since just about every sub in Holds does a
> query of some sort. I guess it doesn't matter either way if I do the connect
> in the new() vs up top outside of a sub.
Boredom break:
As for your dbh, stick it whereever its scope applies, however I don't
like declaring globals, so I've found that if I make the dbh accessible
via an object, usually together with Apache::DBI in the background, I can
often do clean up stuff, such as closing the handle (incase Apache::DBI
isn't in place with a particular invokation of the package), last system
logging updates/inserts, or whatever the job requires in a DESTROY method.
> What is the problem with the my $holdcheck = new Holds() type of syntax?
> I never read anything about that either way.
It's in the book which I think should be called, 'the guy in the silly hat
book,' ie. Damien's OO book, pretty much saying that,
"The indirect object syntax does, however, suffer from the same type of
ambiguity problems that sometime befuddles print
my $cd3 = new get_classname() (@data) #Compilation Error
...
Assuming you have $cd="MyPackage" and:
get_name $cd;
This is usually equivalent to:
$cd->get_name;
However, let's say that you have a method in the invoking script
named 'get_name', then:
get_name $cd;
Gets interpreted as:
get_name("MyPackage")
Which is not what you're after.
" - from the guy in the silly hat book
--
Senior Programmer
Bookings.nl
--
Me::[EMAIL PROTECTED]||www.dreamthought.com
Budget hosting on my 10Mbit/backbone::[EMAIL PROTECTED]
RE: Apache::DBI and CGI::Application with lots of modules.
Hey Eric --
> I wanted the DBH to be global since just about every sub in Holds does a
> query of some sort. I guess it doesn't matter either way if I do
> the connect
> in the new() vs up top outside of a sub.
CGI::Application has a facility which is intended to solve exactly this type
of problem -- the param() method. The param() method allows you to stash a
property (such as a $dbh) in your CGI::Application-based object which can be
retrieved anywhere. I typically connect to the database in my setup()
method and stash my $dbh for use later:
package My::WebApp;
use strict;
use base qw/CGI::Application/;
sub setup {
my $self = shift;
$self->start_mode('start');
$self->run_modes(
'start' => 'run_mode_method'
);
my $dbh = $self->connect_to_database();
$self->param('DBH', $dbh);
}
sub run_mode_method {
my $self = shift;
# Get database handle
my $dbh = $self->param('DBH');
my $output = '';
# ...etc
return $output;
}
Furthermore, in order to disconnect, the teardown() method may be used:
sub teardown {
my $self = shift;
# Get database handle
my $dbh = $self->param('DBH');
$dbh->disconnect();
}
Refer to the CGI::Application POD for details on teardown() and param().
Regarding connecting to the database, I also urge you to encapsulate your
connection code. On my projects I always get things started by creating a
Perl module which I use whenever I need a database connection:
package My::DatabaseCreds;
use DBI;
sub new_dbh {
my $dbh = DBI->connect()
die ("Can't connect: ".$DBI::errstr) unless ($dbh);
return $dbh;
}
(This isn't exactly the code I use -- I actually have a module which I
sub-class, but you get the idea.)
The benefit of creating a module is that (1) all your Perl code can use this
module so that (2) should it ever have to change you can change it in one
place.
> What is the problem with the my $holdcheck = new Holds() type of syntax?
> I never read anything about that either way.
My guess is that Perrin was referring to your use of the "indirect"
notation, as opposed to the "arrow" notation:
Indirect:
my $holdcheck = new Holds()
Arrow:
my $holdcheck = Holds->new()
Many people (myself included) prefer the arrow notation. In general, the
arrow notation tends to be less ambiguous, particularly when it comes to
combining method calls with arguments.
HTH,
-Jesse-
--
Jesse Erlbaum
The Erlbaum Group
[EMAIL PROTECTED]
Phone: 212-684-6161
Fax: 212-684-6226
Re: Apache::DBI and CGI::Application with lots of modules.
Hi,
I had to read that over a few times to get it. And now I see that I do
indeed have that situation, there are a number of times when I call
my $holdstatus = new Holds(); from within a module that also has a new
method. What I don't understand is how does my code work at all?
Thanks,
Eric
At 07:13 PM 10/14/02 +0200, Rafiq Ismail wrote:
>On Mon, 14 Oct 2002, Eric Frazier wrote:
>> >That looks like voodoo code copied from a man page. If you call this as
>> >Holds->new(), you don't need that junk about ref. (And most people
>> >recommend against the "new Holds" syntax.)
>>
>> I wanted the DBH to be global since just about every sub in Holds does a
>> query of some sort. I guess it doesn't matter either way if I do the connect
>> in the new() vs up top outside of a sub.
>
>Boredom break:
>
>As for your dbh, stick it whereever its scope applies, however I don't
>like declaring globals, so I've found that if I make the dbh accessible
>via an object, usually together with Apache::DBI in the background, I can
>often do clean up stuff, such as closing the handle (incase Apache::DBI
>isn't in place with a particular invokation of the package), last system
>logging updates/inserts, or whatever the job requires in a DESTROY method.
>
>> What is the problem with the my $holdcheck = new Holds() type of syntax?
>> I never read anything about that either way.
>It's in the book which I think should be called, 'the guy in the silly hat
>book,' ie. Damien's OO book, pretty much saying that,
>
>"The indirect object syntax does, however, suffer from the same type of
>ambiguity problems that sometime befuddles print
>
> my $cd3 = new get_classname() (@data) #Compilation Error
>
>...
>
>
> Assuming you have $cd="MyPackage" and:
> get_name $cd;
>
> This is usually equivalent to:
> $cd->get_name;
>
> However, let's say that you have a method in the invoking script
>named 'get_name', then:
>
> get_name $cd;
>
> Gets interpreted as:
>
> get_name("MyPackage")
>
> Which is not what you're after.
>
>" - from the guy in the silly hat book
>
>--
>Senior Programmer
>Bookings.nl
>--
>Me::[EMAIL PROTECTED]||www.dreamthought.com
>Budget hosting on my 10Mbit/backbone::[EMAIL PROTECTED]
>
>
(250) 655 - 9513 (PST Time Zone)
"Inquiry is fatal to certainty." -- Will Durant
Handler Access to vars created by other modules. (modperl 2.0)
Hi, I am creating a handler that logs key (request) variables passed from our client application. I need to tie the entries I create to entries in the apache request log. I was thinking that I could use the UNIQUE_ID created by mod_unique_id (i.e. stick it in access_log and the log generated by my handler and use the UNIQUE_ID's to correlate the log entries). I am having difficulty accessing this variable (via the ENV hash). I decided to make it a PerlLogHandler and register it REALLY_LAST, thinking that mod_unique_id would've exported UNIQUE_ID prior to that. However, that does not seem to be the case :) Any suggestions? Thanks In Advance, Erich
Re: [mp2.0] How do I port modules using Apache::SIG?
Clare, Bruce W wrote:
I'm attempting to run Scoop 0.9 (scoop.kuro5hin.org) under Apache2/mod_perl
2.0 running on Windows 2000, but the application was written for Apache/mp
1.x, so it uses Apache::SIG (and possibly other) modules that are no longer
in mod_perl.
The mod_perl developer documentation for porting from 1.x to 2.x doesn't
really cover the missing modules, other than to say you can use
Apache::compat to allow use of deprecated methods. This doesn't do the job
here, which makes sense because the SIG module isn't even installed on my
system. Is there any resource that discusses the changes between mod_perl
1.x and 2.x in more detail than the current developer document? The key
point here is what has been deprecated/removed/rearchitected in mod_perl
2.x? and how do I replace it?
The changes are documented here:
http://perl.apache.org/docs/2.0/user/compat/compat.html
I haven't put it into the developer's guide, but the user's guide.
Because the user's guide is for all people who write mod_perl code. The
developer's guide is for those who tinker with the core. I'll put an
xref to the above doc to avoid this problem in the fuure.
Apache::compat is certainly incomplete, as you have just figured out,
and that doc is synced with Apache::compat. But we are getting there.
Please keep reporting those missing things.
I'm not sure if mod_perl 2.0 will ever need this module (especially with
perl 5.8.0 which has safe signals). So here is a stub that let's your
1.0 code run as is. It'll be in CVS soonish.
Index: lib/Apache/compat.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/compat.pm,v
retrieving revision 1.71
diff -u -r1.71 compat.pm
--- lib/Apache/compat.pm23 Nov 2002 22:35:06 - 1.71
+++ lib/Apache/compat.pm4 Dec 2002 02:23:01 -
@@ -509,5 +509,14 @@
APR::Table::make($r->pool, $nelts);
}
+package Apache::SIG;
+
+use Apache::Const -compile => 'DECLINED';
+
+sub handler {
+# don't set the SIGPIPE
+return Apache::DECLINED;
+}
+
1;
__END__
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2.0] How do I port modules using Apache::SIG?
The changes are documented here: http://perl.apache.org/docs/2.0/user/compat/compat.html I haven't put it into the developer's guide, but the user's guide. Because the user's guide is for all people who write mod_perl code. The developer's guide is for those who tinker with the core. I'll put an xref to the above doc to avoid this problem in the fuure. While adding the xrefs I've realized that what I've said is not strictly correct, as http://perl.apache.org/docs/2.0/devel/porting/porting.html includes useful notes for code writers as well. In any case I've added xrefs to each other, so there shouldn't be a problem to find all the relevant info now. The online docs will be updated by the cron within 6 hours. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] Having to reload apache when perl modules change
Richard Curtis wrote: Hi again group. A quick question (but this might not be the right place). If this is the wrong place to ask, please point me in the direction of the right place. you're in the right place, don't worry :) I have a web app written using mod_perl2 and apache::ASP. When I change the code in a perl module, I have to restart apache to make the changes appear to all children. Is there a way of avoiding this - maybe with an apache directive - so that all modules are re-read by all children without a restart ? Apache::Reload ships standard with mod_perl 2.0 and is pretty much the same as with 1.0. See that manpage or docs/api/mod_perl-2.0/Apache/Reload.pod for more details. HTH --Geoff
Re: [mp2] Having to reload apache when perl modules change
Geoffrey Young wrote: Richard Curtis wrote: Hi again group. A quick question (but this might not be the right place). If this is the wrong place to ask, please point me in the direction of the right place. you're in the right place, don't worry :) I have a web app written using mod_perl2 and apache::ASP. When I change the code in a perl module, I have to restart apache to make the changes appear to all children. Is there a way of avoiding this - maybe with an apache directive - so that all modules are re-read by all children without a restart ? Also note the native Apache::ASP configs StatINC and StatINCMatch work too. These can be good as they handle reloading ASP compiled packages smoothly without undefining ASP related symbols. Note that these settings should only be used in development and for reloading code in production a full stop/start should be done. Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
Re: modperl 2.0 problems with Apache::Cookie and related modules.
On Thu, 19 Dec 2002, b. ash wrote: > Hi, > > I am trying to configure a working apache2/modperl2 setup, unfortunately > I can not seemt to get a critical module Apache::Cookie to install, I > keep getting this error. > > Can't locate Apache/MyConfig.pm in @INC (@INC contains: > /usr/local/lib/perl5/5.8.0/i686-linux-thread-multi > /usr/local/lib/perl5/5.8.0 > /usr/local/lib/perl5/site_perl/5.8.0/i686-linux-thread-multi > /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl .) > at Makefile.PL line 27. > BEGIN failed--compilation aborted at Makefile.PL line 27. > > any ideas what might be going on here. Apache::Cookie (and Apache::Request) haven't been ported to mod_perl-2 yet. Until that happens, you can use the mod_perl-2 compatibility mode to do form data, and for cookies, you can use a CPAN module (eg, CGI.pm). -- best regards, randy kobes
RE: modperl 2.0 problems with Apache::Cookie and related modules.
Hi - You may want to check out my experiences w/ap2-mp2 shown in: http://beaucox.com/mason/mason-with-apmp2-mini-HOWTO.htm It shows how I intalled these packages. Aloha => Beau. -Original Message- From: b. ash [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 19, 2002 10:40 AM To: [EMAIL PROTECTED] Subject: modperl 2.0 problems with Apache::Cookie and related modules. Hi, I am trying to configure a working apache2/modperl2 setup, unfortunately I can not seemt to get a critical module Apache::Cookie to install, I keep getting this error. Can't locate Apache/MyConfig.pm in @INC (@INC contains: /usr/local/lib/perl5/5.8.0/i686-linux-thread-multi /usr/local/lib/perl5/5.8.0 /usr/local/lib/perl5/site_perl/5.8.0/i686-linux-thread-multi /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl .) at Makefile.PL line 27. BEGIN failed--compilation aborted at Makefile.PL line 27. any ideas what might be going on here. Thanks --bash
Re: modperl 2.0 problems with Apache::Cookie and related modules.
b. ash wrote: Hi, I am trying to configure a working apache2/modperl2 setup, unfortunately I can not seemt to get a critical module Apache::Cookie to install, I keep getting this error. Can't locate Apache/MyConfig.pm in @INC (@INC contains: /usr/local/lib/perl5/5.8.0/i686-linux-thread-multi /usr/local/lib/perl5/5.8.0 /usr/local/lib/perl5/site_perl/5.8.0/i686-linux-thread-multi /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl .) at Makefile.PL line 27. BEGIN failed--compilation aborted at Makefile.PL line 27. any ideas what might be going on here. A backcompat version of Apache::MyConfig is now available via Apache::compat in the mod_perl cvs. Though it won't solve the Apache::Cookie lib as reported by others. __ 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
performance difference between apache/perl modules and registry scripts question
Dear All I have been asked to code several apache / perl modules. these module accept a "post" consisting of a long string - do a few database things and return a long string to the browser. What are the advantages of using apache / mod_perl modules vs using a registry / mod_perl style CGI script. General memory use / efficiency are an issue and that is why I am being asked to do modules as registry / cgi.pm is seen as"too slow". I would prefer registry / cgi.pm as this is easier to code! (being lazy:-) Any thoughts / experiences would be appreciated Thanks Greg Cope
Re: Problems with dynamically-loaded perl modules under Solaris 2.5.1
Dan Rench wrote: > > I'm having problems with modules that use DynaLoader (Data::Dumper and > Storable, specifically) under mod_perl on Solaris machines. > > These modules work fine in standalone scripts, or when run under mod_cgi > or mod_fastcgi, but as soon as I put a "use Storable" in a mod_perl handler, > I get this in my error log: > > [Tue Oct 26 11:21:33 1999] [error] Can't load >'/usr/local/lib/perl5/site_perl/5.005/sun4-solaris/auto/Storable/Storable.so' for >module Storable: ld.so.1: ./httpd: fatal: relocation error: file >/usr/local/lib/perl5/site_perl/5.005/sun4-solaris/auto/Storable/Storable.so: symbol >main: referenced symbol not found at >/usr/local/lib/perl5/5.00503/sun4-solaris/DynaLoader.pm line 169. > > BTW I get an identical message if I put a "use Storable" inside a > section in my httpd.conf. > > After searching the mailing list archive, I see that this sort of thing can > happen if mod_perl was compiled against the "wrong" version of perl on the > system. So just to make sure, I removed all remnants of an older 5.004 > install, remade mod_perl, and I'm still getting the errors. > > My setup: > > Solaris 2.5.1 (Sparc) > gcc 2.95 > perl 5.005_03 (compiled with above gcc, as were the below) > apache 1.3.9 (with all modules compiled statically) > mod_perl 1.21 (EVERYTHING=1) > mod_fastcgi 2.2.2 > what's the ld version you use ?, make sure you compiled perl using the solaris hints you can find in the perl sources. -- ^-^,-. mailto:[EMAIL PROTECTED] o o )http://www.etsetb.upc.es/~frankie Y (_ (___(
Preloading Modules with mod_perl as a shared object doesn't work!
Okay, I have finally tracked down the source of the problem I am having and would appreciate your suggestions and work-arounds. First, I am using mod_perl; however, like the docs say, I wanted to preload modules, so, I have in my httpd.conf: PerlRequire /startup.pl For a startup.pl I have: use DBI; use Carp; 1; Okay, now I have compiled the Apache 1.3.9 tarball and mod_perl 1.2.1 tarball. If I compile mod_perl as a shared object, and put: LoadModule libexec/libperl.so AddModule... the web server will NOT run. If I comment out the line: # use DBI; it runs perfectly fine. If I compile mod_perl statically into Apache, everything works as advertised. The reason I ran into all of this is because doing: use Apache::DBI; gives the exact same behavior: apachectl tells me that I have successfully launched; however, no processes exist. This is the problem that many have complained about before, and NO!, it is not because the web server is trying to open a db connection. There is nothing at all with opening a db connection yet. Once the web server works, I'll worry about trying to open a db connection. So, how can I preload DBI (or use Apache::DBI for that matter) without having to statically link the libperl.so into the httpd executable? The reason that I cannot link them is that I must use a module with the RedHat secure server I am using. I am running on i386, RH 6.1. I have compiled apache and mod_perl from their respective sources (not using RPM's). Thanks! --Brian
