Manual Pages for UNIX Darwin command on man Apache2::compat

apachemoadpapcehrel-m1o0d1.p1e~r2Ul:s-:e1mr0o1dC.o1pn~et2rr:li:-bm2uo.td0e.dp2e:Pr:eldr-ol2c.sD0:o.:c2au:pm:ied:no:tcAaspt:ai:coahnpei2::::Acpoamcphaet2(:3:)compat(3)

NAME

Apache2::compat - 1.0 backward compatibility functions deprecated in

2.0 SSyynnooppssiiss

# either add at the very beginning of startup.pl

use Apache2::compat;

# or httpd.conf

PerlModule Apache2::compat

# override and restore compat functions colliding with mp2 API

Apache2::compat::overridemp2api('Apache2::Connection::localaddr');

my ($localport, $localaddr) = sockaddrin($c->localaddr);

Apache2::compat::restoremp2api('Apache2::Connection::localaddr');

DDeessccrriippttiioonn

"Apache2::compat" provides modperl 1.0 compatibility layer and can be

used to smooth the transition process to modperl 2.0. It includes functions that have changed their API or were removed in modperl 2.0. If your code uses any of those functions, you should load this module at the server startup, and everything should work as it did in 1.0. If it doesn't please report the bug, but before you do that please make sure that your code does work properly under modperl 1.0. However, remember, that it's implemented in pure Perl and not C, therefore its functionality is not optimized and it's the best to try to port your code not to use deprecated functions and stop using the compatibility layer. CCoommppaattiibbiilliittyy FFuunnccttiioonnss CCoolllliiddiinngg wwiitthh mmooddppeerrll 22..00 AAPPII

Most of the functions provided by Apache2::compat don't interfere with

modperl 2.0 API. However there are several functions which have the same name in the modperl 1.0 and modperl 2.0 API, accept the same number of arguments, but either the arguments themselves aren't the same or the return values are different. For example the modperl 1.0 code: require Socket;

my $sockaddrin = $c->localaddr;

my ($localport, $localaddr) = Socket::sockaddrin($sockaddrin);

should be adjusted to be: require Apache2::Connection; require APR::SockAddr;

my $sockaddr = $c->localaddr;

my ($localport, $localaddr) = ($sockaddr->port, $sockaddr->ipget);

to work under modperl 2.0. As you can see in modperl 1.0 API localaddr() was returning a SOCKADDRIN object (see the Socket perl manpage), in modperl 2.0 API it returns an "APR::SockAddr" object, which is a totally different

beast. If Apache2::compat overrides the function "localaddr()" to be

back-compatible with modperl 1.0 API. Any code that relies on this

function to work as it should under modperl 2.0 will be broken. Therefore the solution is not to override "localaddr()" by default. Instead a special API is provided which overrides colliding functions only when needed and which can be restored when no longer needed. So for example if you have code from modperl 1.0:

my ($localport, $localaddr) = Socket::sockaddrin($c->localaddr);

and you aren't ready to port it to to use the mp2 API:

my ($localport, $localaddr) = ($c->localaddr->port,

$c->localaddr->ipget);

you could do the following:

Apache2::compat::overridemp2api('Apache2::Connection::localaddr');

my ($localport, $localaddr) = Socket::sockaddrin($c->localaddr);

Apache2::compat::restoremp2api('Apache2::Connection::localaddr');

Notice that you need to restore the API as soon as possible. Both "overridemp2api()" and "restoremp2api()" accept a list of functions to operate on. AAvvaaiillaabbllee OOvveerrrriiddaabbllee FFuunnccttiioonnss At the moment the following colliding functions are available for overriding: +o "Apache2::RequestRec::notes" +o "Apache2::RequestRec::filename" +o "Apache2::RequestRec::finfo" +o "Apache2::Connection::localaddr" +o "Apache2::Connection::remoteaddr" +o "Apache2::Util::httime" +o "APR::URI::unparse" UUssee iinn CCPPAANN MMoodduulleess

The short answer: DDoo nnoott uussee "Apache2::compat" in CPAN modules.

The long answer:

"Apache2::compat" is useful during the modperl 1.0 code porting.

Though remember that it's implemented in pure Perl. In certain cases it overrides modperl 2.0 methods, because their API is very different and doesn't map 1:1 to modperl 1.0. So if anything, not under user's

control, loads "Apache2::compat" user's code is forced to use the

potentially slower method. Which is quite bad.

Some users may choose to keep using "Apache2::compat" in production and

it may perform just fine. Other users will choose not to use that module, by porting their code to use modperl 2.0 API. However it should be users' choice whether to load this module or not and not to be enforced by CPAN modules. If you port your CPAN modules to work with modperl 2.0, you should follow the porting Perl and XS module guidelines.

Users that are stuck with CPAN modules preloading "Apache2::compat",

can prevent this from happening by adding

$INC{'Apache2/compat.pm'} = FILE;

at the very beginning of their startup.pl. But this will most certainly break the module that needed this module. AAPPII You should be reading the modperl 1.0 API docs for usage of the methods and functions in this package, since what this module is doing is providing a backwards compatibility and it makes no sense to duplicate documentation. Another important document to read is: Migrating from modperl 1.0 to modperl 2.0 which covers all modperl 1.0 constants, functions and methods that have changed in modperl 2.0. SSeeee AAllssoo modperl 2.0 documentation. CCooppyyrriigghhtt modperl 2.0 and its core modules are copyrighted under The Apache Software License, Version 2.0. AAuutthhoorrss The modperl development team and numerous contributors.