perl-docs-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From s...@apache.org
Subject cvs commit: modperl-docs/src/docs/2.0/user/porting compat.pod
Date Thu, 22 Jul 2004 05:37:30 GMT
stas        2004/07/21 22:37:30

  Modified:    src/docs/2.0/user/config config.pod
               src/docs/2.0/user/handlers intro.pod server.pod
               src/docs/2.0/user/porting compat.pod
  Log:
  new sections:
  # Startup Process
  # PerlLoadModule
  # PerlModule
  # PerlRequire
  
  Revision  Changes    Path
  1.66      +378 -224  modperl-docs/src/docs/2.0/user/config/config.pod
  
  Index: config.pod
  ===================================================================
  RCS file: /home/cvs/modperl-docs/src/docs/2.0/user/config/config.pod,v
  retrieving revision 1.65
  retrieving revision 1.66
  diff -u -u -r1.65 -r1.66
  --- config.pod	15 Jul 2004 20:51:08 -0000	1.65
  +++ config.pod	22 Jul 2004 05:37:30 -0000	1.66
  @@ -71,15 +71,60 @@
   C<PerlModule> directives are processed.
   
   
  +=head1 Startup Process
  +
  +As explained in the L<Server Life
  +Cycle|docs::2.0::user::handlers::server> chapter, normally Apache
  +runs the server configuration phase, followed by
  +C<L<PerlOpenLogsHandler|docs::2.0::user::handlers::server/C_PerlOpenLogsHandler_>>
  +and
  +C<L<PerlPostConfigHandler|docs::2.0::user::handlers::server/C_PerlPostConfigHandler_>>
  +phases, then immediately restarts itself. Therefore everything running
  +at the server startup is executed twice. During the restart, Perl is
  +completely destroyed and started again.
  +
  +If Apache is started as C<'httpd -t'> (equivalent to C<'apachectl
  +configtest'>) or as C<'httpd -S'>, it will run only the configuration
  +phase and exit. mod_perl 2.0 postpones the startup of Perl until after
  +the configuration phase is over, to allow the usage of the
  +C<L<PerlSwitches|/C_PerlSwitches_>> directive, which can't be used
  +after Perl is started.  mod_perl starts Perl and runs any registered
  +C<L<PerlRequire|/C_PerlRequire_>> and C<L<PerlModule|/C_PerlModule_>>
  +entries as the very first thing during the
  +C<L<PerlOpenLogsHandler|docs::2.0::user::handlers::server/C_PerlOpenLogsHandler_>>
  +phase, which is not invoked during the C<'apachectl configtest'>
  +execution.
  +
  +There are two cases when mod_perl 2.0 is forced to start early (during
  +the configuration phase). First, is when
  +C<L<PerlLoadModule|/C_PerlLoadModule_>> is used and second is when a
  +C<L<E<lt>PerlE<gt> section|docs::2.0::api::Apache::PerlSections>>
is
  +encountered, both requiring a running Perl, and therefore triggering
  +an early server startup.
  +
  +Therefore at the moment, if you want to trigger an early Perl startup,
  +just add an empty C<L<E<lt>PerlE<gt>
  +section|docs::2.0::api::Apache::PerlSections>> in F<httpd.conf>:
  +
  +  <Perl>
  +  # trigger an early Perl startup
  +  </Perl>
  +
  +right after loading the mod_perl module, if you are using DSO, or just
  +before your mod_perl configuration section, if you're using a static
  +mod_perl build.
  +
  +
   
   
   
   
   =head1 Startup File
   
  -Next usually a startup file with Perl code is loaded:
  +A startup file with Perl code to be executed at the server startup can
  +be loaded using C<L<PerlRequire|/C_PerlRequire_>>. For example:
   
  -  PerlRequire "/home/httpd/httpd-2.0/perl/startup.pl"
  +  PerlRequire /home/httpd/perl/lib/startup.pl
   
   It's used to adjust Perl modules search paths in C<@INC>, pre-load
   commonly used modules, pre-compile constants, etc. Here is a typical
  @@ -118,9 +163,9 @@
     
     1;
   
  -In this file the C<Apache2> modules is loaded, so the 2.0 modules will
  -be found. Afterwards C<@INC> in adjusted to include non-standard
  -directories with Perl modules:
  +In this file the C<Apache2> modules is loaded, so L<the 2.0 modules
  +will be found|/Accessing_the_mod_perl_2_0_Modules>. Afterwards C<@INC>
  +in adjusted to include non-standard directories with Perl modules:
   
     use lib qw(/home/httpd/perl);
   
  @@ -140,34 +185,8 @@
   
   =head1 Server Configuration Directives
   
  -=head2 C<PerlRequire>
  -
  -  META: to be written
  -
  -=head2 C<PerlModule>
  -
  -  META: to be written
  -
  -=head2 C<PerlLoadModule>
  -
  -  META: to be written
  -  discused somewhere in docs::2.0::user::config::custom
  -
  -=head2 C<PerlSetVar>
  -
  -  META: to be written
  -
  -=head2 C<PerlAddVar>
  -
  -  META: to be written
  -
  -=head2 C<PerlSetEnv>
  -
  -  META: to be written
   
  -=head2 C<PerlPassEnv>
   
  -  META: to be written
   
   =head2 C<E<lt>PerlE<gt>> Sections
   
  @@ -182,225 +201,55 @@
   
   
   
  -=head2 C<PerlSwitches>
  -
  -Now you can pass any Perl's command line switches in I<httpd.conf>
  -using the C<PerlSwitches> directive. For example to enable warnings
  -and Taint checking add:
  -
  -  PerlSwitches -wT
  -
  -As an alternative to using C<use lib> in I<startup.pl> to adjust
  -C<@INC>, now you can use the command line switch C<-I> to do that:
  -
  -  PerlSwitches -I/home/stas/modperl
  -
  -You could also use C<-Mlib=/home/stas/modperl> which is the exact
  -equivalent as C<use lib>, but it's broken on certain platforms/version
  -(e.g. Darwin/5.6.0). C<use lib> is removing duplicated entries,
  -whereas C<-I> does not.
  -
  -
  -=head2 C<SetHandler>
  -
  -mod_perl 2.0 provides two types of C<SetHandler> handlers: C<modperl>
  -and C<perl-script>. The C<SetHandler> directive is only relevant for
  -response phase handlers. It doesn't affect other phases.
  -
  -=head3 C<modperl>
  -
  -Configured as:
  -
  -  SetHandler modperl
  -
  -The bare mod_perl handler type, which just calls the C<Perl*Handler>'s
  -callback function. If you don't need the features provided by the
  -I<perl-script> handler, with the C<modperl> handler, you can gain even
  -more performance. (This handler isn't available in mod_perl 1.0.)
  -
  -Unless the C<Perl*Handler> callback, running under the C<modperl>
  -handler, is configured with:
  -
  -  PerlOptions +SetupEnv
  -
  -or calls:
  -
  -  $r->subprocess_env;
  -
  -in a void context with no arguments (which has the same effect
  -as C<PerlOptions +SetupEnv> for the handler that called it), only
  -the following environment variables are accessible via C<%ENV>:
  -
  -=over
  -
  -=item *
  -
  -C<MOD_PERL> (always)
  -
  -=item *
  -
  -C<PATH> and C<TZ> (if you had them defined in the shell or
  -I<httpd.conf>)
   
  -=back
   
  -Therefore if you don't want to add the overhead of populating C<%ENV>,
  -when you simply want to pass some configuration variables from
  -I<httpd.conf>, consider using C<PerlSetVar> and C<PerlAddVar> instead
  -of C<PerlSetEnv> and C<PerlPassEnv>. In your code you can retrieve the
  -values using the C<dir_config()> method. For example if you set in
  -I<httpd.conf>:
  -
  -  <Location /print_env2>
  -      SetHandler modperl
  -      PerlResponseHandler Apache::VarTest
  -      PerlSetVar VarTest VarTestValue
  -  </Location>
  -
  -this value can be retrieved inside C<Apache::VarTest::handler()> with:
  -
  -  $r->dir_config('VarTest');
  -
  -Alternatively use the Apache core directives C<SetEnv> and C<PassEnv>,
  -which always populate C<r-E<gt>subprocess_env>, but this doesn't happen
  -until the Apache I<fixups> phase, which could be too late for your needs.
  -
  -=head3 C<perl-script>
  -
  -Configured as:
  -
  -  SetHandler perl-script
  -
  -Most mod_perl handlers use the I<perl-script> handler. Among other
  -things it does:
  -
  -=over
  +=head2 C<PerlAddVar>
   
  -=item *
  +  META: to be written
   
  -C<PerlOptions +GlobalRequest> is in effect only during the
  -PerlResponseHandler phase unless:
   
  -  PerlOptions -GlobalRequest
   
  -is specified.
   
  -=item *
   
  -C<PerlOptions +SetupEnv> is in effect unless:
   
  -  PerlOptions -SetupEnv
  +=head2 C<PerlLoadModule>
   
  -is specified.
  +The C<PerlLoadModule> directive is similar to
  +C<L<PerlModule|/C_PerlModule_>>, in a sense that it loads a
  +module. The difference is that it's used to implement L<new Apache
  +directives|docs::2.0::user::config::custom>. Since those
  +directives are needed during the configuration phase, this directive
  +triggers L<an early Perl startup|/Startup_Process>, as a side effect.
   
  -=item *
   
  -C<STDIN> and C<STDOUT> get tied to the request object C<$r>, which
  -makes possible to read from C<STDIN> and print directly to C<STDOUT>
  -via C<CORE::print()>, instead of implicit calls like
  -C<$r-E<gt>puts()>.
   
  -=item *
   
  -Several special global Perl variables are saved before the handler is
  -called and restored afterwards (similar to mod_perl 1.0). This
  -includes: C<%ENV>, C<@INC>, C<$/>, C<STDOUT>'s C<$|> and
C<END> blocks
  -array (C<PL_endav>).
   
  -=item *
   
  -Entries added to C<%ENV> are passed on to the C<subprocess_env> table,
  -and are thus accessible via C<r-E<gt>subprocess_env> during the later
  -C<PerlLogHandler> and C<PerlCleanupHandler> phases.
   
  -=back
  +=head2 C<PerlModule>
   
  -=head3 Examples
  +  PerlModule Foo::Bar
   
  -Let's demonstrate the differences between the C<modperl> and the
  -C<perl-script> core handlers in the following example, which
  -represents a simple mod_perl response handler which prints out the
  -environment variables as seen by it:
  +is equivalent to Perl's:
   
  -  file:MyApache/PrintEnv1.pm
  -  -----------------------
  -  package MyApache::PrintEnv1;
  -  use strict;
  -  
  -  use Apache::RequestRec (); # for $r->content_type
  -  use Apache::RequestIO ();  # for print
  -  use Apache::Const -compile => ':common';
  -  
  -  sub handler {
  -      my $r = shift;
  -  
  -      $r->content_type('text/plain');
  -      for (sort keys %ENV){
  -          print "$_ => $ENV{$_}\n";
  -      }
  -  
  -      return Apache::OK;
  -  }
  -  
  -  1;
  +  require Foo::Bar;
   
  -This is the required configuration:
  +C<PerlModule> is used to load modules using their package names.
   
  -  PerlModule MyApache::PrintEnv1
  -  <Location /print_env1>
  -      SetHandler perl-script
  -      PerlResponseHandler MyApache::PrintEnv1
  -  </Location>
  +You can pass one or more module names as arguments to C<PerlModule>:
   
  -Now issue a request to I<http://localhost/print_env1> and you should
  -see all the environment variables printed out.
  +    PerlModule Apache::DBI CGI DBD::Mysql
   
  -Here is the same response handler, adjusted to work with the
  -C<modperl> core handler:
  +Notice, that normally, the Perl startup is L<delayed|/Startup_Process>
  +until after the configuration phase.
   
  -  file:MyApache/PrintEnv2.pm
  -  ------------------------
  -  package MyApache::PrintEnv2;
  -  use strict;
  -  
  -  use Apache::RequestRec (); # for $r->content_type
  -  use Apache::RequestIO ();  # for $r->print
  -  
  -  use Apache::Const -compile => ':common';
  -  
  -  sub handler {
  -      my $r = shift;
  -  
  -      $r->content_type('text/plain');
  -      $r->subprocess_env;
  -      for (sort keys %ENV){
  -          $r->print("$_ => $ENV{$_}\n");
  -      }
  -  
  -      return Apache::OK;
  -  }
  -  
  -  1;
  +See also: C<L<PerlRequire|/C_PerlRequire_>>.
   
  -The configuration now will look as:
   
  -  PerlModule MyApache::PrintEnv2
  -  <Location /print_env2>
  -      SetHandler modperl
  -      PerlResponseHandler MyApache::PrintEnv2
  -  </Location>
   
  -C<MyApache::PrintEnv2> cannot use C<print()> and therefore uses
  -C<$r-E<gt>print()> to generate a response. Under the C<modperl> core
  -handler C<%ENV> is not populated by default, therefore
  -C<subprocess_env()> is called in a void context. Alternatively we
  -could configure this section to do:
   
  -    PerlOptions +SetupEnv
   
  -If you issue a request to I<http://localhost/print_env2>, you should
  -see all the environment variables printed out as with
  -I<http://localhost/print_env1>.
   
   
   
  @@ -736,6 +585,307 @@
   
   
   
  +=head2 C<PerlPassEnv>
  +
  +  META: to be written
  +
  +
  +
  +
  +
  +
  +=head2 C<PerlRequire>
  +
  +  PerlRequire Foo/Bar.pm
  +
  +is equivalent to Perl's:
  +
  +  require "Foo/Bar.pm";
  +
  +C<PerlRequire> is used to load files with Perl code.
  +
  +Most commonly C<PerlRequire> is used to load
  +F<L<startup.pl|/Startup_File>>, containing Perl code to be run at the
  +server startup. For example:
  +
  +    PerlRequire  /home/httpd/perl/lib/startup.pl
  +
  +A C<PerlRequire> filename argument can be absolute or relative to
  +C<ServerRoot> or a filepath in Perl's C<@INC>.
  +
  +As with any file with Perl code that gets C<use()>'d or
  +C<require()>'d, it must return a I<true> value.  To ensure that this
  +happens don't forget to add C<1;> at the end of
  +F<L<startup.pl|/Startup_File>>.
  +
  +You can pass one or more filenames as arguments to C<PerlRequire>:
  +
  +    PerlRequire path1/startup.pl path2/startup.pl
  +
  +Notice that normally, the Perl startup is L<delayed|/Startup_Process>
  +until after the configuration phase.
  +
  +See also: C<L<PerlModule|/C_PerlModule_>>.
  +
  +
  +
  +
  +
  +
  +=head2 C<PerlSetEnv>
  +
  +  META: to be written
  +
  +
  +
  +
  +
  +
  +
  +=head2 C<PerlSetVar>
  +
  +  META: to be written
  +
  +
  +
  +
  +
  +=head2 C<PerlSwitches>
  +
  +Now you can pass any Perl's command line switches in I<httpd.conf>
  +using the C<PerlSwitches> directive. For example to enable warnings
  +and Taint checking add:
  +
  +  PerlSwitches -wT
  +
  +As an alternative to using C<use lib> in I<startup.pl> to adjust
  +C<@INC>, now you can use the command line switch C<-I> to do that:
  +
  +  PerlSwitches -I/home/stas/modperl
  +
  +You could also use C<-Mlib=/home/stas/modperl> which is the exact
  +equivalent as C<use lib>, but it's broken on certain platforms/version
  +(e.g. Darwin/5.6.0). C<use lib> is removing duplicated entries,
  +whereas C<-I> does not.
  +
  +
  +
  +
  +
  +
  +
  +=head2 C<SetHandler>
  +
  +mod_perl 2.0 provides two types of C<SetHandler> handlers: C<modperl>
  +and C<perl-script>. The C<SetHandler> directive is only relevant for
  +response phase handlers. It doesn't affect other phases.
  +
  +=head3 C<modperl>
  +
  +Configured as:
  +
  +  SetHandler modperl
  +
  +The bare mod_perl handler type, which just calls the C<Perl*Handler>'s
  +callback function. If you don't need the features provided by the
  +I<perl-script> handler, with the C<modperl> handler, you can gain even
  +more performance. (This handler isn't available in mod_perl 1.0.)
  +
  +Unless the C<Perl*Handler> callback, running under the C<modperl>
  +handler, is configured with:
  +
  +  PerlOptions +SetupEnv
  +
  +or calls:
  +
  +  $r->subprocess_env;
  +
  +in a void context with no arguments (which has the same effect
  +as C<PerlOptions +SetupEnv> for the handler that called it), only
  +the following environment variables are accessible via C<%ENV>:
  +
  +=over
  +
  +=item *
  +
  +C<MOD_PERL> (always)
  +
  +=item *
  +
  +C<PATH> and C<TZ> (if you had them defined in the shell or
  +I<httpd.conf>)
  +
  +=back
  +
  +Therefore if you don't want to add the overhead of populating C<%ENV>,
  +when you simply want to pass some configuration variables from
  +I<httpd.conf>, consider using C<PerlSetVar> and C<PerlAddVar> instead
  +of C<PerlSetEnv> and C<PerlPassEnv>. In your code you can retrieve the
  +values using the C<dir_config()> method. For example if you set in
  +I<httpd.conf>:
  +
  +  <Location /print_env2>
  +      SetHandler modperl
  +      PerlResponseHandler Apache::VarTest
  +      PerlSetVar VarTest VarTestValue
  +  </Location>
  +
  +this value can be retrieved inside C<Apache::VarTest::handler()> with:
  +
  +  $r->dir_config('VarTest');
  +
  +Alternatively use the Apache core directives C<SetEnv> and C<PassEnv>,
  +which always populate C<r-E<gt>subprocess_env>, but this doesn't happen
  +until the Apache I<fixups> phase, which could be too late for your needs.
  +
  +=head3 C<perl-script>
  +
  +Configured as:
  +
  +  SetHandler perl-script
  +
  +Most mod_perl handlers use the I<perl-script> handler. Among other
  +things it does:
  +
  +=over
  +
  +=item *
  +
  +C<PerlOptions +GlobalRequest> is in effect only during the
  +PerlResponseHandler phase unless:
  +
  +  PerlOptions -GlobalRequest
  +
  +is specified.
  +
  +=item *
  +
  +C<PerlOptions +SetupEnv> is in effect unless:
  +
  +  PerlOptions -SetupEnv
  +
  +is specified.
  +
  +=item *
  +
  +C<STDIN> and C<STDOUT> get tied to the request object C<$r>, which
  +makes possible to read from C<STDIN> and print directly to C<STDOUT>
  +via C<CORE::print()>, instead of implicit calls like
  +C<$r-E<gt>puts()>.
  +
  +=item *
  +
  +Several special global Perl variables are saved before the handler is
  +called and restored afterwards (similar to mod_perl 1.0). This
  +includes: C<%ENV>, C<@INC>, C<$/>, C<STDOUT>'s C<$|> and
C<END> blocks
  +array (C<PL_endav>).
  +
  +=item *
  +
  +Entries added to C<%ENV> are passed on to the C<subprocess_env> table,
  +and are thus accessible via C<r-E<gt>subprocess_env> during the later
  +C<PerlLogHandler> and C<PerlCleanupHandler> phases.
  +
  +=back
  +
  +=head3 Examples
  +
  +Let's demonstrate the differences between the C<modperl> and the
  +C<perl-script> core handlers in the following example, which
  +represents a simple mod_perl response handler which prints out the
  +environment variables as seen by it:
  +
  +  file:MyApache/PrintEnv1.pm
  +  -----------------------
  +  package MyApache::PrintEnv1;
  +  use strict;
  +  
  +  use Apache::RequestRec (); # for $r->content_type
  +  use Apache::RequestIO ();  # for print
  +  use Apache::Const -compile => ':common';
  +  
  +  sub handler {
  +      my $r = shift;
  +  
  +      $r->content_type('text/plain');
  +      for (sort keys %ENV){
  +          print "$_ => $ENV{$_}\n";
  +      }
  +  
  +      return Apache::OK;
  +  }
  +  
  +  1;
  +
  +This is the required configuration:
  +
  +  PerlModule MyApache::PrintEnv1
  +  <Location /print_env1>
  +      SetHandler perl-script
  +      PerlResponseHandler MyApache::PrintEnv1
  +  </Location>
  +
  +Now issue a request to I<http://localhost/print_env1> and you should
  +see all the environment variables printed out.
  +
  +Here is the same response handler, adjusted to work with the
  +C<modperl> core handler:
  +
  +  file:MyApache/PrintEnv2.pm
  +  ------------------------
  +  package MyApache::PrintEnv2;
  +  use strict;
  +  
  +  use Apache::RequestRec (); # for $r->content_type
  +  use Apache::RequestIO ();  # for $r->print
  +  
  +  use Apache::Const -compile => ':common';
  +  
  +  sub handler {
  +      my $r = shift;
  +  
  +      $r->content_type('text/plain');
  +      $r->subprocess_env;
  +      for (sort keys %ENV){
  +          $r->print("$_ => $ENV{$_}\n");
  +      }
  +  
  +      return Apache::OK;
  +  }
  +  
  +  1;
  +
  +The configuration now will look as:
  +
  +  PerlModule MyApache::PrintEnv2
  +  <Location /print_env2>
  +      SetHandler modperl
  +      PerlResponseHandler MyApache::PrintEnv2
  +  </Location>
  +
  +C<MyApache::PrintEnv2> cannot use C<print()> and therefore uses
  +C<$r-E<gt>print()> to generate a response. Under the C<modperl> core
  +handler C<%ENV> is not populated by default, therefore
  +C<subprocess_env()> is called in a void context. Alternatively we
  +could configure this section to do:
  +
  +    PerlOptions +SetupEnv
  +
  +If you issue a request to I<http://localhost/print_env2>, you should
  +see all the environment variables printed out as with
  +I<http://localhost/print_env1>.
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
   
   =head1 Server Life Cycle Handlers Directives
   
  @@ -745,19 +895,23 @@
   
   =head2 C<PerlOpenLogsHandler>
   
  -See C<L<PerlOpenLogsHandler|docs::2.0::user::handlers::server/PerlOpenLogsHandler>>.
  +See
  +C<L<PerlOpenLogsHandler|docs::2.0::user::handlers::server/C_PerlOpenLogsHandler_>>.
   
   =head2 C<PerlPostConfigHandler>
   
  -See C<L<PerlPostConfigHandler|docs::2.0::user::handlers::server/PerlPostConfigHandler>>.
  +See
  +C<L<PerlPostConfigHandler|docs::2.0::user::handlers::server/C_PerlPostConfigHandler_>>.
   
   =head2 C<PerlChildInitHandler>
   
  -See C<L<PerlChildInitHandler|docs::2.0::user::handlers::server/PerlChildInitHandler>>.
  +See
  +C<L<PerlChildInitHandler|docs::2.0::user::handlers::server/C_PerlChildInitHandler_>>.
   
   =head2 C<PerlChildExitHandler>
   
  -See C<L<PerlChildExitHandler|docs::2.0::user::handlers::server/PerlChildExitHandler>>.
  +See
  +C<L<PerlChildExitHandler|docs::2.0::user::handlers::server/C_PerlChildExitHandler_>>.
   
   
   
  
  
  
  1.20      +5 -6      modperl-docs/src/docs/2.0/user/handlers/intro.pod
  
  Index: intro.pod
  ===================================================================
  RCS file: /home/cvs/modperl-docs/src/docs/2.0/user/handlers/intro.pod,v
  retrieving revision 1.19
  retrieving revision 1.20
  diff -u -u -r1.19 -r1.20
  --- intro.pod	12 Jan 2004 04:30:46 -0000	1.19
  +++ intro.pod	22 Jul 2004 05:37:30 -0000	1.20
  @@ -132,13 +132,13 @@
   
   =over
   
  -=item * C<L<PerlOpenLogsHandler|docs::2.0::user::handlers::server/PerlOpenLogsHandler>>
  +=item * C<L<PerlOpenLogsHandler|docs::2.0::user::handlers::server/C_PerlOpenLogsHandler_>>
   
  -=item * C<L<PerlPostConfigHandler|docs::2.0::user::handlers::server/PerlPostConfigHandler>>
  +=item * C<L<PerlPostConfigHandler|docs::2.0::user::handlers::server/C_PerlPostConfigHandler_>>
   
  -=item * C<L<PerlChildInitHandler|docs::2.0::user::handlers::server/PerlChildInitHandler>>
  +=item * C<L<PerlChildInitHandler|docs::2.0::user::handlers::server/C_PerlChildInitHandler_>>
   
  -=item * C<L<PerlChildExitHandler|docs::2.0::user::handlers::server/PerlChildExitHandler>>
  +=item * C<L<PerlChildExitHandler|docs::2.0::user::handlers::server/C_PerlChildExitHandler_>>
   
   =back
   
  @@ -253,7 +253,7 @@
     PerlOutputFilterHandler      VOID
   
   Note:
  -C<L<PerlChildExitHandler|docs::2.0::user::handlers::http/PerlChildExitHandler>>
  +C<L<PerlChildExitHandler|docs::2.0::user::handlers::http/C_PerlChildExitHandler_>>
   and
   C<L<PerlCleanupHandler|docs::2.0::user::handlers::http/PerlCleanupHandler>>
   are not real Apache hooks, but to mod_perl users they behave as all
  @@ -281,7 +281,6 @@
   Handlers of the type C<RUN_ALL> will be executed in the order they
   have been registered until the first handler that returns something
   other than C<Apache::OK> or C<Apache::DECLINED>.
  -
   
   For C API declarations see I<include/ap_config.h>, which includes
   other types which aren't exposed by mod_perl handlers.
  
  
  
  1.19      +7 -7      modperl-docs/src/docs/2.0/user/handlers/server.pod
  
  Index: server.pod
  ===================================================================
  RCS file: /home/cvs/modperl-docs/src/docs/2.0/user/handlers/server.pod,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -u -r1.18 -r1.19
  --- server.pod	16 Jul 2004 01:11:03 -0000	1.18
  +++ server.pod	22 Jul 2004 05:37:30 -0000	1.19
  @@ -206,7 +206,7 @@
   
   
   
  -=head2 PerlOpenLogsHandler
  +=head2 C<PerlOpenLogsHandler>
   
   The I<open_logs> phase happens just before the I<post_config> phase.
   
  @@ -271,7 +271,7 @@
   C<$s> is the base server object.
   
   The pool arguments in this phase and
  -C<L<PerlPostConfigHandler|/PerlPostConfigHandler>> are:
  +C<L<PerlPostConfigHandler|/C_PerlPostConfigHandler_>> are:
   
   =over
   
  @@ -331,9 +331,9 @@
     }
   
   As you can see, its arguments are identical to the
  -L<I<open_logs|/PerlOpenLogsHandler>> phase's handler. In this example
  -handler we don't do much, but logging that the configuration was
  -completed and returning right away.
  +L<I<open_logs|/C_PerlOpenLogsHandler_>> phase's handler. In this
  +example handler we don't do much, but logging that the configuration
  +was completed and returning right away.
   
   As you've seen in the example this handler is configured by adding to
   I<httpd.conf>:
  @@ -341,8 +341,8 @@
     PerlPostConfigHandler MyApache::StartupLog::post_config
   
   Everything that applies to
  -C<L<PerlOpenLogsHandler|/PerlOpenLogsHandler>> identically applies to
  -this handler.
  +C<L<PerlOpenLogsHandler|/C_PerlOpenLogsHandler_>> identically applies
  +to this handler.
   
   The
   C<L<add_version_component()|docs::2.0::api::Apache::ServerUtil/C_add_version_component_>>
  
  
  
  1.59      +4 -29     modperl-docs/src/docs/2.0/user/porting/compat.pod
  
  Index: compat.pod
  ===================================================================
  RCS file: /home/cvs/modperl-docs/src/docs/2.0/user/porting/compat.pod,v
  retrieving revision 1.58
  retrieving revision 1.59
  diff -u -u -r1.58 -r1.59
  --- compat.pod	16 Jul 2004 01:11:03 -0000	1.58
  +++ compat.pod	22 Jul 2004 05:37:30 -0000	1.59
  @@ -127,35 +127,10 @@
   
   =head1 Server Startup
   
  -mod_perl 1.0 was always running its startup code immediately at the
  -server startup. On a big setup it was causing a slow startup, since
  -Apache always starts and immediately restarts itself, running the
  -startup code twice. Therefore in mod_perl 2.0, by default perl won't
  -be started until after the configuration phase. So, if for example you
  -run:
  -
  -  % apachectl configtest
  -
  -none of your perl code will be executed.
  -
  -There are two cases when mod_perl 2.0 is forced to start early. First,
  -is when
  -C<L<PerlLoadModule|docs::2.0::user::config::config/C_PerlLoadModule_>>
  -is used and the second is
  -C<L<E<lt>PerlE<gt>|docs::2.0::api::Apache::PerlSections>> sections,
  -both requiring a running perl, and triggering an early server startup.
  -
  -Therefore at the moment, if you want to trigger an early startup, like
  -mod_perl 1.0 does, just add an empty
  -C<L<E<lt>PerlE<gt>|docs::2.0::api::Apache::PerlSections>> section:
  -
  -  <Perl>
  -  # trigger an early startup
  -  </Perl>
  -
  -Right after loading the mod_perl module in F<httpd.conf> if you are
  -using DSO, or just before your mod_perl configuration if you using a
  -static build.
  +mod_perl 1.0 was always running its startup code as soon as it was
  +encountered. In mod_perl 2.0, it is not always the case. Refer to the
  +L<Startup Process|docs::2.0::user::config::config/Startup_Process>
  +section.
   
   
   =head1 Code Porting
  
  
  

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-cvs-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-cvs-help@perl.apache.org


Mime
View raw message