RE: Apache::DBI in startup.pl generating error
Well, it should be documented somewhere in the guide, or presumable in Apache::DBI.pod, that one should *only* PerlModule Apache::DBI Since it's pointless in startup.pl (right?). I think you need to think that one through a bit more :) I disagree. I *did* think it through. When involving Apache::DBI, one of two situations is true: either you are starting the webserver, or you are changing/testing startup.pl. When starting the webserver, Apache::DBI loads and **transparently** replaces the function of DBI-connect. If one were to NOT load Apache::DBI, everything would work JUST THE SAME (codewise), but we don't see the benefits that Apache::DBI provide. true When messing with startup.pl, Apache::DBI is redundant. Since it's transparent, and only works when RUNNING the httpd, nope - see below it is undesired to have it in startup.pl, since it will only cause errors. I disagree with that - I do it all the time. HOWEVER, loading Apache::DBI as httpd.conf: PerlModule Apache::DBI means that it only loads when it's worth loading, i.e. server startup. If startup.pl then logically contains init code wrapped in a test for whether it's running under mod_perl, within that block becomes a good place for Apache::DBI specific initialization. So... your response indicates you think I missed something so obvious that I would pick it up on a re-think. Well, this is my original-think... have I really missed something? ok, at least you're thinking :) the two things I had in mind were: a) generally, you ought to pre-load all your modules in startup.pl so that you get the maximum amount of code-sharing/memory-sharing, etc. b) you couldn't call Apache::DBI-connect_on_init; without first use Apache::DBI; Except that (and I have to check this to be ABSOLUTELY shure but) PerlModule Apache::DBI happens first, THEN startup.pl. I just checked, and it works exactly that way when the httpd.conf directives are in the following order: PerlModule Apache::DBI PerlRequire /etc/httpd/perl/lib/startup.pl Since Apache::DBI is now loaded into the (single) perl interpreter's symbol table, and since the above call to connect_on_init() is a method call (vs an exported symbol), calling methods on it are valid, and can be easily wrapped as I suggested in an if($ENV{MOD_PERL}) {} block. Explicitly, it is *NOT* required to 'use Apache::DBI ();' in startup.pl to do this. your *only* up top I thought was a bit strong, which was why I was trying to encourage deeper thought... for the most part, though, you get Apache::DBI, which is more than be said for most... I hope you found it constructive criticism and not condescending - you seem like a person who wants to understand :) Absolutely... I'm on this list to edify and to be edified. L8r, Rob #!/usr/bin/perl -w use Disclaimer qw/:standard/;
Re: Apache::DBI in startup.pl generating error
Alternatively, you can remove use Apache; from Apache::DBI and then you can test it perflectly fine from the command-line, you just won't be able to use connect_on_init() which is the only reason Apache::DBI seems to load Apache.pm (Apache.pm is causing your problem not Apache::DBI). At 10:20 PM 8/2/2001 +0800, Stas Bekman wrote: On Thu, 2 Aug 2001 [EMAIL PROTECTED] wrote: Thanks to all (esp Stas) for helping me with the 'make test' error involving CGI.pm. Here is the next issue: use Apache::DBI (); When I run perl -c startup.pl, I get the following error. I get NO error when I comment out the 'use Apache::DBI' line: Can't locate object method module via package Apache at /usr/lib/perl5/site_perl/5.005/Apache/DBI.pm line 202. BEGIN failed--compilation aborted at startup.pl line 8. Is there an earlier version of Apache::DBI I should be using (like the CGI.pm error)? It's not a problem. Apache::DBI expects mod_perl env, and hence you cannot test it from the command line. I suppose that you don't have a problem to start the server with Apache::DBI loaded. It's documented somewhere is the guide too. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: [OT] Inspired by closing comments from the UBB thread.
On Thu, 2 Aug 2001, Tim Bunce wrote: I think DBIx::AnyDBD is a pretty good compromise. Well, I worked with Matt on the project for which it was developed (WebBoard for Unix) and I still felt like there was just way too much stuff to deal with. Just too much SQL. I wanted a more abstract way to do things like outer joins, which are different in syntax across multiple platforms. It's definitely better than nothing, but I think for a larger project you'll still end up with a huge amount of very similar SQL statements in your modules. I guess that's why I've been working on Alzabo (though I had actually started that well before working on WBUX). -dave /*== www.urth.org We await the New Sun ==*/
Re: Just while we are so nicely [OT]: SQL Search Results in pages
On Thu, 2 Aug 2001, Perrin Harkins wrote: I've had great success with Select and cache only the row keys, fetch full rows as needed. We were also caching the individual records (in BerkeleyDB), so some pages never needed to hit Oracle at all after the initial query. A good way to go, if your data is not too volatile. This is more or less how Alzabo works (but you can tweak it). When it fetches row objects, its really just fetching primary keys that match your query. As you request other columns they are fetched and cached. You can also specify some columns to be fetched with the primary key and specify that others should be considered a group (when A is fetched, get B C too). Actually, I stole a lot of this from Michael Schwern's Class::DBI and got some more ideas from your talk at ApacheCon, Perrin. So if people are interested in implementing this, they may want to just consider using Alazbo (or you can rip out the caching code and use that separately if you want). -dave /*== www.urth.org We await the New Sun ==*/
RE: Apache::DBI in startup.pl generating error
Except that (and I have to check this to be ABSOLUTELY shure but) PerlModule Apache::DBI happens first, THEN startup.pl. only if you code it the way you did below, which isn't terribly portable. see http://perl.apache.org/guide/perl.html#use_require_do_INC_and basically, it's a bad programming practice not to use() modules in the code that needs them. it works if you call PerlModule before you use() the module, but again, it requires you to pay better attention to your httpd.conf than you ought to. consider writing an Apache module for CPAN, relying on, say, Apache::Log calls, but failing to use Apache::Log in your module. If you have a PerlModule Apache::Log everything works - until somebody else tries to run your code with a different configuration. There's what works and then there's how you ought to do things. I just checked, and it works exactly that way when the httpd.conf directives are in the following order: PerlModule Apache::DBI PerlRequire/etc/httpd/perl/lib/startup.pl Since Apache::DBI is now loaded into the (single) perl interpreter's symbol table, and since the above call to connect_on_init() is a method call (vs an exported symbol), calling methods on it are valid, and can be easily wrapped as I suggested in an if($ENV{MOD_PERL}) {} block. Explicitly, it is *NOT* required to 'use Apache::DBI ();' in startup.pl to do this. this is just a particular gripe of mine, but I think we ought to be past the $ENV{MOD_PERL} thing by now... startup.pl is a mod_perl idiom. if you are designing web applications that depend on things like the mod_perl API, Apache::DBI, and using the hooks into the Apache request cycle then you are already way beyond making a startup.pl script portable between mod_perl and other web environments. --Geoff
Re: dbi abstraction layer on perlmonks
On 02 Aug 2001 14:32:01 -0700, brian moseley wrote: for the next perl conference i'm writing a do everything abstraction layer. it will provide a do_stuff routine that will, out of the box, do your laundry and perform oral sex. scalable, robust, state of the art technology for e-businesses. Ah, the mythical ellipses operator ... :-) yada yada yada -- Matt/ /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Re: dbi abstraction layer on perlmonks
On Thu, Aug 02, 2001 at 02:32:01PM -0700, brian moseley wrote: for the next perl conference i'm writing a do everything abstraction layer. it will provide a do_stuff routine that will, out of the box, do your laundry and perform oral sex. scalable, robust, state of the art technology for e-businesses. Sounds great! But skip the oral sex, ok? I don't know where you've been. Cheers, -- Alastair| [EMAIL PROTECTED] | http://www.calliope.demon.co.uk |PGP Key : A9DE69F8 ---
Re: Just while we are so nicely [OT]: SQL Search Results in pages
On Thu, Aug 02, 2001 at 07:10:49PM +0300, raptor wrote: This may be of interest: http://search.cpan.org/doc/TIMB/DBI_Talk5_2001/sld059.htm ]- Where is $h-{FetchHashKeyName}, I didn't found it even in the source perl -m DBI my version is 1.18 Umm, let's see... that talk was given just a couple of weeks ago, the title of the slide that refers to FetchHashKeyName is What's Planned, and you're using a version released two months ago... As it happens, I made of release of the DBI just before the conference and that release, 1.19, does include $h-{FetchHashKeyName}. Tim.
Re: Just while we are so nicely [OT]: SQL Search Results in pages
On Thursday, August 2, 2001, at 04:07 AM, Joachim Zobel wrote: One of the really nice features of MySQL (OK, its not a real RDBMS, but who cares:) is LIMIT. Using Oracle I have found it a real pain to display search results in pages (of eg 20) while using connection pooling. The problem is that you can not be shure to repeat the same resultset on every page. This gets a real problem if the queries get expensive and I can't afford sorting because it destroys first row performance. Is there a generic soloution to this? Has anybody found this worth writing a pattern? Sure! Just store the results in your session, and display from there... -- -- Tom Mornini -- ICQ 113526784
RE: Apache::DBI in startup.pl generating error
-Original Message- From: Rob Bloodgood [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 02, 2001 9:18 PM To: Geoffrey Young Cc: mod_perl Subject: RE: Apache::DBI in startup.pl generating error basically, it's a bad programming practice not to use() modules in the code that needs them. it works if you call PerlModule before you use() the module, but again, it requires you to pay better attention to your httpd.conf than you ought to. See my above point. Apache::DBI is *made* to be transparent, or at least semi-. It exists at the server level, and without (much) interaction with the programmer's dataspace at all. What better place for it than httpd.conf? And as for having to pay too much attention... well... let's just say that RedCode is spreading like it is because not enough IIS Admins paid better attention to the defaults THEY were given. :-) Seriously tho, why WOULDN'T you know what exactly is in your server configuration? well, I was going to leave this thread alone now, but I feel the need to justify myself on this one issue - I wrote that email a bit bleery-eyed... of course you need to know what your config contains. what I meant was that relying on the PerlModule syntax to allow you to call Apache::DBI-connect_on_init from your startup.pl was less than solid coding - it's the same as not use()ing modules from the scripts that require them (you didn't get that thought from what I wrote? I can't imagine why ;). as for the rest of Apache::DBI you're right, it's transparent so it doesn't matter where you load it - as long as you understand the action-at-a-distance concept, and are comfortable with it, you're ok... anyway, nuff said. Gunther and Ken tied things up nicely. --Geoff
Re: Apache::Reload : eval { require $filename }
On Thu, 2 Aug 2001, Sidharth Malhotra wrote: In the Apache::Reload module, if the 'require' fails, your script bails out, and your client gets status 500. The side effect is that totally unrelated scripts can fail because a bad programmer on another end of the system forgot my a variable. My proposed solution is to put the require inside an eval. Upon failure, simply write to the error log. My Question: If the require is in an eval, what happens when a reload fails? Does the old code in memory stay or or is it removed w/out being replaced by the updated code? Apache::Reload shouldn't be used on production systems. At least in the way you describe. This dissolves the problem. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: dbi abstraction layer on perlmonks
Stas Bekman wrote: Maybe the guide should include links to the most mature peristence abstraction layer projects out there: - Class::DBI - Alzabo - Tangram - SPOPS I suppose that could fit into the help.pod. Otherwise it's not directly related to mod_perl, and the guide has to start shrinking rather than growing. That's fine. The guide has become sort of a catch-all for web site building techniques, and maybe that should be changed in the interest of the maintainer's sanity. I'd also start working on the new docs for mod_perl 2.0, so I can see an extended chapter on databases and persistence layers in the users guide. I vote to cover only the mod_perl specific stuff in there, as you said above. Perrin, would you like to be the database chapter pumpkin? Possibly. We should talk more about what would go into that chapter when you start working on the new guide. - Perrin
Re: dbi abstraction layer on perlmonks
Robert Landrum wrote: The guide is a great thing, and removing items from it is risky. Think of it as refactoring.
Re: segfault with mod_perl, Oraperl, XML::Parser
Thanks everyone for their help, I tried all the suggestions with no luck, and I definitely configured Apache without expat. I finally ended up parsing the XML in perl instead of using Expat. Since I already had handlers, it was quite easy, although still needs better validation and error handling. When I get a chance I'll see if this works on mod_perl 2.0. If anyone does get this to work on Solaris 2.8 x86, please let me know. Thanks, Scott #!./perl use DBD::Oracle; use XML::Parser::Expat; my $parser = new XML::Parser::Expat; $parser-parse('foo id=me here emwe/em go /foo'); # perl-5.6.1 # mod_perl-1.26 # apache 1.3.20 # expat-1.95.1 # DBD-Oracle-1.06 # DBI-1.15 # XML-Parser-2.30 # config_args='-Dcc=gcc -Ubincompat5005 -Uuselargefiles -Uusemymalloc -des' On Tue, July 31 16:37 +0100, Tim Bunce wrote: On Mon, Jul 30, 2001 at 03:30:48PM -0400, Philip Mak wrote: On Mon, 30 Jul 2001, Scott Kister wrote: uselargefiles=define Have you tried turning off uselargefiles? I might be off track here, but recently I tried to install mod_perl on Solaris 5.8. It kept segfaulting until I turned off uselargefiles and binary compatibility with 5.00503. You could try recompiling perl with this configure line, then recompiling mod_perl and see what happens: sh Configure -des -Dcc=gcc -Ubincompat5005 -Uuselargefiles And -Uusemymalloc (or something like that) to get perl to use the system's own malloc. Tim.
Apache::URI problems
I'm seeing this problem both under mod_perl 1.25 and 1.26. I've installed mod_perl as a DSO outside of the Apache source tree using APXS. It seems to work fine, except for Apache::URI. Here's my test script: #!/usr/bin/perl use strict; use Apache::FakeRequest; use Apache::URI; my $req = Apache::FakeRequest-new( 'get_server_name' = 'dev1.aus1.datafoundry.net' ); my $uri = Apache::URI-parse( $req, 'main/test.html' ); print 'URI: ', $uri-unparse(), \n; print 'SCHM: ', $uri-scheme(), \n; print 'PATH: ', $uri-path(), \n; print 'RPTH: ', $uri-rpath(), \n; All I'm doing is some simple testing. The problem is, I'm getting this error: Can't locate object method parse via package Apache::URI (perhaps you forgot to load Apache::URI?) at t1 line 10. Looking at an old install of both perl and mod_perl (which are both not being used or considered), I see that there are actually three related URI files: /usr/local/lib/perl5/site_perl/5.6.0/i86pc-solaris/Apache/URI.pm /usr/local/lib/perl5/site_perl/5.6.0/i86pc-solaris/auto/Apache/URI/URI.bs /usr/local/lib/perl5/site_perl/5.6.0/i86pc-solaris/auto/Apache/URI/URI.so Under the version of perl I'm actually working with, though, only the first exists /usr/local/lib/perl5/site_perl/5.6.1/i86pc-solaris/Apache/URI.pm How come the rest of the code for URI isn't being installed? Did something change at 1.25 to make it unnecessary? Am I doing something wrong? Does parse() not exist as a class method anymore (if so, the docs are out of date)? The perl being used has this configured for @INC: Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under solaris Compiled at May 14 2001 09:09:43 @INC: /usr/local/lib/perl5/5.6.1/i86pc-solaris /usr/local/lib/perl5/5.6.1 /usr/local/lib/perl5/site_perl/5.6.1/i86pc-solaris /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl . Thanks in advance for any assistance, Philip * Philip Molter * Texas.net Internet * http://www.texas.net/ * [EMAIL PROTECTED]
Re: dbi abstraction layer on perlmonks
On Thursday, August 2, 2001, at 03:00 PM, Robert Landrum wrote: Sweet... I was getting kinda tired of my Linux box going down on me. You must be thinking Windows! -- -- Tom Mornini -- ICQ 113526784
Re: segfault with mod_perl, Oraperl, XML::Parser
On 03 Aug 2001 10:26:37 -0700, Scott Kister wrote: Thanks everyone for their help, I tried all the suggestions with no luck, and I definitely configured Apache without expat. I finally ended up parsing the XML in perl instead of using Expat. Since I already had handlers, it was quite easy, although still needs better validation and error handling. Try XML::LibXML. -- Matt/ /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
modules/status make test fail
I can come back with more, if needed, but just in case someone else has seen this: Fresh 1.26 and 1.3.20 Sun Solaris 2.6 Perl 5.005_03 I just did this on Linux and it worked just fine :( This doesn't bother me, too much modules/request.Use of uninitialized value at modules/request.t line 147. Use of uninitialized value at modules/request.t line 147. Use of uninitialized value at modules/request.t line 149. Use of uninitialized value at modules/request.t line 147. Use of uninitialized value at modules/request.t line 147. Use of uninitialized value at modules/request.t line 149. Use of uninitialized value at modules/request.t line 147. Use of uninitialized value at modules/request.t line 147. Use of uninitialized value at modules/request.t line 149. Use of uninitialized value at modules/request.t line 147. Use of uninitialized value at modules/request.t line 147. Use of uninitialized value at modules/request.t line 149. skipping test on this platform modules/src.ok modules/ssi.ok modules/stage...skipping test on this platform But: modules/status..Internal Server Error dubious Test returned status 9 (wstat 2304, 0x900) DIED. FAILED tests 8-10 Failed 3/10 tests, 70.00% okay In error_log: [Fri Aug 3 16:27:16 2001] [error] Can't locate object method inh_tree via package Devel::Symdump at /data/_g/lii/apache/1.26/mod_perl-1.26/blib/lib/Apache/Status.pm line 222, fh1b chunk 1. Do I need an updated Devel::Symdump? Bill Moseley mailto:[EMAIL PROTECTED]
[Fwd: Help with @ISA]
Hello there, I have a problem and I am not sure how to explain it... So please forgive me if I sound like a rookie, since I am that. I have a packge called: my::foo in which I have declared the following: package my::foo; @my::foo::ISA = qw( my::bar ); . . . sub handler { my $r = shift; . . # rest of the code } I have a method called cookie_check in my 'my::bar' package that needs to be called before my controller or 'my::foo' takes over. package my::bar; sub cookie_check { my $self= shift; . . . # rest of the code } I have declared the following in my httpd.conf: Location /foo SetHandler perl-script PerlHandler my::foo-cookie_check() /Location However, I get an error message: Can't locate object method cookie_check() via package my::foo Can anyone tell me what am I doing wrong? Thanks in advance -r
Help needed. LWP-5.48 dicovered..
Hi All, I know all of you are very busy, but could you look at POST request results ( this is print $req-as_string ) : What is the %00H in the last line??? my $resp = $ua-request(POST 'https://www.assist.ru/reports/results.cfm', [ @params ]); my $req = $resp-request; print $req-as_string [ debug | Thu Aug 2 03:50:02 2001 ] POST http://bsadm.yyy.com/banners.xhtml User-Agent: libwww-perl/5.48 Content-Length: 3103 Content-Type: application/x-www-form-urlencoded orderid1=299bannerid1=56title1=AMT%26amp%3BC%20Ltd.body1=%F0%CF%CC%C9%CD% C5%D2%CE%D9%C5%0D%0A%CD%C1%C7%CE%C9%D4%CE% [..] %0D%0A%EB%CF%CE%D3%D5%CC%D8%D4%C1%C3%C9%C9href1=http%3A%2F%2Famtc.org%2Frus %2FSales.htmlphrases1=%CD%C1%C7%CE%A9%00% [.. look at %00] [.. skipped a lot ] %CC%CB%C1%20-%D4%CF%CD%CF%E2%00%00%00H%FC%20- What is the %00H ??? How could it happend??? Is it LWP bug? phrases1 does not contain 'H' chars .. Vlad.
OT: building a server -- advise needed
I have been tasked with re-designing our Sun Server. As it sits right now, it's basically hosed it's a conglomeration of patches, bailing twine, duct tape and whatnot. We are running a Sun Ultra10 with an Ultra SCSI array, Solaris 2.6 the latest Apache, Perl, and JDK. We have installed ModPerl 1.2.5 and various and sundry packages and libraries. Whet I am planning to do is wipe out the drives and start with a fresh install of the OS. It looks as if we will be going with Solaris 8 What I am looking for is advise and recommendations for: Configurations for this server (Sun, Ultra 10, Solaris8 [what else]) New Server (Make, Model, OS, etc) Any other advice you can recommend Thanks in advance for your help. Paul
RE: Apache::DBI in startup.pl generating error
Rob, how much stuff do you have in startup.pl? So nothing else is dependent on Apache.pm modules? To some degree, because Apache::DBI affects all the Perl interpreters in a very config-type of way (as opposed to just preloading modules) I like the idea of it being in PerlModule as it allows some servers to have caching off and some servers to have it on yet still keep the application level startup code in startup.pl. I guess I've always considered startup.pl to be a place for dealing with the various applications you are using and optimizing them by precaching selected modules because you really need to use Perl code if you want to do anything half way complex such as importing namespaces or creating global singletons in a particular package space. Whereas, something simple like Apache::DBI which turns on and off caching seems just as well in PerlModule. However, I also think that this is unworthy of inclusion into the guide. PerlModule is well documented. startup.pl is well documented. Documenting where to put Apache::DBI? That's up to the sysadmin. Doesn't seem worthy of guide inclusion. For the complaint about $ENV{MOD_PERL}. I am not quite sure I really agree that this is a bad thing. Basically, by design you can see in your code explicitly which code will be run when Mod_perl is running and which code will not. What's so bad about that? However, if you really have a problem with this, why don't you create startup.pl and then a second non-apache-depdenent-startup.pl which is require'd from startup.pl Then when you run your script from the command line, just test the non-apache-dependent-startup.pl being loaded first so that startup.pl only contains mod_perl specific config. That way you get the best of both worlds. You could also probably do a check on $INC{'Apache.pm'} or something like that if you wanted to be a real stickler because in theory it might be possible to bootstrap a pseudo Apache.pm for non-inside-Apache testing. Anyway, in all these cases it does seem like there is more than one way to do it, and advocating a specific way just doesn't seem right for the guide since I think it is arguable either way. Later, Gunther At 06:17 PM 8/2/2001 -0700, Rob Bloodgood wrote: only if you code it the way you did below, which isn't terribly portable. see http://perl.apache.org/guide/perl.html#use_require_do_INC_and Ahem, PerlModule is a wrapper around the perl builtin require(). One presumes that perl knows where it lives if perl can successfully require() it. Especially since this module is installed into the standard perl heirarchy as a system module, from CPAN. It's not even XS. basically, it's a bad programming practice not to use() modules in the code that needs them. it works if you call PerlModule before you use() the module, but again, it requires you to pay better attention to your httpd.conf than you ought to. See my above point. Apache::DBI is *made* to be transparent, or at least semi-. It exists at the server level, and without (much) interaction with the programmer's dataspace at all. What better place for it than httpd.conf? And as for having to pay too much attention... well... let's just say that RedCode is spreading like it is because not enough IIS Admins paid better attention to the defaults THEY were given. :-) Seriously tho, why WOULDN'T you know what exactly is in your server configuration? consider writing an Apache module for CPAN, relying on, say, Apache::Log calls, but failing to use Apache::Log in your module. If you have a PerlModule Apache::Log everything works - until somebody else tries to run your code with a different configuration. There's what works and then there's how you ought to do things. Again, server-level and mostly transparent. And as far as requiring a module, 1) I would expect it to be clearly documented 2) and if I didn't read the dox I deserve to have wasted the time, and 3) I'll leave 3 for below... methods on it are valid, and can be easily wrapped as I suggested in an if($ENV{MOD_PERL}) {} block. this is just a particular gripe of mine, but I think we ought to be past the $ENV{MOD_PERL} thing by now... startup.pl is a mod_perl idiom. if you are designing web applications that depend on things like the mod_perl API, Apache::DBI, and using the hooks into the Apache request cycle then you are already way beyond making a startup.pl script portable between mod_perl and other web environments. Portable, portable, portable... First of all, understanding that items appearing earlier or later in a config file is significant is so common I'm astonished you consider it bad manners to see code that depends on it. And unless I'm very badly mistaken, it's even significant in httpd.conf as far as *Apache* is concerned. And secondly, you're right, this is *mod_perl*. Not IIS, NSAPI, PHP, or Cold Fusion. startup.pl is indubitably a mod_perl idiom. I'm failing