[RELEASE CANDIDATE] please test mod_perl-1.99_12-dev.tar.gz

[Stas Bekman]

A release candidate for mod_perl-1.99_12 is available:

http://apache.org/~stas/mod_perl-1.99_12-dev.tar.gz

Please test and report any failures to this list.

If everything goes well, 1.99_12 will be released on Monday, so those who do 
mod_perl work can test on Friday and those at home over the weekend. There is 
nothing else to do on the pre-XMas weekend anyway ;)

Changes since 1.99_11:

Restore a proper behavior of all Registry handlers, but PerlRun, not
to reset %INC to forget any .pl files required during the script's
execution. [Stas]
 are now evaluating code into one distinct namespace per
container, similar to ModPerl::Registry scripts. [Philippe M. Chiasson]
Fix ModPerl::MM::WriteMakefile to use the MODPERL_CCOPTS entry from
Apache::BuildConfig, as it contains some flags added by mod_perl,
which aren't in perl_ccopts and ap_ccopts. [Stas]
Add the implementation of Apache::Connection::local_addr and
Apache::Connection::remote_addr to the Apache::compat overridable
functions. [Stas]
Apache::compat's implementation of APR::URI::unparse,
Apache::RequestRec::finfo and Apache::RequestRec::notes is now
overridable and not enabled by default. [Stas]
Apache::compat no longer enables functions which collide with mp2 API
by default. It provides two new functions: override_mp2_api and
restore_mp2_api to override and restore the original mp2 API. [Stas]
For Win32, add a .bat extension to candidates for the apxs and
apr-config utilities used in Apache::Build, so that the -x file
test can potentially succeed [Randy Kobes]
Plug a memory leak with 'perl-script' not cleaning up the temp vars
created during the override of STDIN/STDOUT to use the :Apache IO
layer [Stas]
libgtop config (needed for enabling MOD_PERL_TRACE=m) is now searched
using the gnome packaging tools if available (pkg-config for gnome-2.x
and gnome-config for gnome-1.x) [Stas]
Prevent a problem where an autovivified package (stash) prevents from
modperl_mgv to load the file with that package (until now it was
checking whether the stash existed already and skipped the loading if
that was the case). Now checking %INC and attempting to load the
module. Reporting the failure only if the module has failed to load
and the stash is not defined (so that it's possible to autovivify
packages without loading them from an external file). [Stas]
MaxClients is now overridable from the t/TEST -maxclients command line
option (it was hardcoded before). [Stas]
Postpone the allocation of the wbucket in filters till the moment it's
needed (if at all). Since non-streaming filters aren't going to use
that buffer, it's a waste to allocate/free it. [Stas]
Extend the autogenerated bug report to include information about
installed modules of special interest (which may aid in understanding
the bug report), such as CGI.pm, Apache::Request, LWP, etc. [Stas]
As the test suite keeps on growing, it takes longer time to
startup. Change the main test suite timeout to 180 secs for threaded
mpms and 120 secs for non-threaded ones. [Stas]
use plain malloc/free to allocate filter structs, since they could be
invoked hundreds of times during a single request, causing huge memory
demands if the memory is allocated from the pool, which gets destroyed
only at the end of a request. [Stas]
Fix a compilation error in APX.xs when MP_HAVE_APR_LIBS is not defined
[Fred Moyer <[EMAIL PROTECTED]>]
fix a memory leak when $filter->ctx is used [Stas]

fix buglet on Win32 (and potentially other non-Unix platforms)
where not all files were being installed under a relative Apache2
subdirectory when MP_INST_APACHE2 was specified [Randy Kobes].
deprecated APR::SockAddr::port_get()/APR::SockAddr::port_set()
replaced with direct access to the port record via
APR::SockAddr::port(). [Geoffrey Young, Stas]
deprecated APR::URI::default_port_for_scheme() replaced with
APR::URI::port_of_scheme() [Geoffrey Young]
deprecated APR::SockAddr::ip_set() and APR::NO_TIMEOUT removed.
[Geoffrey Young]
Apache::MPM->is_threaded() replaces Apache::MPM_IS_THREADED
[Geoffrey Young]
fix "PerlSetVar Foo 0" so that $r->dir_config('Foo') returns 0, not undef
[Geoffrey Young]
add Apache::MPM class, along with show() and query() class methods
[Geoffrey Young]
add :mpmq import tag to Apache::Const [Geoffrey Young]

