You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Morbus Iff <mo...@disobey.com> on 2004/02/18 22:56:33 UTC
Wow. Uh. Heh. PerlRun and Seeming Caches...
In an attempt to disprove my sanity, I did a quick swap out of
Apache::Registry for Apache::PerlRun, expecting that a good portion
of my problems [1] would go away. Oddly, they didn't. In fact, there
seemed to be no difference whatsoever. Can I learn anything from this?
[1] http://groups.yahoo.com/group/modperl/message/57303
--
Morbus Iff ( i put the demon back in codemonkey )
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/disobeycom
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Where is set_basic_auth_pw?
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
john Brahy wrote:
> Is there a way to set that information from mod_perl?
>
> I have written my own authentication system but I want to pass the username
> to the logs to replace the - - or unknown - that's happening now. I've
> looked in the white tailed eagle book but didn't see it.
>
>
> Mod_perl 1.29 / apache 1.3.27
see recipe 13.4 in the mod_perl developer's cookbook for ways to set the
password
http://www.modperlcookbook.org/chapters/ch13.pdf
I'm not sure which field the second - corresponds to, but if you've written
your own authentication scheme it looks like you forgot to set $r->user -
authentication handlers are expected to set $r->user and
$r->connection->auth_type. see recipes 13.7 and 13.8 as well.
HTH
--Geoff
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Where is set_basic_auth_pw?
Posted by john Brahy <Jo...@ad2.com>.
Is there a way to set that information from mod_perl?
I have written my own authentication system but I want to pass the username
to the logs to replace the - - or unknown - that's happening now. I've
looked in the white tailed eagle book but didn't see it.
Mod_perl 1.29 / apache 1.3.27
::::: John Brahy
::::: Research and Development
::::: www.ad2.com
::::: johnb@ad2.com
::::: t: 310. 394. 8379
::::: f: 310. 451. 0966
::::: ad2, Inc.
::::: 2118 Wilshire Blvd # 205
::::: Santa Monica, CA 90403
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Wow. Uh. Heh. PerlRun and Seeming Caches...
Posted by Morbus Iff <mo...@disobey.com>.
>> In an attempt to disprove my sanity, I did a quick swap out of
>> Apache::Registry for Apache::PerlRun, expecting that a good portion
>> of my problems [1] would go away. Oddly, they didn't. In fact, there
>> seemed to be no difference whatsoever. Can I learn anything from this?
>
>You can learn that you don't have a problem with globals that are in the
>current script's name space and not declared explicitly in any package.
>You may still have problems with globals in other packages, or closures.
This, as well as http://groups.yahoo.com/group/modperl/message/57338,
proved very helpful. I did some rather quick editing to match this
"Singleton pattern", and I've yet to be duplicate the caching that
was happening. I'm stilling having trouble with the missing-but-
existing function call [1], but I'll be able to poke around with
a little more understanding before I bug you again <g>.
[1] Program fragment delivered error ``Can't locate object
method "connect" via package "LibDB::DB::MySQL".
--
Morbus Iff ( i put the demon back in codemonkey )
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/disobeycom
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Wow. Uh. Heh. PerlRun and Seeming Caches...
Posted by Morbus Iff <mo...@disobey.com>.
At 7:53 PM -0500 2/19/04, petersm wrote:
>Morbus Iff wrote:
>> So, in my case, it appears that eval'ing the module in the .cgi script
>> is my only solution, based on this bit from the porting guidelines:
>>
>> When running under mod_perl, once the server is up @INC is frozen
>> and cannot be updated. The only opportunity to temporarily modify
>> @INC is while the script or the module are loaded and compiled for
>> the first time. After that its value is reset to the original one.
>> The only way to change @INC permanently is to modify it at startup.
>>
>
> PerlSetEnv PERL5LIB /path/to/my/modules
>
>That way it get's added to @INC for that location.
Yeah, the porting guide does talk about PerlSetEnv as a solution too.
--
Morbus Iff ( i subscribe to the theory of intellectual osmosis )
Technical: http://www.oreillynet.com/pub/au/779
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Wow. Uh. Heh. PerlRun and Seeming Caches...
Posted by petersm <pe...@venzia.com>.
Morbus Iff wrote:
> So, in my case, it appears that eval'ing the module in the .cgi script
> is my only solution, based on this bit from the porting guidelines:
>
> When running under mod_perl, once the server is up @INC is frozen
> and cannot be updated. The only opportunity to temporarily modify
> @INC is while the script or the module are loaded and compiled for
> the first time. After that its value is reset to the original one.
> The only way to change @INC permanently is to modify it at startup.
>
I might be wrong, but couldn't you fix it with this in your httpd.conf file
in a location tag.
<Location ...>
.
.
PerlSetEnv PERL5LIB /path/to/my/modules
.
.
</Location>
That way it get's added to @INC for that location.
Michael Peters
Venzia
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Wow. Uh. Heh. PerlRun and Seeming Caches...
Posted by Morbus Iff <mo...@disobey.com>.
>Hmm. You must have some things inside a BEGIN or that are called from a
>"use" that need these libs to be in @INC during the compile phase.
Yeah, I'm not entirely sure what it is - I'm not using any BEGIN's myself.
>More to the point, I would expect you to have the same problem that you
>had with "use lib" because you're really doing the same thing that use
>lib does. I'd suggest testing it more before you consider it solved.
Yup, I do. Did some testing over the weekend.
>By the way, it's pretty reasonable to expect that someone who intends to
>run your code under mod_perl will be able to either add a use lib
>statement to httpd.conf or put your libs in <APCHE_HOME>/lib/perl/ which
>is automatically added to @INC. Both of those avoid this issue
That's what I ended up deciding. :)
Thanks for all your help!
--
Morbus Iff ( i know a little of everything, a lot of nothing. )
Technical: http://www.oreillynet.com/pub/au/779
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Wow. Uh. Heh. PerlRun and Seeming Caches...
Posted by Perrin Harkins <pe...@elem.com>.
On Sat, 2004-02-21 at 20:43, Morbus Iff wrote:
> Well, without the BEGIN, running it as a normal CGI script failed entirely,
> with the scripts not being able to find the modules.
Hmm. You must have some things inside a BEGIN or that are called from a
"use" that need these libs to be in @INC during the compile phase.
> Throwing it into a
> BEGIN worked immediately thereafter, but I've not *extensively* tested
> it out under mod_perl yet. And yes, I'm attempting under Registry.
Because Registry caches your script, it only runs the BEGIN block the
first time the script gets compiled, and then again if you modify the
script. PerlRun executes BEGIN blocks every time because it recompiles
your script every time. So, if that stuff in the guide about @INC being
frozen is correct, I would expect that your BEGIN block solution would
only modify @INC on the first request when running under Registry.
More to the point, I would expect you to have the same problem that you
had with "use lib" because you're really doing the same thing that use
lib does. I'd suggest testing it more before you consider it solved.
By the way, it's pretty reasonable to expect that someone who intends to
run your code under mod_perl will be able to either add a use lib
statement to httpd.conf or put your libs in <APCHE_HOME>/lib/perl/ which
is automatically added to @INC. Both of those avoid this issue
completely.
- Perrin
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Wow. Uh. Heh. PerlRun and Seeming Caches...
Posted by Morbus Iff <mo...@disobey.com>.
>> For what it's worth, I had to do this instead:
>>
>> BEGIN { unshift(@INC, qw(lib extlib)); }
>
>That's odd, because that's almost exactly equivalent to a "use lib"
>call. Are you running this under PerlRun? PerlRun executes BEGIN
>blocks every time, but Registry only executes them once. It would be
>good to try to get things running under Registry, since it's
>significantly faster.
Well, without the BEGIN, running it as a normal CGI script failed entirely,
with the scripts not being able to find the modules. Throwing it into a
BEGIN worked immediately thereafter, but I've not *extensively* tested
it out under mod_perl yet. And yes, I'm attempting under Registry.
--
Morbus Iff ( I'd prefer my past to be multiple choice. )
Technical: http://www.oreillynet.com/pub/au/779
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Wow. Uh. Heh. PerlRun and Seeming Caches...
Posted by Perrin Harkins <pe...@elem.com>.
Morbus Iff wrote:
> For what it's worth, I had to do this instead:
>
> BEGIN { unshift(@INC, qw(lib extlib)); }
That's odd, because that's almost exactly equivalent to a "use lib"
call. Are you running this under PerlRun? PerlRun executes BEGIN
blocks every time, but Registry only executes them once. It would be
good to try to get things running under Registry, since it's
significantly faster.
- Perrin
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Wow. Uh. Heh. PerlRun and Seeming Caches...
Posted by Morbus Iff <mo...@disobey.com>.
>The only reason it doesn't work the second time is that "use lib 'lib'"
>happens at compile time. It's like a BEGIN block. To make it happen
>every time, you could just do this:
>
>unshift(@INC, qw(lib extlib));
For what it's worth, I had to do this instead:
BEGIN { unshift(@INC, qw(lib extlib)); }
--
Morbus Iff ( take this ming! i'm sick of your dynasty! )
Technical: http://www.oreillynet.com/pub/au/779
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Wow. Uh. Heh. PerlRun and Seeming Caches...
Posted by Perrin Harkins <pe...@elem.com>.
On Thu, 2004-02-19 at 18:33, Morbus Iff wrote:
> So, in my case, it appears that eval'ing the module in the .cgi script
> is my only solution, based on this bit from the porting guidelines:
>
> When running under mod_perl, once the server is up @INC is frozen
> and cannot be updated. The only opportunity to temporarily modify
> @INC is while the script or the module are loaded and compiled for
> the first time. After that its value is reset to the original one.
> The only way to change @INC permanently is to modify it at startup.
I actually didn't even realize that, since I always do a "use lib" in my
startup.pl file.
> * the first time index.cgi is run with no database connection,
> it loads all the magick modules I "use", save for LibDB::DB::MySQL.
> it can do this because I've passed 'lib' and 'extlib' to @INC.
> after the first run, @INC returns to normal (ie. no 'lib'/'extlib').
The only reason it doesn't work the second time is that "use lib 'lib'"
happens at compile time. It's like a BEGIN block. To make it happen
every time, you could just do this:
unshift(@INC, qw(lib extlib));
- Perrin
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Wow. Uh. Heh. PerlRun and Seeming Caches...
Posted by Morbus Iff <mo...@disobey.com>.
At 6:27 PM -0500 2/19/04, Morbus Iff wrote:
>>You are either getting the wrong module name in some cases, or it is not
>>able to read the module file for some reason. Just check $@ for the
>>message and find out.
>
> Can't locate LibDB/DB/MySQL.pm in @INC (@INC contains:
> /usr/lib/perl5/5.8.0/i586-linux-thread-multi /usr/lib/perl5/5.8.0
> /usr/lib/perl5/site_perl/5.8.0/i586-linux-thread-multi
> /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl . /usr/
> /usr/lib/perl) at (eval 17) line 2. BEGIN failed--compilation
> aborted at (eval 17) line 2. / 14495
>
>which means that %INC isn't being set as I intended,
>since the top of all my .cgi scripts include:
>
> use lib 'lib';
> use lib 'extlib';
So, in my case, it appears that eval'ing the module in the .cgi script
is my only solution, based on this bit from the porting guidelines:
When running under mod_perl, once the server is up @INC is frozen
and cannot be updated. The only opportunity to temporarily modify
@INC is while the script or the module are loaded and compiled for
the first time. After that its value is reset to the original one.
The only way to change @INC permanently is to modify it at startup.
Workflow wise, this is what happens (I'm writing this down for my
benefit and confirmation; not to chastise you with something you
already know <g>):
* the first time index.cgi is run with no database connection,
it loads all the magick modules I "use", save for LibDB::DB::MySQL.
it can do this because I've passed 'lib' and 'extlib' to @INC.
after the first run, @INC returns to normal (ie. no 'lib'/'extlib').
* the second time index.cgi is run (this time, WITH a dbconn),
it tries to eval LibDB:DB::MySQL in. Since this file is not part
of the default @INC (which now does NOT include my lib/extlib),
it can't be found. refreshing like mad brings me to a child
with no cache/reset @INC, and things work just fine.
--
Morbus Iff ( united we're bland )
Technical: http://www.oreillynet.com/pub/au/779
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Wow. Uh. Heh. PerlRun and Seeming Caches...
Posted by Morbus Iff <mo...@disobey.com>.
>You are either getting the wrong module name in some cases, or it is not
>able to read the module file for some reason. Just check $@ for the
>message and find out.
Interesting. I got:
Can't locate LibDB/DB/MySQL.pm in @INC (@INC contains:
/usr/lib/perl5/5.8.0/i586-linux-thread-multi /usr/lib/perl5/5.8.0
/usr/lib/perl5/site_perl/5.8.0/i586-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl . /usr/
/usr/lib/perl) at (eval 17) line 2. BEGIN failed--compilation
aborted at (eval 17) line 2. / 14495
which means that %INC isn't being set as I intended,
since the top of all my .cgi scripts include:
use lib 'lib';
use lib 'extlib';
/me heads off to read more.
--
Morbus Iff ( i put the demon back in codemonkey )
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/disobeycom
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Wow. Uh. Heh. PerlRun and Seeming Caches...
Posted by Perrin Harkins <pe...@elem.com>.
On Thu, 2004-02-19 at 17:38, Morbus Iff wrote:
> * the first load of index.cgi uses no DB calls (well,
> it does "use LibDB::DB", but DB.pm never gets around
> to eval'ing MySQL.pm), so things are cached without it.
>
> * with all the modules and whatnot cached in the child,
> a "use the database" call to that process fails because
> LibDB::DB::MySQL isn't part of that cache.
No, it doesn't work that way. You can always load more modules.
You are either getting the wrong module name in some cases, or it is not
able to read the module file for some reason. Just check $@ for the
message and find out.
> If that's the case, then I should consider eval'ing my
> database module in the .cgi script, regardless of whether
> I'm actually using any of it's functions.
You should load all of your modules during startup to save memory, but
that's not related to this problem.
- Perrin
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Wow. Uh. Heh. PerlRun and Seeming Caches...
Posted by Morbus Iff <mo...@disobey.com>.
>> I don't, however, do any error checking on that eval.
>
>Jinx!
Heh, heh :)
>> that if a) the eval fails or it gets cached or whatever, then
>> b) I'd be returning a blessed object for a module that hasn't
>> been loaded. *That* could cause the ->connect to not exist,
>> thus causing my error. Right?
>
>Right.
And this is confirmed further: if I just add "use LibDB::DB::MySQL"
to the top of my .cgi scripts (yeah, yeah, the whole "in the same
codebase" stuff), then I can't replicate the missing ->connect.
>It's not random; you just don't know what series of steps reproduces it
>yet. If you run with -X, you can probably find a sequence that will do
This is what I'm hoping happens (I'm still in the process
of building a dev server that exactly mimicks my prod, thus
allowing me to run -X). Does the following sound possible?
* the first load of index.cgi uses no DB calls (well,
it does "use LibDB::DB", but DB.pm never gets around
to eval'ing MySQL.pm), so things are cached without it.
* with all the modules and whatnot cached in the child,
a "use the database" call to that process fails because
LibDB::DB::MySQL isn't part of that cache. Refreshing
like mad eventually brings me to a child that has not
previously cached things, and thus, LibDB::DB::MySQL
is loaded and cached.
If that's the case, then I should consider eval'ing my
database module in the .cgi script, regardless of whether
I'm actually using any of it's functions.
--
Morbus Iff ( i put the demon back in codemonkey )
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/disobeycom
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Wow. Uh. Heh. PerlRun and Seeming Caches...
Posted by Perrin Harkins <pe...@elem.com>.
On Thu, 2004-02-19 at 17:01, Morbus Iff wrote:
> I don't, however, do any error checking on that eval.
Jinx!
> It seems
> that if a) the eval fails or it gets cached or whatever, then
> b) I'd be returning a blessed object for a module that hasn't
> been loaded. *That* could cause the ->connect to not exist,
> thus causing my error. Right?
Right.
> /me searches the mod_perl docs for mentions of eval.
There is nothing special about eval under mod_perl. Remember, mod_perl
is just perl, with some extra classes. It has no fundamental
differences.
- Perrin
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Wow. Uh. Heh. PerlRun and Seeming Caches...
Posted by Morbus Iff <mo...@disobey.com>.
>Alrighty. I've yet to figure out what my ->connect problem [1] is.
>All my settings caching problems have been fixed, as I've yet to
>duplicate the issue in about 300 to 400 loads. Anywhere I should
>look? What I know:
>
>[1] http://groups.yahoo.com/group/modperl/message/57303
> Program fragment delivered error ``Can't locate object
> method "connect" via package "LibDB::DB::MySQL".
How does mod_perl handle evals? Since LibDB::DB determines what
database module to load at runtime, it "eval"'s this selection:
# if it exists, bless ourselves into its class.
eval "use LibDB::DB::$user_dbtype"; # load this class into memory.
my $self = bless { _error => '' }, "LibDB::DB::$user_dbtype";
I don't, however, do any error checking on that eval. It seems
that if a) the eval fails or it gets cached or whatever, then
b) I'd be returning a blessed object for a module that hasn't
been loaded. *That* could cause the ->connect to not exist,
thus causing my error. Right? <g>
/me searches the mod_perl docs for mentions of eval.
--
Morbus Iff ( i put the demon back in codemonkey )
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/disobeycom
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Wow. Uh. Heh. PerlRun and Seeming Caches...
Posted by Perrin Harkins <pe...@elem.com>.
On Thu, 2004-02-19 at 16:54, Morbus Iff wrote:
> * LibDB::DB is correctly determining the database type.
>
> * LibDB::DB is correctly returning a blessed
> class for that database type (LibDB::DB::MySQL).
>
> * LibDB::DB::MySQL->connect does exist.
>
> * LibDB::DB::MySQL->connect does work.
>
> But, still, I'll randomly get the error [1].
It's not random; you just don't know what series of steps reproduces it
yet. If you run with -X, you can probably find a sequence that will do
it.
Usually people find that pulling things out in order to reduce things to
a simple example will eventually show what the problem is. You also can
try putting in a bunch of logging around the places where you call this
method.
> What should I look for?
It would help if you could give some context by showing the code that
produces this error. A quick look makes me think that this code is
suspicious:
# if it exists, bless ourselves into its class.
eval "use LibDB::DB::$user_dbtype"; # load this class into memory.
my $self = bless { _error => '' }, "LibDB::DB::$user_dbtype";
You bless a hash ref into a class, but you don't check the value of $@.
That class may not have actually loaded.
- Perrin
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Wow. Uh. Heh. PerlRun and Seeming Caches...
Posted by Morbus Iff <mo...@disobey.com>.
>>You can learn that you don't have a problem with globals that are in the
>>current script's name space and not declared explicitly in any package.
>>You may still have problems with globals in other packages, or closures.
>
>This, as well as http://groups.yahoo.com/group/modperl/message/57338,
>proved very helpful. I did some rather quick editing to match this
>"Singleton pattern", and I've yet to be duplicate the caching that
>was happening. I'm stilling having trouble with the missing-but-
>existing function call [1], but I'll be able to poke around with
>a little more understanding before I bug you again <g>.
Alrighty. I've yet to figure out what my ->connect problem [1] is.
All my settings caching problems have been fixed, as I've yet to
duplicate the issue in about 300 to 400 loads. Anywhere I should
look? What I know:
* LibDB::DB is correctly determining the database type.
* LibDB::DB is correctly returning a blessed
class for that database type (LibDB::DB::MySQL).
* LibDB::DB::MySQL->connect does exist.
* LibDB::DB::MySQL->connect does work.
But, still, I'll randomly get the error [1]. From ignorance, this
*can't* be related to globals or caching, right (since it is
reporting the correct package name, and a cache wouldn't
suddenly "remove" a function)? What should I look for?
[1] http://groups.yahoo.com/group/modperl/message/57303
Program fragment delivered error ``Can't locate object
method "connect" via package "LibDB::DB::MySQL".
--
Morbus Iff ( i put the demon back in codemonkey )
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/disobeycom
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Wow. Uh. Heh. PerlRun and Seeming Caches...
Posted by Perrin Harkins <pe...@elem.com>.
On Wed, 2004-02-18 at 16:56, Morbus Iff wrote:
> In an attempt to disprove my sanity, I did a quick swap out of
> Apache::Registry for Apache::PerlRun, expecting that a good portion
> of my problems [1] would go away. Oddly, they didn't. In fact, there
> seemed to be no difference whatsoever. Can I learn anything from this?
You can learn that you don't have a problem with globals that are in the
current script's name space and not declared explicitly in any package.
You may still have problems with globals in other packages, or closures.
- Perrin
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html