Re: Apache::DBI in startup.pl generating error

2001-08-02 Thread Stas Bekman

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/





RE: Apache::DBI in startup.pl generating error

2001-08-02 Thread Rob Bloodgood

> 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 to
understand how this can be considered "portable".  But if you mean portable
from system to system, well, last I heard, ActiveState hadn't quite gotten
signals or sockets mastered, but I'm pretty certain the have the %ENV
emulation worked out.

But thirdly, I consider it a convenience to be able to test a script for
syntax errors before attempting to -HUP my webserver to see if it works or
not.  perl -wc is done almost before I register the cursor moving.  apache
restarts take me at least a minute.  It's not about the request cycle, it's
about the DEBUG cycle.  Since I didn't write Apache::DBI, but I have
reasonable confidence in the guy who did, it doesn't hurt my feelings to
defer initializing it until I've finished modifying startup.pl for other
reasons.  Which means I can make a change, switch windows, and perl -wc and
get a syntax check, instead of an Apache error on Apache::AuthDBI, in under
10 seconds.  Or even perl -w (even tho I run w/ -w in the shebang line and
PerlWarn On) and see debug output I'm working with.

For the record, I also consider it cheesy to have to check $ENV{MOD_PERL}
but to my knowledge, the Apache $s object isn't passed to startup.pl, and
setting an environment variable is significantly cheaper than creating a
perl object in terms of C code and devel/debug time.  Remember, the E in
perl is for "Eclectic." :-)

Idioms are there for a reason: They do well in shorthand a required task.
Even if there are other, longer ways to do the same thing.  TIMTOWTDI.  The
way I "ought to" program is in the way that makes perfect sense when one
understands all of the pieces, and document the hell out of it so that
people behind me who don't understand can at least follow the requirements
list.  ESPECIALLY when the person behind me is me, 6 months later.



L8r,
Rob

#!/usr/bin/perl -w
use Disclaimer qw/:standard/;





RE: Apache::DBI in startup.pl generating error

2001-08-02 Thread Rob Bloodgood

> > > > 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

2001-08-02 Thread Gunther Birznieks

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: Apache::DBI in startup.pl generating error

2001-08-03 Thread Geoffrey Young



>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: Apache::DBI in startup.pl generating error

2001-08-03 Thread Geoffrey Young



> -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::DBI in startup.pl generating error

2001-08-03 Thread Rob Bloodgood

> 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).
>
> >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.

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?).

Then a block like:

if ($im_in_mod_perl_now) {
$Apache::DBI::parameter = $newvalue;
# etc
}

would be completely appropriate in startup.pl.

My $.02

L8r,
Rob

#!/usr/bin/perl -w
use Disclaimer qw/:standard/;





RE: Apache::DBI in startup.pl generating error

2001-08-03 Thread Gunther Birznieks

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

RE: Apache::DBI in startup.pl generating error

2001-08-04 Thread Geoffrey Young



> -Original Message-
> From: Rob Bloodgood [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, August 02, 2001 2:31 PM
> To: Gunther Birznieks
> Cc: [EMAIL PROTECTED]; mod_perl
> Subject: RE: Apache::DBI in startup.pl generating error

[snip]

> 
> 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 :)

--Geoff