Fix ModPerl::Registry handlers family to modify $0 only for the
duration of the handler, by localizing it [Stas]
Fix :Apache perlio's STDOUT to be reentrant + modules/include_subreq
test [Stas]
fix slurp_filename to always open the file and not try to guess
whether filename has been already opened, as there is no reliable way
to accomplish that [Stas]
Apache->can_stack_handlers is now in Apache::compat (mp2 always can
stack handlers) [Stas]
add access to $r->finfo() and related APR::Finfo methods,
such as $r->finfo->size(), $r->finfo->mtime(), and
$r->finfo->stat() [Geoffrey Young]
add :filetype import tag to APR::Const [Geoffrey Young]

 sections now properly set $0 to the name of the configuration
file they are in. [

[RELEASE CANDIDATE] please test Apache-Test-1.07-dev.tar.gz

[Stas Bekman]

A release candidate for Apache-Test-1.07 is available:

http://apache.org/~stas/Apache-Test-1.07-dev.tar.gz

Please test and report any failures to this list.

Changes since 1.06

allow conditional C module compilation on a more granular level.
#define HTTPD_TEST_REQUIRE_APACHE 2.0.49 is now recognized.
[Geoffrey Young]
Another attempt at providing a test function that verifies whether
Apache when switching from 'root' to 'nobody' or another user will be
able to access and create files under the t/ directory. This time
using perl's vars $(, $< since POSIX equivalents seem to be broken on
some systems. Also using a better test that actually tries to
write/read/execute in the path under test. [Stas]
Cleanly exit (and complain) if the default hostname resolution has
failed (usually due to a missing localhost entry in /etc/hosts) [Stas]
Fix Apache::TestConfigParse to handle quoted Include arguments [Stas]

Fix Apache::TestServer::wait_till_is_up not to bail out if the server
takes time to start and LWP is not available. [Stas]
Fix Apache::TestConfigParse to handle glob includes, like Include
conf/*.conf on RedHat [Philippe M. Chiasson]
Fix Apache::TestConfig::add_config not to append " " at the end of the
config lines. This was a problem with config sections imported from
.pm files, the appended "" made it impossible to have multi-line
directives using \ [Stas]
Fix a bug in '-port select' which was incorrectly using the same port
twice [Stas]
added bugreport and file argument options to
Apache::TestRun::generate_script() [Geoffrey Young]
__
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
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: [RELEASE CANDIDATE] please test Apache-Test-1.07-dev.tar.gz

[Steve Hay]

Stas Bekman wrote:

>A release candidate for Apache-Test-1.07 is available:
>
>http://apache.org/~stas/Apache-Test-1.07-dev.tar.gz
>
>Please test and report any failures to this list.
>
Builds OK & All tests successful on WinXP / MSVC++ 6 / Perl 5.8.2 / 
Apache 1.3.29 / mod_perl 1.29.





Radan Computational Ltd.

The information contained in this message and any files transmitted with it are 
confidential and intended for the addressee(s) only.  If you have received this 
message in error or there are any problems, please notify the sender immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is strictly 
forbidden.  Note that any views or opinions presented in this email are solely those 
of the author and do not necessarily represent those of Radan Computational Ltd.  The 
recipient(s) of this message should check it and any attached files for viruses: Radan 
Computational will accept no liability for any damage caused by any virus transmitted 
by this email.


-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: [RELEASE CANDIDATE] please test mod_perl-1.99_12-dev.tar.gz

[Steve Hay]

Stas Bekman wrote:

>A release candidate for mod_perl-1.99_12 is available:
>
>http://apache.org/~stas/mod_perl-1.99_12-dev.tar.gz
>
>Please test and report any failures to this list.
>
WinXP / MSVC++ 6 / Perl 5.8.2 (ActivePerl Build 808) / Apache 2.0.48:

Builds OK, and the top-level "nmake test" passes all tests successful, 
but the ModPerl-Registry "nmake test" fails basic.t test 12:

C:\Temp\mod_perl-1.99_12-dev\ModPerl-Registry>perl t/TEST -verbose t/basic.t
[...]
# Running under perl version 5.008002 for MSWin32
# Win32::BuildNumber 808
# Current time local: Fri Dec 19 10:27:28 2003
# Current time GMT:   Fri Dec 19 10:27:28 2003
# Using Test.pm version 1.24
[...]
# Failed test 12 in basic.t at line 66 fail #3
# testing : ModPerl::RegistryBB mod_cgi-like environment pre-set
# expected: it works
# received:
not ok 12
[...]

I'm not sure what the problem is yet.  A snapshot of the mp2 CVS that I 
took on 17 Dec passes all the tests with the same version of Perl and 
Apache.  Here are the entries that have been added to the Change log 
since I took that snapshot:

=
Restore a proper behavior of all Registry handlers, but PerlRun, not
to reset %INC to forget any .pl files required during the script's
execution. [Stas]

 are now evaluating code into one distinct namespace per
container, similar to ModPerl::Registry scripts. [Philippe M. Chiasson]

Fix ModPerl::MM::WriteMakefile to use the MODPERL_CCOPTS entry from
Apache::BuildConfig, as it contains some flags added by mod_perl,
which aren't in perl_ccopts and ap_ccopts. [Stas]

Add the implementation of Apache::Connection::local_addr and
Apache::Connection::remote_addr to the Apache::compat overridable
functions. [Stas]

Apache::compat's implementation of APR::URI::unparse,
Apache::RequestRec::finfo and Apache::RequestRec::notes is now
overridable and not enabled by default. [Stas]

Apache::compat no longer enables functions which collide with mp2 API
by default. It provides two new functions: override_mp2_api and
restore_mp2_api to override and restore the original mp2 API. [Stas]
=

Hopefully the culprit is there somewhere?

- Steve




Radan Computational Ltd.

The information contained in this message and any files transmitted with it are 
confidential and intended for the addressee(s) only.  If you have received this 
message in error or there are any problems, please notify the sender immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is strictly 
forbidden.  Note that any views or opinions presented in this email are solely those 
of the author and do not necessarily represent those of Radan Computational Ltd.  The 
recipient(s) of this message should check it and any attached files for viruses: Radan 
Computational will accept no liability for any damage caused by any virus transmitted 
by this email.


-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: index.pl won't executed with mod_perl and apache

[Ged Haywood]

Hi there,

On Thu, 18 Dec 2003, James.Q.L wrote:

> i have a directory which execute mod_perl program. i want to requestion 
> site.com/printer/ and
> index.pl get executed. however i got directory listing instead. requestiong index.pl 
> directly runs fine.
> 
> both index.pl and /www/printer are 755 on permission.

Be careful with permissions on executables which are tun by mod_perl.
Read the documentation.

> 
>   [snip]
>   DirectoryIndex index.pl
> 
> 
> with  Options +ExecCGI +MultiViews, i got this error while requesting 
> /www/printer/index
> 
> Negotiation: discovered file(s) matching request: /www/printer/index  (None could be 
> negotiated).

Where is index.pl?  If for example it's in your cgi-bin directory, have you tried

   DirectoryIndex /cgi-bin/index.pl

> running apache 2.0.40 on redhat 9.  mod_perl-1.99_07-5

You should update your Apache and mod_perl, those are very out of date.

73,
Ged.


-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

VirtualHost + PerlSetVar

[Paul G. Weiss]

I have something like this:

PerlModule Module


PerlSetVar abc def

Module->start;


and in Module.pm

use Apache::ServerUtil ()

...

sub startup
{
   my $value = Apache->server->dir_config("abc");
...
}
and lo and behold - $value is undef !  However, if I take the PerlSetVar 
and move it outside the VirtualHost, then $value is "def".

I'm using 2.0.47 + 1.99_10, only because I have rpms build for them (for 
RH9).  Has this problem been noticed and fixed in the latest release?  I 
don't see any mention of it in the mail archives.

-Paul Weiss

--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: [RELEASE CANDIDATE] please test mod_perl-1.99_12-dev.tar.gz

[Swen Schillig]

Steve, Stas

I experienced the same on Linux-Intel ( Apache 2.0.48, Perl 5.8.2)
having a threaded MPM (worker).
Everything works fine with MPM (prefork) on Linux-Intel and Linux-PPC.

I assume Steve is running the Apache under the special NT MPM and not in
prefork.
So maybe there's something not really thread-safe (wild-guess).

Maybe this helps.

Mit freundlichen Grüßen / Best Regards
Swen Schillig



--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: VirtualHost + PerlSetVar

[Paul G. Weiss]

More interesting info...

First of all, I've upgraded to mod_perl-1.99_11 with no change.

Second, I've determined that the per-VirtualHost values are visible in the 
request, but not during server startup.

Here's the situation in an (I hope) easy to reproduce format:

-- config --

PerlRequire /var/www/perl/startup.pl
# set value in global scope
PerlSetVar foo global

SetHandler perl-script
PerlHandler Module


# set value in virtual host scope
PerlSetVar foo virtual

Module->start;


-- /var/www/perl/startup.pl --

use Apache2 ();
use Apache::RequestIO ();
use Apache::ServerUtil ();
use Apache::RequestRec ();
use Apache::Const -compile => ':common';
package Module;

sub start {
 my $s = Apache->server;
 print "Module->start sees foo=" . $s->dir_config('foo') . "\n";
}
sub handler {
 my $r = shift;
 my $value = $r->dir_config('foo');
 $r->content_type('text/plain');
 $r->print("Request sees foo=$value\n");
 return Apache::OK;
}
1;

-- the output --

[EMAIL PROTECTED] pgweiss]# /usr/sbin/apachectl start
Module->start sees foo=global
[EMAIL PROTECTED] pgweiss]# access handle w/o virtual host
[EMAIL PROTECTED] pgweiss]# lwp-request http://localhost/module
foo=global
[EMAIL PROTECTED] pgweiss]# now access handle w/ virtual host
[EMAIL PROTECTED] pgweiss]# lwp-request http://localhost:9900/module
foo=virtual
[EMAIL PROTECTED] pgweiss]#
The reason this is important is that I'm trying to get Apache::PageKit to 
run in virtual hosts, and it depends on the availability of PerlSetVar 
variables on startup.

-Paul

On Fri, 19 Dec 2003 06:28:10 -0500, Paul G. Weiss <[EMAIL PROTECTED]> wrote:

I have something like this:

PerlModule Module


PerlSetVar abc def

Module->start;


and in Module.pm

use Apache::ServerUtil ()

...

sub startup
{
my $value = Apache->server->dir_config("abc");
...
}
and lo and behold - $value is undef !  However, if I take the PerlSetVar 
and move it outside the VirtualHost, then $value is "def".

I'm using 2.0.47 + 1.99_10, only because I have rpms build for them (for 
RH9).  Has this problem been noticed and fixed in the latest release?  I 
don't see any mention of it in the mail archives.

-Paul Weiss
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: [RELEASE CANDIDATE] please test mod_perl-1.99_12-dev.tar.gz

[Stas Bekman]

Steve Hay wrote:
Stas Bekman wrote:


A release candidate for mod_perl-1.99_12 is available:

http://apache.org/~stas/mod_perl-1.99_12-dev.tar.gz

Please test and report any failures to this list.

WinXP / MSVC++ 6 / Perl 5.8.2 (ActivePerl Build 808) / Apache 2.0.48:

Builds OK, and the top-level "nmake test" passes all tests successful, 
but the ModPerl-Registry "nmake test" fails basic.t test 12:

C:\Temp\mod_perl-1.99_12-dev\ModPerl-Registry>perl t/TEST -verbose t/basic.t
[...]
# Running under perl version 5.008002 for MSWin32
# Win32::BuildNumber 808
# Current time local: Fri Dec 19 10:27:28 2003
# Current time GMT:   Fri Dec 19 10:27:28 2003
# Using Test.pm version 1.24
[...]
# Failed test 12 in basic.t at line 66 fail #3
# testing : ModPerl::RegistryBB mod_cgi-like environment pre-set
# expected: it works
# received:
not ok 12
[...]
I'm not sure what the problem is yet.  A snapshot of the mp2 CVS that I 
took on 17 Dec passes all the tests with the same version of Perl and 
Apache.  Here are the entries that have been added to the Change log 
since I took that snapshot:
...
Hopefully the culprit is there somewhere?
The most recent change was the culprit.

> =
> Restore a proper behavior of all Registry handlers, but PerlRun, not
> to reset %INC to forget any .pl files required during the script's
> execution. [Stas]
> =
I have noticed that while porting the registry I've applied the perlrun 
feature to all registry handlers (i.e. remove any .pl files from %INC at the 
end of each run), so I've restored it to how it is in mod_perl 1.0. I've fixed 
the failing test and uploaded an updated version. Same URL as before. Please 
try again.

Thank you Steve and Swen.

__
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
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Debugging mod_perl ???

[Michael D Schleif]

Ref: 
 

 

Several places mention perldb command `w' (window).  Is that command
missing from more recent versions of perldb?

   Loading DB routines from perl5db.pl version 1.19

 DB<1> w
   Adding a watch-expression requires an expression

Yes, there is `l' and `-' -- however, these show lines only _after_ or
_before_ the current line.  `w' in the reference webpage results in a
window with lines _before_ and _after_ the current line, which is ideal
for establishing context.

How can I do this with my perldb?

-- 
Best Regards,

mds
mds resource
877.596.8237
-
Dare to fix things before they break . . .
-
Our capacity for understanding is inversely proportional to how much
we think we know.  The more I know, the more I know I don't know . . .
--


pgp0.pgp
Description: PGP signature

Prematch and postmatch regex vars and performance

[publiustemp-modperllist]

Hi all,

I'm researching some performance problems with one of our Web sites and
stumbled across some legacy code that's getting pulled into our system.
This code uses $` and $' variables with regular expression matches.
>From the perlre docs (emphasis mine):

WARNING: Once Perl sees that you need one of "$&", "$`", or "$'"
*anywhere in the program*, it has to provide them for every pattern
match. This may substantially slow your program.

In fact, in tests that I've run, it appears that the mere existence of
these variables will trigger this behavior, regardless of whether or
not the code that accesses them will be executed. Removing these
variables seems to consistently get me a ten percent bump in regex
performance.

Since mod_perl is a persistent Perl interpreter embedded in the Web
server, it seems to me that any reference to these variables will
impact all regex matches in a mod_perl environment, regardless of
whether or not my code actually uses those variables. Is this the case?
I don't know enough about benchmarking snippets in a mod_perl
environment to easily verify this.

Cheers,
Ovid

=
Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm
Ovid   http://www.perlmonks.org/index.pl?node_id=17000
Web Programming with Perl  http://users.easystreet.com/ovid/cgi_course/

-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: Apache::DB - Undefined subroutine ???

[Stas Bekman]

Michael D Schleif wrote:
[...]
Yes, that is further down on that page, and I meant that I am working
with the whole Perl debugging section.  I thought -- erroneously? --
that I could PerlRequire the `use' and `init' stuff.  How can I do that?
Sure you can. it's better to keep it in httpd.conf so it's not hidden in the 
startup file.

The suggested config section should work just fine:

 
 use Apache::DB ();
 Apache::DB->init;
 
 
 PerlFixupHandler Apache::DB
 
 PerlModule Apache::Status
 
 PerlHandler Apache::Status
 SetHandler perl-script
 
make sure that you do *not* preload Apache::Status before you init 
Apache::DB


I do not know why problems persist: `Undefined subroutine
&Apache::Status::handler called.'  Perhaps, a look at my httpd.conf
will help?
   

NOTE: That server is *not* the one in question ;>
what about startup.pl in 'PerlRequire startup.pl'? Make sure you don't load it 
from startup.pl as well.

I want to setup Apache::DB in such a way that it is easily turned OFF,
since most of the time I do not want it interfering.
You already did that as the docs suggest:



use Apache::DB ();
Apache::DB->init;


PerlFixupHandler Apache::DB


Only when you start the server with httpd -DPERLDB (and -X) it'll work.

__
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
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

RE: using pnotes to store/retrieve Class::DBI objects?

[Eric J. Hansen]

After looking at this further, it turns out that Perrin's suggested
code *does* work, but only in the PerlResponseHandler or earlier
stages.  And unfortunately, I mis-stated the original problem...  which is
that I am trying to retrieve that pnotes object (Class::DBI instance)
in _PerlCleanupHandler_ (not PerlResponseHandler as originally stated).

When I try to retrieve this Class::DBI object from the Cleanup Handler,
the pnotes values are totally gone.  However, regular scalers that I've
put in 'notes' are still there. Perhaps pnotes has (by design) already
been cleaned up prior to the PerlCleanupHandler stage?

FYI, this happens whether or not I define PerlCleanupHandler in the
server conf file or dynamically via $r->push_handlers.

thanks
Eric



Perrin last wrote:
> > On further investigation, the problem seems to be that the 
> object is 
> > losing its namespace.
> 
> That's not it.  Many people have successfully stored objects 
> in pnotes 
> before.
> 
> > In the first handler (where I define
> > the object and store it in pnotes) I'm logging the value of "ref 
> > $dbrecord" and getting the correct Class::Object value.  In 
> the second 
> > handler (where I retrieve the object from pnotes and try to 
> access a 
> > method), I'm logging the "ref $dbrecord" and getting a blank ("").
> 
> Are you certain that you have the same request object in both 
> cases?  If 
> your first handler is handling an index request, the second 
> one might be 
> a totally different request object.  Check $r->is_initial_req().



-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: Request object getting switched

[Stas Bekman]

Eric Sammer wrote:
All:

Apache 1.3.28, MP 1.29, Perl 5.8.0

I'm having a problem with $r being different between request phases of 
the same request. Specifically, $r->pnotes() is missing a parameter that 
is packed into it by an earlier handler. Here's the setup:

In virtual host context:

PerlInitHandler - Does some processing and sets an item in $r->pnotes(). 
$r comes directly from handler()'s first arg.

PerlAccessHandler - Does some access processing and uses variable from 
$r->pnotes().

In Location context at /app
PerlHandler - Uses $r with no problems.
In this scenario it works fine. The application at '/app' gets the 
variables from the previous two request phases.

I also have a PerlHandler in a Files context (handling all files with a 
specific extension). None of these files are within /app so there's no 
collision with the PerlHandler or conf merging problems. The 
$r->pnotes() table in this handler is always empty. The problem is 
reproducible always.

All handlers get $r from shifting off args from handler() (none of them 
use Apache->request()). Is there some reason why $r would turn up 
different? I've done similar things before and haven't had a problem. 
I'm quite sure it's a minor oversight on my part.

TIA and any help is appreciated.
You have this problem when running a sub-request. In which case you need to do:

my $pnote = $r->main ? $r->main->pnotes('foo') : $r->pnotes('foo');

http://perl.apache.org/docs/1.0/api/Apache.html#_r_E_gt_main
http://perl.apache.org/docs/1.0/guide/snippets.html#Passing_Notes_Between_mod_perl_and_other__non_Perl__Apache_Modules
__
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
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: Request object getting switched

[Eric Sammer]

Stas Bekman wrote:
You have this problem when running a sub-request. In which case you need 
to do:

my $pnote = $r->main ? $r->main->pnotes('foo') : $r->pnotes('foo');

http://perl.apache.org/docs/1.0/api/Apache.html#_r_E_gt_main
http://perl.apache.org/docs/1.0/guide/snippets.html#Passing_Notes_Between_mod_perl_and_other__non_Perl__Apache_Modules 
Oddly enough, the object is not in $r->main->pnotes() either. On the 
other hand, I try $r->prev->pnotes() and it *is* there and works. The 
handler isn't redirecting or anything - am I wrong in assuming it should 
be main rather than prev? The way it is now seems as if it's a redirect 
rather than a subrequest.

Either way, it works with $r->prev() even if I'm unclear about why. Once 
again, thanks Stas!
--
Eric Sammer
[EMAIL PROTECTED]
http://www.ineoconcepts.com

--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: Request object getting switched

[Stas Bekman]

Eric Sammer wrote:
Stas Bekman wrote:

You have this problem when running a sub-request. In which case you 
need to do:

my $pnote = $r->main ? $r->main->pnotes('foo') : $r->pnotes('foo');

http://perl.apache.org/docs/1.0/api/Apache.html#_r_E_gt_main
http://perl.apache.org/docs/1.0/guide/snippets.html#Passing_Notes_Between_mod_perl_and_other__non_Perl__Apache_Modules 


Oddly enough, the object is not in $r->main->pnotes() either. On the 
other hand, I try $r->prev->pnotes() and it *is* there and works. The 
handler isn't redirecting or anything - am I wrong in assuming it should 
be main rather than prev? The way it is now seems as if it's a redirect 
rather than a subrequest.

Either way, it works with $r->prev() even if I'm unclear about why. Once 
again, thanks Stas!
Yes, sorry, it's $r->prev(), was writing from memory...

Your handler doesn't redirect, but Apache does / -> /index.tt is a subrequest.

__
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
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: Request object getting switched

[Eric Sammer]

Stas Bekman wrote:
Yes, sorry, it's $r->prev(), was writing from memory...
Got cha. Just wanted to make sure it wasn't something unexplained.

Your handler doesn't redirect, but Apache does / -> /index.tt is a 
subrequest.
Right. I was afraid that it was *supposed* to be accessible via 
$r->main() rather than $r->prev() and something was wrong.

Again, thanks for all the help!
--
Eric Sammer
[EMAIL PROTECTED]
http://www.ineoconcepts.com
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: Prematch and postmatch regex vars and performance

[Stas Bekman]

[EMAIL PROTECTED] wrote:
Hi all,

I'm researching some performance problems with one of our Web sites and
stumbled across some legacy code that's getting pulled into our system.
This code uses $` and $' variables with regular expression matches.
From the perlre docs (emphasis mine):
WARNING: Once Perl sees that you need one of "$&", "$`", or "$'"
*anywhere in the program*, it has to provide them for every pattern
match. This may substantially slow your program.
In fact, in tests that I've run, it appears that the mere existence of
these variables will trigger this behavior, regardless of whether or
not the code that accesses them will be executed. Removing these
variables seems to consistently get me a ten percent bump in regex
performance.
Since mod_perl is a persistent Perl interpreter embedded in the Web
server, it seems to me that any reference to these variables will
impact all regex matches in a mod_perl environment, regardless of
whether or not my code actually uses those variables. Is this the case?
I don't know enough about benchmarking snippets in a mod_perl
environment to easily verify this.
That's correct.

See:
http://search.cpan.org/~andk/Devel-SawAmpersand-0.30/lib/Devel/SawAmpersand.pm
perl -MDevel::SawAmpersand -le '$&; Devel::SawAmpersand::sawampersand() && die 
"oops"'

Devel::FindAmpersand from the same package will tell you where it was defined 
when the process exits.

__
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
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: Debugging mod_perl ???

[Stas Bekman]

Michael D Schleif wrote:
Ref: 
 

 
Several places mention perldb command `w' (window).  Is that command
missing from more recent versions of perldb?
   Loading DB routines from perl5db.pl version 1.19

 DB<1> w
   Adding a watch-expression requires an expression
Yes, there is `l' and `-' -- however, these show lines only _after_ or
_before_ the current line.  `w' in the reference webpage results in a
window with lines _before_ and _after_ the current line, which is ideal
for establishing context.
How can I do this with my perldb?
Unfortunately perl 5.8 has mucked around with letters and redefined a bunch of 
them. Using 'h' will tell you what are the new commands:

  DB<1> h
List/search source lines:   Control script execution:
  l [ln|sub]  List source codeT   Stack trace
  - or .  List previous/current line  s [expr]Single step [in expr]
  v [line]View around linen [expr]Next, steps over subs
so you are after 'v' in 5.8+, what used to be 'w' in 5.6

I'll update the online docs.

__
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
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: VirtualHost + PerlSetVar

[Stas Bekman]

Paul G. Weiss wrote:
[...]
The reason this is important is that I'm trying to get Apache::PageKit 
to run in virtual hosts, and it depends on the availability of 
PerlSetVar variables on startup.
First of all, why do you expect PerlSetVar to be available at the server 
startup? The config phase is not completed and the value can be overriden 
several times by the end of config.

Second, Apache->server always gives you the global (top-level) server, so of 
course once you move PerlSetVar outside of vhost, you get to see its value.

I think using PerlPostConfigHandler will let you achieve what you want:

PerlRequire /var/www/perl/startup.pl
# set value in global scope
PerlSetVar foo global

SetHandler perl-script
PerlHandler Module


# set value in virtual host scope
PerlSetVar foo virtual
PerlModule Module
PerlPostConfigHandler Module::start

package Module;

sub start {
 my($conf_pool, $log_pool, $temp_pool, $s) = @_;
 print "Module->start sees foo=" . $s->dir_config('foo') . "\n";
}
(this code is untested, but I think it should do what you want)

The difference is that you get the correct $s object here (which you can't get 
during the config phase).  Sounds like your case can be a useful addition to 
the existing example:
http://perl.apache.org/docs/2.0/user/handlers/server.html#PerlPostConfigHandler

__
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
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Storing variables in memory

[Chris Ochs]

I have an application where known users connect, and normally I do a db
query to get their configuration information.  What I would like to do is
preload all of this information into memory, say into a global hash where
all the mod perl processes can access it.

I could have each process load the data the first time it runs and stick it
into a global hash.

And since the primary goal is making the program faster, any alternatives
that would take longer than a database select wouldnt' do me any good.

Any ideas?



-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: using pnotes to store/retrieve Class::DBI objects?

[Stas Bekman]

Eric J. Hansen wrote:
After looking at this further, it turns out that Perrin's suggested
code *does* work, but only in the PerlResponseHandler or earlier
stages.  And unfortunately, I mis-stated the original problem...  which is
that I am trying to retrieve that pnotes object (Class::DBI instance)
in _PerlCleanupHandler_ (not PerlResponseHandler as originally stated).
When I try to retrieve this Class::DBI object from the Cleanup Handler,
the pnotes values are totally gone.  However, regular scalers that I've
put in 'notes' are still there. Perhaps pnotes has (by design) already
been cleaned up prior to the PerlCleanupHandler stage?
Right, here is the fix:

Index: src/modules/perl/modperl_config.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_config.c,v
retrieving revision 1.71
diff -u -r1.71 modperl_config.c
--- src/modules/perl/modperl_config.c   23 Oct 2003 18:34:51 -  1.71
+++ src/modules/perl/modperl_config.c   20 Dec 2003 02:46:41 -
@@ -288,12 +288,12 @@
 apr_status_t retval;
 MP_dRCFG;
+retval = modperl_callback_per_dir(MP_CLEANUP_HANDLER, r, MP_HOOK_RUN_ALL);
+
 if (rcfg->pnotes) {
 SvREFCNT_dec(rcfg->pnotes);
 rcfg->pnotes = Nullhv;
 }
-
-retval = modperl_callback_per_dir(MP_CLEANUP_HANDLER, r, MP_HOOK_RUN_ALL);
 /* undo changes to %ENV caused by +SetupEnv, perl-script, or
  * $r->subprocess_env, so the values won't persist  */
__
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
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: [mp1] Bug + Patch: Improper signal handler restoration with sigaction()

[Stas Bekman]

Douglas K. Fischer wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I recently encountered problems with stuck Apache processes that upon 
analysis can be traced back to the signal handler saving/restoration code 
within mod_perl. This issue appears to have been originally reported by 
Charles Jardine in Oct 2002 (see included original e-mail from mod_perl 
user's list).

The problem stems from the use of Perl's rsignal_state() and rsignal() 
functions to save and restore, respectively, the SIGALRM signal handler 
that was installed by Apache. If the OS does not have sigaction() 
(requiring Perl to use signal() instead), this is fine, as the only 
arguments to signal() are the signal number and the handler. However, with 
sigaction(), there are other fields, with the flags being the most 
important for this particular issue, especially SA_RESTART. Using 
rsignal_state() and rsignal() does nothing to preserve these other fields; 
in fact, rsignal() will specifically set SA_RESTART if it is defined (in 
Perl 5.6.x at least).

A better way to handle this for systems with sigaction() is to use the 
rsignal_save() and rsignal_restore() functions in Perl, which will properly 
save and restore the sigaction structure, thereby preserving the flags et 
al. While Perl 5.8.x does not set SA_RESTART (and thereby avoids the 
specific problem I encountered), saving and restoring the entire sigaction 
structure seems to me to be "the right thing to do".
Thank you for the detailed report and the patch, Douglas. It's on the mp1 TODO 
list now.

Any idea whether mod_perl 2.0 may have any of these issues? In particular I'm 
after tests that we can reproduce the problem with.

Thanks.

__
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
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Who is adding .. 'document has moved..'?

[justin]

Using Registry..

When using text/vnd.wap.wml

$r->status(302)
$r->content_type($encoding);
$r->header_out('Location' => "...");

and adding, via print, my own empty document
(a minimal wml card)

apache+modperl persists in adding ..

 
302 Found  Found The document has
moved here. 

after the end of my card, which breaks Nokia WAP proxies

Who is adding this on, how do I stop it getting added?

thanks!

-Justin


-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html