Re: Problem reloading modules
On Thu, 2003-08-14 at 11:24, Jean-Sebastien Guay wrote: > I'm using Apache::Reload, and I can see that my modified module is > getting reloaded (with ReloadDebug On), but the program still uses the > old code. How can you tell? Can you post some sample code? You might be doing something that doesn't work when reloaded, like closures. - Perrin
Re: Problem reloading modules
Perrin Harkins wrote: If you're interested in working on it, we could discuss possible approaches on the list and review your patch. In a week or so I'll have a bit more free time, and I might try implementing it. I'll start by reading up on mod_perl internals... :-) I'd suggest a different approach. Write a subclass of the registry and if it gains popularity we will merge it in. And you don't really need to read on mod_perl internals to do that. Just learn the ModPerl/RegistryCooker guts ;) __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Problem reloading modules
> However, there will always be things that Apache::Reload doesn't > handle. For example, you might import functions from one module into > another module, as opposed to importing into a Registry script. Well, making a given module aware of who imported it (whether it's a module or a Registry script) would solve that. But again, I don't know how complicated that would be; I'll have to read up when I try doing it. > My > advice is to avoid importing things at all, but I know that many people > really love importing and will not want to give it up. I'm one of them, at least with our present module hierarchy. But I understand your point of view too. J-S
Re: Problem reloading modules
On Thu, 2003-08-14 at 15:33, Jean-Sebastien Guay wrote: > In a week or so I'll have a bit more free time, and I might try > implementing it. I'll start by reading up on mod_perl internals... :-) Actually, all you need to read is the code for Apache::Registry or ModPerl::Registry (depending on which you are using) and the code for Apache::Reload. These are all pure perl modules. However, there will always be things that Apache::Reload doesn't handle. For example, you might import functions from one module into another module, as opposed to importing into a Registry script. My advice is to avoid importing things at all, but I know that many people really love importing and will not want to give it up. - Perrin
Re: Problem reloading modules
> How can you tell? Can you post some sample code? You might be doing
> something that doesn't work when reloaded, like closures.
Well, here's the code I'm trying to run. (I have verified that
Param('script_root') returns D:/htdocs, as expected). The initial code
was this:
<===>
sub getImage {
my ($project, $shotprefix, $shot) = @_;
$shot =~ s/\./_/;
my $image = Param('script_root') . '/' .
"images/$project/$shotprefix/$shot.jpg";
# Check if the shot-specific image exists
if (!-e $image) {
# If not, use the generic image
$image = Param('script_root') . '/' .
"images/$project/generic.jpg";
if (!-e $image) {
$image = Param('script_root') . '/' . "images/no_image.gif";
}
}
warn "-- image is $image";
return $image;
}
<===>
I changed it to this:
<===>
sub getImage {
my ($project, $shotprefix, $shot) = @_;
$shot =~ s/\./_/;
my $image = "images/$project/$shotprefix/$shot.jpg";
# Check if the shot-specific image exists
if (!-e Param('script_root') . '/' . $image) {
# If not, use the generic image
$image = "images/$project/generic.jpg";
if (!-e Param('script_root') . '/' . $image) {
$image = "images/no_image.gif";
}
}
warn "-- image is $image";
return $image;
}
<===>
The first piece of code would see that, for example,
"D:/htdocs/images/project/prefix/bob.jpg" exists, and return that whole
string.
The second piece of code would see that
"D:/htdocs/images/project/prefix/bob.jpg" exists but only return
"images/project/prefix/bob.jpg". That's what I want.
And I can see in the error_log that $image is still the absolute path
("D:/htdocs/images/project/prefix/bob.jpg" in our example) even after
the change.
J-S
Re: Problem reloading modules
Hi Perrin, > I don't see anything wrong with that chunk of code. If you restart the > server, does it pick up the change? Yes. > Is there anything unusual about the > way you call this sub (AUTOLOAD, function ref, etc.)? Not at all. It is imported with use Hybride::Projects qw(getImage ); and the file in which the sub is located is called Projects.pm, in a directory Hybride, whose parent directory (D:/htdocs) is added to my @INC by using 'use libs qw(D:/htdocs)' in my startup.pl file AND 'PerlSwitches -ID:/htdocs' in my httpd.conf (I just wanted to make sure... :-). I can see with perl-status that my @INC is correctly set to pick up the module, and that the module itself is listed in %INC with its absolute path on my filesystem, so that should be right. I get this in my error_log when I refresh the page that runs the CGI script that uses the sub: Apache::Reload: Checking mtime of Hybride/Projects.pm Subroutine listProjects redefined at D:/htdocs/Hybride/Projects.pm line 33. Subroutine validProject redefined at D:/htdocs/Hybride/Projects.pm line 49. Subroutine getImage redefined at D:/htdocs/Hybride/Projects.pm line 68. Subroutine getProjectAbbreviation redefined at D:/htdocs/Hybride/Projects.pm line 92. Apache::Reload: process 2392 reloading Hybride/Projects.pm I believe those warnings are normal since the module is being reloaded and the subs are being replaced in memory, right? So that tells me that the module is reloaded. However, the old code is still being used. > However, your code here looks pretty vanilla and seems like > it should be working fine with Reload. I agree. Is there anything else I can check to make sure I'm not missing anything obvious? Thank you, J-S
Re: Problem reloading modules
Stas Bekman wrote: > > OK, I've written a proper entry for the man page, Jean-Sebastien can you > > please verify that it all works, as I wrote it without testing. Great work Stas, you're quick :-) Other than the little mistake Perrin pointed out, the suggested change works. Perrin Harkins wrote: > If you're interested > in working on it, we could discuss possible approaches on the list and > review your patch. In a week or so I'll have a bit more free time, and I might try implementing it. I'll start by reading up on mod_perl internals... :-) Thanks for your help, J-S
Re: Problem reloading modules
On Thu, 2003-08-14 at 15:10, Stas Bekman wrote: > OK, I've written a proper entry for the man page, Jean-Sebastien can you > please verify that it all works, as I wrote it without testing. Thanks. > http://perl.apache.org/docs/2.0/api/Apache/Reload.html#Problems_with_Scripts_Running_with_Registry_Handlers_that_Cache_the_Code Thanks Stas! I think you have a little mistake here: @EXPORT = qw(set_colour); That should be @EXPORT = qw(colour); - Perrin
Re: Problem reloading modules
Perrin Harkins wrote: On Thu, 2003-08-14 at 15:10, Stas Bekman wrote: OK, I've written a proper entry for the man page, Jean-Sebastien can you please verify that it all works, as I wrote it without testing. Thanks. http://perl.apache.org/docs/2.0/api/Apache/Reload.html#Problems_with_Scripts_Running_with_Registry_Handlers_that_Cache_the_Code Thanks Stas! I think you have a little mistake here: @EXPORT = qw(set_colour); That should be @EXPORT = qw(colour); Thanks, committed! __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Problem reloading modules
Stas Bekman wrote: Perrin Harkins wrote: On Thu, 2003-08-14 at 14:29, Jean-Sebastien Guay wrote: I'm asking you to try it and see if it works. Ok, I tried it and it works. I guess we need to add this to the docs: Apache::Reload will have problems if you import subs from a module you are trying to reload. The problem is described here (and one of the solutions is to touch the file as Perrin has mentioned the other is covered in that URL) http://marc.theaimsgroup.com/?l=apache-modperl&m=105330639304103&w=2 I think I have planned to add this to the docs, but didn't get to it yet, I'll try to do that shortly. OK, I've written a proper entry for the man page, Jean-Sebastien can you please verify that it all works, as I wrote it without testing. Thanks. http://perl.apache.org/docs/2.0/api/Apache/Reload.html#Problems_with_Scripts_Running_with_Registry_Handlers_that_Cache_the_Code __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Problem reloading modules
On Thu, 2003-08-14 at 15:01, Jean-Sebastien Guay wrote: > Could something in Apache::Registry be implemented to integrate it > better with Apache::Reload? Something along the lines of keeping track > of which modules a certain script use()s, and at request time, checking > if Apache::Reload has reloaded one of those since the last request and > if so, reload the script itself? It's somewhat tricky to know what modules you've imported from. Maybe through overloading use(). The thing is, I don't use Registry or Apache::Reload so I don't have much motivation to do it. (I just restart my server, since it only takes a second.) If you're interested in working on it, we could discuss possible approaches on the list and review your patch. - Perrin
Re: Problem reloading modules
Perrin, > Apache::Registry? Just do a touch on the script file and Registry will > reload it. OK, thanks. > You could hack your own Apache::RegistryNG subclass that > would just reload everything when Apache::Reload triggers, but it's > probably not worth it. Could something in Apache::Registry be implemented to integrate it better with Apache::Reload? Something along the lines of keeping track of which modules a certain script use()s, and at request time, checking if Apache::Reload has reloaded one of those since the last request and if so, reload the script itself? That would remove the confusion, and make Apache::Reload's work more transparent, IMO. Anyways, for now I will do it as you suggested. Once more, thanks for the help. J-S
Re: Problem reloading modules
Perrin Harkins wrote: On Thu, 2003-08-14 at 14:29, Jean-Sebastien Guay wrote: I'm asking you to try it and see if it works. Ok, I tried it and it works. I guess we need to add this to the docs: Apache::Reload will have problems if you import subs from a module you are trying to reload. The problem is described here (and one of the solutions is to touch the file as Perrin has mentioned the other is covered in that URL) http://marc.theaimsgroup.com/?l=apache-modperl&m=105330639304103&w=2 I think I have planned to add this to the docs, but didn't get to it yet, I'll try to do that shortly. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Problem reloading modules
On Thu, 2003-08-14 at 14:29, Jean-Sebastien Guay wrote: > > I'm asking you to try it and see if it works. > > Ok, I tried it and it works. I guess we need to add this to the docs: Apache::Reload will have problems if you import subs from a module you are trying to reload. > The file that imports it is not a module, it's the actual script. Apache::Registry? Just do a touch on the script file and Registry will reload it. You could hack your own Apache::RegistryNG subclass that would just reload everything when Apache::Reload triggers, but it's probably not worth it. - Perrin
Re: Problem reloading modules
> I'm asking you to try it and see if it works. Ok, I tried it and it works. > A possible solution if that is the problem is to make all the modules > that import it reload as well. You can do that with a touch file. The file that imports it is not a module, it's the actual script. No other file (that is running currently) needs that sub. Can I get Apache::Reload to reload the script itself? Thanks for your help, J-S
Re: Problem reloading modules
On Thu, 2003-08-14 at 11:43, Jean-Sebastien Guay wrote:
> And I can see in the error_log that $image is still the absolute path
> ("D:/htdocs/images/project/prefix/bob.jpg" in our example) even after
> the change.
I don't see anything wrong with that chunk of code. If you restart the
server, does it pick up the change? Is there anything unusual about the
way you call this sub (AUTOLOAD, function ref, etc.)?
Reloading modules is not foolproof. Perl doesn't actually support it,
so things like Apache::Reload fake it by removing the module from %INC
and making it get compiled again. This usually works for things in the
symbol table, but people have reported problems in the past with things
that keep references to lexicals (closures) and other somewhat magical
features. However, your code here looks pretty vanilla and seems like
it should be working fine with Reload.
- Perrin
Problem reloading modules
Hello, I know this has been discussed before, but I can't seem to find the information I need to solve my problem. I'm using Apache::Reload, and I can see that my modified module is getting reloaded (with ReloadDebug On), but the program still uses the old code. I have read http://perl.apache.org/docs/2.0/api/Apache/Reload.html#Problems_With_Reloading_Modules_Which_Do_Not_Declare_Their_Package_Name but all my modules declare their package names. I have also checked, using the perl-status Apache module, and all my modules are in %INC with absolute paths, not relative ones. I have also checked, and nothing in http://perl.apache.org/docs/1.0/guide/porting.html#Using_Apache__Reload seems to resolve the problem. What else should I check? Thanks in advance, J-S ___ Jean-Sébastien Guay [EMAIL PROTECTED] Software Developer, Hybride http://www.hybride.com Piedmont, Québec, Canada
Re: Problem reloading modules
On Thu, 2003-08-14 at 13:41, Jean-Sebastien Guay wrote: > > Is there anything unusual about the > > way you call this sub (AUTOLOAD, function ref, etc.)? > > Not at all. It is imported with > > use Hybride::Projects qw(getImage ); I think that's the problem. You are creating an alias to the sub here, and when it gets reloaded the alias is still pointing to an old version. Try doing a fully-qualified sub call instead of importing. - Perrin
Re: Problem reloading modules
Perrin, > > use Hybride::Projects qw(getImage ); > > I think that's the problem. You are creating an alias to the sub here, > and when it gets reloaded the alias is still pointing to an old version. Actually, I just saw that the sub is exported in the EXPORT section of the Projects module, not the EXPORT_OK section, and is imported with use Hybride::Projects; Sorry about that, my mistake... But the sub is still not getting reloaded. > Try doing a fully-qualified sub call instead of importing. Err, that would actually be a pretty massive change to my codebase. Changing all the calls to Hybride::Module:: would be a pain, not to mention too much typing. There has to be another solution, isn't there? Thanks, J-S
Re: Problem reloading modules
On Thu, 2003-08-14 at 14:04, Jean-Sebastien Guay wrote: > > Try doing a fully-qualified sub call instead of importing. > > Err, that would actually be a pretty massive change to my codebase. > Changing all the calls to Hybride::Module:: would be > a pain, not to mention too much typing. There has to be another > solution, isn't there? I'm asking you to try it and see if it works. A possible solution if that is the problem is to make all the modules that import it reload as well. You can do that with a touch file. - Perrin
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
Ted Prah wrote:
> 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.
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');
> 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.
__
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');
>
> you will see that it fails as well. This code acts like Reload.pm, but
> always reloads the module. So it's not Reload.pm's fault.
>
> Is anybody else familiar with this Exporter's (mis)behavior?
>
> The solution that I see is to use something like this:
>
> package My::Test;
>
> use strict;
> use warnings;
>
> sub import {
> my $package = shift;
>
> no strict 'refs';
> for (@_) {
> *{ (caller)[0] . "::$_" } = \&{$_};
> }
> }
>
> sub test1 { print "In test1 func\n"; }
> sub test2 { print "In test2 func\n"; }
>
> 1;
>
> If somebody else can see the problem with Exporter may be we need to run
> it through p5p.
>
> __
> Stas BekmanJAm_pH --> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apac
Re: Reloading Modules
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');
you will see that it fails as well. This code acts like Reload.pm, but
always reloads the module. So it's not Reload.pm's fault.
Is anybody else familiar with this Exporter's (mis)behavior?
The solution that I see is to use something like this:
package My::Test;
use strict;
use warnings;
sub import {
my $package = shift;
no strict 'refs';
for (@_) {
*{ (caller)[0] . "::$_" } = \&{$_};
}
}
sub test1 { print "In test1 func\n"; }
sub test2 { print "In test2 func\n"; }
1;
If somebody else can see the problem with Exporter may be we need to run
it through p5p.
__
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
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
