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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
