Re: Reloading Modules
Stas Bekman wrote:
> Ted Prah wrote:
> > Thanks for the input Stas. I found your debugging methodology
> > to be very informative and especially useful in a mod_perl environment.
> >
> > I tried your suggestion of commenting out
> > require $key;
> > in Reload.pm, but it did not work for me. I'd be happy to try
> > any other suggestions you might have.
>
> But did you debug whether the module was reloaded from test.pl with the
> modified Reload.pm? If so was the import() called? If not, try to have
> it as a separate call:
>
> require My::Test;
> My::Test->import(':subs');
>
This worked! The modification to Reload.pm was not necessary for
this to work.
>
> > Your code to work around Exporter worked fine. However,
> > I think I'll stick with using Exporter so that I can make use
> > of the export tags.
>
> But it doesn't seem to work? You can easily extend the import() function
> I've suggested to suppport tags.
>
Right, it doesn't work unless I restart the server. Restarting the
server has been made easier due to your advice on cloning the
apachectl script and setting the suid bit.
Thanks again for all your help,
Ted
>
> __
> 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: Reloading Modules
Thanks for the input Stats. I found your debugging methodology
to be very informative and especially useful in a mod_perl environment.
I tried your suggestion of commenting out
require $key;
in Reload.pm, but it did not work for me. I'd be happy to try
any other suggestions you might have.
Your code to work around Exporter worked fine. However,
I think I'll stick with using Exporter so that I can make use
of the export tags.
Thanks again!
Ted
Stas Bekman wrote:
> Ted Prah wrote:
> > Hi again,
> >
> > I'm having trouble seeing module changes when I reload
> > a script that uses it.
>
> That's because Reload.pm doesn't re-exports the symbols when reloading
> the module and test.pl doesn't call import() because it sees the module
> in %INC, therefore it still sees the old sub till the moment it gets
> recompiled. Below you will find a complete analysis.
>
> > I'm using Apache::Reload and my test
> > script/module is as follows:
> >
> >
> > test.pl
> >
> > #!/usr/local/bin/perl
> > use strict;
> > use warnings;
> >
> > use My::Test qw(:subs);
> >
> > print "Content-type: text/plain\r\n\r\n";
> > &test1();
> >
> >
> >
> > Test.pm
> >
> > package My::Test;
> > use strict;
> > use warnings;
> >
> > BEGIN {
> > use Exporter ();
> >
> > our (@ISA, @EXPORT, @EXPORT_OK, %EXPORT_TAGS);
> >
> > @ISA = qw(Exporter);
> > @EXPORT= qw();
> > @EXPORT_OK = qw();
> >
> > %EXPORT_TAGS = (
> > subs => [qw(test1)],
> >);
> >
> > Exporter::export_ok_tags('subs');
> >
> > }
> >
> > sub test1 { print "In test1 func\n"; }
> >
> > 1;
> >
>
> adjust the test.pl to do:
>
> test1(); print \&test1, "\n";
> #test2(); print \&test2, "\n";
>
> and My::Test.pm to:
>
> ...
> warn "test1:", \&test1, "\n";
> #warn "test2:", \&test2, "\n";
> sub test1 { print "In test1 func\n"; }
> #sub test2 { print "In test2 func\n"; }
> ...
>
> The first time you run the script you will see:
>
> output:
> In test1 func
> CODE(0x85ad38c)
>
> error_log:
> test1:CODE(0x85ad38c)
>
> you can see that both test1 and My::Test::test1 point to the same sub.
>
> > When I modify sub test1, and I reload - no changes appear
> > in the browser. The following gets printed to error_log:
> > Subroutine test1 redefined at /export/home/httpd/cgi-bin/My/Test.pm line 22.
>
> output:
> In test1 func
> CODE(0x85ad38c)
>
> error_log:
> test1:CODE(0x84ee110)
>
> as you see the test1 is not the same as My::Test::test1
>
> > When I touch test.pl - the changes appear. The following gets printed
> > to error_log:
> > Subroutine test1 redefined at /export/home/httpd/cgi-bin/My/test.pl line 5
>
> output:
> In test11 func
> CODE(0x84ee110)
>
> now it points to the recent My::Test::test1
>
> In that way you can debug any "mysteries" in Perl code.
>
> Now, how to solve this problem. For example comment out
> require $key;
>
> in Reload.pm
>
> that way, test.pl will see that My::Test is not in %INC, and require it
> + call its import() method.
>
> Tell if this worked and we may adjust Reload.pm to have a special mode
> where it makes Perl forget about modified modules and let the code that
> loaded them in first place do the loading (and therefore the importing).
>
> > Finally, if I add a new subroutine test2 to Test.pm, export it, and
> > update the test.pl script to call test2, the script fails with an
> > Internal
> > Server Error. The following gets printed to error_log:
> > "test2" is not exported by the My::Test module at
> > /export/home/httpd/cgi-bin/My/test.pl line 5
> > [Wed May 22 15:26:12 2002] [error] Can't continue after import errors at
> >
> > /export/home/httpd/cgi-bin/My/test.pl line 5
> > BEGIN failed--compilation aborted at /export/home/httpd/cgi-bin/
> > My/test.pl line 5.
> >
> > Then, when I restart the server, the script runs fine.
>
> Hmm, this one is different. Seems like a bug in Exporter.
>
> if you remove Reload.pm from the setup, so it won't confuse you and
> adjust the code to do:
>
> do "My/Test.pm";
> My::Test->import(':subs');
Reloading Modules
Hi again,
I'm having trouble seeing module changes when I reload
a script that uses it. I'm using Apache::Reload and my test
script/module is as follows:
test.pl
#!/usr/local/bin/perl
use strict;
use warnings;
use My::Test qw(:subs);
print "Content-type: text/plain\r\n\r\n";
&test1();
Test.pm
package My::Test;
use strict;
use warnings;
BEGIN {
use Exporter ();
our (@ISA, @EXPORT, @EXPORT_OK, %EXPORT_TAGS);
@ISA = qw(Exporter);
@EXPORT= qw();
@EXPORT_OK = qw();
%EXPORT_TAGS = (
subs => [qw(test1)],
);
Exporter::export_ok_tags('subs');
}
sub test1 { print "In test1 func\n"; }
1;
When I modify sub test1, and I reload - no changes appear
in the browser. The following gets printed to error_log:
Subroutine test1 redefined at /export/home/httpd/cgi-bin/My/Test.pm line
22.
When I touch test.pl - the changes appear. The following gets printed
to error_log:
Subroutine test1 redefined at /export/home/httpd/cgi-bin/My/test.pl line
5
Finally, if I add a new subroutine test2 to Test.pm, export it, and
update the test.pl script to call test2, the script fails with an
Internal
Server Error. The following gets printed to error_log:
"test2" is not exported by the My::Test module at
/export/home/httpd/cgi-bin/My/test.pl line 5
[Wed May 22 15:26:12 2002] [error] Can't continue after import errors at
/export/home/httpd/cgi-bin/My/test.pl line 5
BEGIN failed--compilation aborted at /export/home/httpd/cgi-bin/
My/test.pl line 5.
Then, when I restart the server, the script runs fine.
Thank you for any help you can provide,
Ted
Re: Reloading Library Files
Stas Bekman wrote: > Ted Prah wrote: > > >>do you test only this script alone? What happens if you add the package > >>declaration and then call it using the full name? e.g.: > >> > > > > > > Yes, this is the only script (and corresponding library file) that I use > > for this test. When I use the package declaration and make the call > > using the full name, the reloads work fine. > > > > The reason I am using the library file is to follow your recommendation > > in the mod_perl guide where a script is split into two files to avoid > > the nested subroutine problem. Out of curiosity I tested the sample > > code (counter.pl and mylib.pl) and they too did not reload properly > > when mylib.pl was modified. Does the reloading of a modification > > of mylib.pl work for you? I would prefer to use the library file > > approach as opposed to the package approach as a lot of our code > > uses libraries that are not in packages, but will move to packages if > > that is a necessity. > > Well, that explains everything. > > When you require() a library without that doesn't declare a package for > the first time from the registry script, all its global symbols (subs, > vars, etc) get imported into the namespace of the caller, i.e. the > registry script (APACHE::ROOT::...). > > When Apache::Reload require()s that library that doesn't declare a > package, all the global symbols end up in the Apache::Reload namespace! > So the library does get reloaded and you see the compile time errors if > there are any, but the symbols don't get imported to the right > namespace. So the old code is running. Moreover this leads to a > pollution of the Apache::Reload namespace, which may cause to problems > if you happen to overwrite some of its symbols (subs, vars, etc). > That explains the library files not reloading - Thanks! > > I suppose if you want to use the cheap workaround, you have to > s/require/do/. Remember that the guide suggests the lib.pl trick as a > workaround, not a solution you go with during the normal development. I didn't realize that using the library wrapper was a cheap workaround to the nested subroutine problem. The effects of the nested subroutine problem is my biggest concern with writing code for mod_perl. What I liked about the lib.pl trick is that it completely eliminates this problem. I won't lose sleep wondering if somehow the code went into production with a nested subroutine. I realize that there are other ways to eliminate the nested subroutine problem, but what are the preferred techniques used by mod_perl developers? Check the error_log file for problems and fix as needed? > > Was this explanation clear enough? We need to add it to the > Apache::Reload manpage to avoid this kind of questions in the future. > Makes sense. > > Funny though, that it's the first time this problem has been reported. > Which shows that most of the people don't use workarounds when they do > real developments :) > > > __ > 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 -- Ted Prah NetCasters, Inc. [EMAIL PROTECTED]
Re: Reloading Library Files
Stas Bekman wrote:
> Ted Prah wrote:
> > Thanks Drew, I tried that, but it did not work.
>
> What happends if you add:
>
> PerlWarn On
>
> in httpd.conf
>
> or
>
> start the script with perl -w?
>
> any warnings?
>
I had PerlWarn On and added -w anyway, but there were no errors.
>
> do you test only this script alone? What happens if you add the package
> declaration and then call it using the full name? e.g.:
>
Yes, this is the only script (and corresponding library file) that I use
for this test. When I use the package declaration and make the call
using the full name, the reloads work fine.
The reason I am using the library file is to follow your recommendation
in the mod_perl guide where a script is split into two files to avoid
the nested subroutine problem. Out of curiosity I tested the sample
code (counter.pl and mylib.pl) and they too did not reload properly
when mylib.pl was modified. Does the reloading of a modification
of mylib.pl work for you? I would prefer to use the library file
approach as opposed to the package approach as a lot of our code
uses libraries that are not in packages, but will move to packages if
that is a necessity.
Thank you, I really appreciate your help.
>
> z.pl - test script which calls entry_point in z_lib.pl
> ---
> #!/usr/local/bin/perl -w
> use strict;
>
> require '/home/cgi-bin/z_lib.pl';
>
> My::Z::entry_point();
> ---
>
> z_lib.pl
> --
> package My::Z;
> use strict;
>
> sub entry_point {
>
> my $r = Apache->request;
> $r->content_type('text/html');
> $r->send_http_header;
>
> print "HERE 1";
> #print " HERE 2";
>
> }
>
> > Ted
> >
> > Drew Taylor wrote:
> >
> >
> >>Have you tried moving the PerlInitHandler & PerlSetVar up and out of the
> >> directive, making it global for the server? I'm not sure that
> >>would fix it, but it's worth a try.
> >>
> >>Drew
> >>
> >>At 02:37 PM 5/17/02 -0400, Ted Prah wrote:
> >>
> >>>I have tried Apache::Reload as well, but I get the same results.
> >>>
> >>>Ted
> >>>
> >>>Drew Taylor wrote:
> >>>
> >>>
> >>>>Take a look at Apache::Reload or Apache::StatINC. Reload is more flexible,
> >>>>but StatINC has been around a little longer. Both have worked well for me.
> >>>>But be sure that you don't use these modules on a production server. :-)
> >>>>
> >>>>httpd.conf
> >>>>==
> >>>>PerlInitHandler Apache::Reload
> >>>>
> >>>>Drew
> >>>>
> >>>>At 01:38 PM 5/17/02 -0400, Ted Prah wrote:
> >>>>
> >>>>>Hi,
> >>>>>
> >>>>>I am new to mod_perl and am having problems seeing the
> >>>>>changes made to library files. Must I restart the server every
> >>>>>time I change a library file in order to see my changes? My
> >>>>>test code and environment is below.
> >>>>
> >>==
> >>Drew Taylor | Freelance web development using
> >>http://www.drewtaylor.com/ | perl/mod_perl/MySQL/postgresql/DBI
> >>mailto:[EMAIL PROTECTED] | Email jobs at drewtaylor.com
> >>--
> >>Speakeasy.net: A DSL provider with a clue. Sign up today.
> >>http://www.speakeasy.net/refer/29655
> >>==
> >
> >
> > --
> > Ted Prah
> > NetCasters, Inc.
> > Phone: 978.887.2100 x44
> > Fax: 978.887.6750
> > [EMAIL PROTECTED]
> >
>
> --
>
> __
> 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
--
Ted Prah
NetCasters, Inc.
Phone: 978.887.2100 x44
Fax: 978.887.6750
[EMAIL PROTECTED]
Re: Reloading Library Files
Thanks Drew, I tried that, but it did not work. Ted Drew Taylor wrote: > Have you tried moving the PerlInitHandler & PerlSetVar up and out of the > directive, making it global for the server? I'm not sure that > would fix it, but it's worth a try. > > Drew > > At 02:37 PM 5/17/02 -0400, Ted Prah wrote: > >I have tried Apache::Reload as well, but I get the same results. > > > >Ted > > > >Drew Taylor wrote: > > > > > Take a look at Apache::Reload or Apache::StatINC. Reload is more flexible, > > > but StatINC has been around a little longer. Both have worked well for me. > > > But be sure that you don't use these modules on a production server. :-) > > > > > > httpd.conf > > > == > > > PerlInitHandler Apache::Reload > > > > > > Drew > > > > > > At 01:38 PM 5/17/02 -0400, Ted Prah wrote: > > > >Hi, > > > > > > > >I am new to mod_perl and am having problems seeing the > > > >changes made to library files. Must I restart the server every > > > >time I change a library file in order to see my changes? My > > > >test code and environment is below. > > == > Drew Taylor | Freelance web development using > http://www.drewtaylor.com/ | perl/mod_perl/MySQL/postgresql/DBI > mailto:[EMAIL PROTECTED] | Email jobs at drewtaylor.com > -- > Speakeasy.net: A DSL provider with a clue. Sign up today. > http://www.speakeasy.net/refer/29655 > == -- Ted Prah NetCasters, Inc. Phone: 978.887.2100 x44 Fax: 978.887.6750 [EMAIL PROTECTED]
Re: Reloading Library Files
I have tried Apache::Reload as well, but I get the same results. Ted Drew Taylor wrote: > Take a look at Apache::Reload or Apache::StatINC. Reload is more flexible, > but StatINC has been around a little longer. Both have worked well for me. > But be sure that you don't use these modules on a production server. :-) > > httpd.conf > == > PerlInitHandler Apache::Reload > > Drew > > At 01:38 PM 5/17/02 -0400, Ted Prah wrote: > >Hi, > > > >I am new to mod_perl and am having problems seeing the > >changes made to library files. Must I restart the server every > >time I change a library file in order to see my changes? My > >test code and environment is below. > > == > Drew Taylor | Freelance web development using > http://www.drewtaylor.com/ | perl/mod_perl/MySQL/postgresql/DBI > mailto:[EMAIL PROTECTED] | Email jobs at drewtaylor.com > -- > Speakeasy.net: A DSL provider with a clue. Sign up today. > http://www.speakeasy.net/refer/29655 > ==
Reloading Library Files
Hi,
I am new to mod_perl and am having problems seeing the
changes made to library files. Must I restart the server every
time I change a library file in order to see my changes? My
test code and environment is below.
z.pl - test script which calls entry_point in z_lib.pl
---
#!/usr/local/bin/perl
use strict;
require '/home/cgi-bin/z_lib.pl';
&entry_point();
---
z_lib.pl
--
#!/usr/local/bin/perl
use strict;
sub entry_point {
my $r = Apache->request;
$r->content_type('text/html');
$r->send_http_header;
print "HERE 1";
#print " HERE 2";
}
1;
--
My Test Procedure:
1.) Start server (w/ -X option)
2.) Run z.pl via browser - output is "HERE 1"
3.) Uncomment out second print statement in z_lib.pl
4.) Reload z.pl via browser - output is "HERE 1"
I would expect it to display the output of
the second print statement, but it does not.
5.) Re-start server
6.) Run z.pl via browser - output is "HERE 1 HERE 2"
If I deliberately put an error in z_lib.pl and reload z.pl, I receive
an error message. So, it appears that the library file z_lib.pl is
getting reloaded. But why don't my changes show up? Also,
here is the output in the error_log that displays Apache::StatINC
messages
Apache::StatINC: process 21891 reloading /home/cgi-bin/z_lib.pl.
Apache::StatINC::handler('Apache=SCALAR(0x211220)') called at /dev/null
line 0 eval {...} called at /dev/null line 0
I have extended @INC by using "use lib .." in the startup file. I
have read through the mod_perl guide at http://apache.perl.org/, but
am unable to resolve this problem. Should I replace the 'require's
with 'do's in development and then switch back to requires when
moving to production?
My Environment:
perl version: 5.6.1
mod_perl version: 1.26
apache version: 1.3.24
OS: Solaris 2.8
from httpd.conf
PerlWarn On
PerlModule Apache::StatINC
PerlRequire /httpd/conf/startup.pl
Alias /cgi-bin/ /home/cgi-bin/
PerlModule Apache::Registry
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
allow from all
PerlSendHeader On
PerlInitHandler Apache::StatINC
PerlSetVar StatINC_Debug 1
startup.pl
---
use strict;
# Extend @INC if needed
use lib qw(/home/cgi-bin);
# Make sure we are in a sane environment.
$ENV{MOD_PERL} or die "not running under mod_perl!";
# Don't include the name of the virtual host in the package name
$Apache::Registry::NameWithVirtualHost = 0;
# Load Perl modules of your choice here
# This code is interpreted *once* when the server starts
use Apache::DBI ();
use DBI ();
# Tell me more about warnings
use Carp ();
$SIG{__WARN__} = \&Carp::cluck;
1;
---
Thanks for any help you can provide,
Ted
