RE: Using Perl END{} with Apache::Registry
Hello Justin.
I've done a little work on a similar problem due to Apache::Registry's
unusual treatment of END {} blocks. You may want to take a look at
the module I recently submitted:
http://www.cpan.org/authors/id/T/TQ/TQISJIM/ChildExit_0-1.tar.gz
-Jim
> Hi, I'm trying to use the END{ } block in my Perl Scripts to do some
> code clean up (making sure files are not locked) at the end of each
> request. It seems to be working fine. I'm using Apache::Registry to
> run a regular Perl script. I'm having a problem with error messages.
>
>
>
> I have an included file that I'm requiring:
>
>
>
> require "test.pl";
>
>
>
> Without the END { } block if the script cannot find test.pl I get a
> Server error 500 and an appropriate error message in the log file. When
> I include the END{ } block I get no Server Error and no message in the
> log file. It is almost as if the END{ } is overwriting the
> ModPerlRegistry error system.
>
>
>
> Any ideas?
>
>
>
> Thanks.
Apache::ChildExit released
A couple of months ago I posted my realization that I was experiencing many problems with Apache::Registry due to its treatment of module END blocks. No one responded with a workaround, so I have released my own. The module Apache::ChildExit is now available on CPAN: http://www.cpan.org/authors/id/T/TQ/TQISJIM/ChildExit_0-1.tar.gz I have installed this module on three servers with very satisfactory results. Thanks, Jim Schueler
Re: END subroutine in Apache::Registry
Hi Stas. The documentation is neither unclear nor confusing. However, the implication was not obvious (well... not obvious enough) when I first read this section three years ago. If you're sincere about wanting suggestions, here's mine: In addition to understanding the behavior of END blocks in Apache::Registry scripts, a script writer must realize that any module invoked via "use" or "include" may work differently than its designer intended, if that module contains END blocks. -Jim On Fri, 12 Jul 2002, Stas Bekman wrote: > Jim Schueler wrote: > > I just read the fine print: Apache::Registry runs BEGIN subroutines just > > once per child process, but END routines run every time a script is run. > > The implication is that an otherwise robust module may behave unexpectedly > > when it's imported by an Apache::Registry script. Doesn't this cause > > problems for mod_perl users? There is no mention of this issue in either > > mod_perl_to_cgi or mod_perl_traps. > > > > Admittedly, most of the code in my END subroutines should probably be > > refactored into OO DESTROY subroutines anyways. But if not burned, I've > > been significantly scalded by this belated realization. > > > > I don't see anything on CPAN that can be easily applied to all of the > > modules that written. I'll happily fill that void, but I must be > > overlooking the obvious solution. Can anyone provide any insights? > > Please read: > http://perl.apache.org/release/docs/1.0/guide/porting.html#END_blocks > > The special case is for registry scripts that include END blocks. If the > the explanation at the above URL is unclear/confusing, please suggest > how to improve it. > > __ > 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 >
END subroutine in Apache::Registry
I just read the fine print: Apache::Registry runs BEGIN subroutines just once per child process, but END routines run every time a script is run. The implication is that an otherwise robust module may behave unexpectedly when it's imported by an Apache::Registry script. Doesn't this cause problems for mod_perl users? There is no mention of this issue in either mod_perl_to_cgi or mod_perl_traps. Admittedly, most of the code in my END subroutines should probably be refactored into OO DESTROY subroutines anyways. But if not burned, I've been significantly scalded by this belated realization. I don't see anything on CPAN that can be easily applied to all of the modules that written. I'll happily fill that void, but I must be overlooking the obvious solution. Can anyone provide any insights? Jim Schueler Motor City Interactive
