cvs commit: modperl-2.0/ModPerl-Registry/lib/ModPerl PerlRun.pm Registry.pm RegistryBB.pm
stas2002/08/14 07:27:03
Modified:ModPerl-Registry/lib/ModPerl PerlRun.pm Registry.pm
RegistryBB.pm
Log:
use the base pragma instead of ISA
Revision ChangesPath
1.2 +1 -2 modperl-2.0/ModPerl-Registry/lib/ModPerl/PerlRun.pm
Index: PerlRun.pm
===
RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/lib/ModPerl/PerlRun.pm,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- PerlRun.pm9 Oct 2001 12:47:38 - 1.1
+++ PerlRun.pm14 Aug 2002 14:27:03 - 1.2
-8,8 +8,7
our $VERSION = '1.99';
-use ModPerl::RegistryCooker;
-@ModPerl::PerlRun::ISA = qw(ModPerl::RegistryCooker);
+use base qw(ModPerl::RegistryCooker);
# META: prototyping ($$) segfaults on request
sub handler {
1.3 +1 -2 modperl-2.0/ModPerl-Registry/lib/ModPerl/Registry.pm
Index: Registry.pm
===
RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/lib/ModPerl/Registry.pm,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Registry.pm 22 May 2002 05:41:48 - 1.2
+++ Registry.pm 14 Aug 2002 14:27:03 - 1.3
-8,8 +8,7
our $VERSION = '1.99';
-use ModPerl::RegistryCooker;
-@ModPerl::Registry::ISA = qw(ModPerl::RegistryCooker);
+use base qw(ModPerl::RegistryCooker);
sub handler {
my $class = (_ = 2) ? shift : __PACKAGE__;
1.3 +1 -2 modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryBB.pm
Index: RegistryBB.pm
===
RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryBB.pm,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- RegistryBB.pm 22 May 2002 05:41:48 - 1.2
+++ RegistryBB.pm 14 Aug 2002 14:27:03 - 1.3
-8,8 +8,7
our $VERSION = '1.99';
-use ModPerl::RegistryCooker;
-@ModPerl::RegistryBB::ISA = qw(ModPerl::RegistryCooker);
+use base qw(ModPerl::RegistryCooker);
# META: prototyping ($$) segfaults on request
sub handler {
cvs commit: modperl-2.0/ModPerl-Registry/t basic.t
stas2002/08/14 07:27:45
Modified:ModPerl-Registry/t basic.t
Log:
reformat the code according to the spec
Revision ChangesPath
1.6 +24 -24modperl-2.0/ModPerl-Registry/t/basic.t
Index: basic.t
===
RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/t/basic.t,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- basic.t 22 May 2002 05:40:48 - 1.5
+++ basic.t 14 Aug 2002 14:27:45 - 1.6
-6,11 +6,11
use Apache::TestRequest qw(GET_BODY HEAD);
-my %modules =
-(registry= 'ModPerl::Registry',
- registry_bb = 'ModPerl::RegistryBB',
- perlrun = 'ModPerl::PerlRun',
-);
+my %modules = (
+registry= 'ModPerl::Registry',
+registry_bb = 'ModPerl::RegistryBB',
+perlrun = 'ModPerl::PerlRun',
+);
my aliases = sort keys %modules;
-21,10 +21,10
my $url = /$alias/basic.pl;
ok t_cmp(
- ok,
- GET_BODY($url),
- $modules{$alias} basic cgi test,
-);
+ok,
+GET_BODY($url),
+$modules{$alias} basic cgi test,
+);
}
# test non-executable bit
-32,10 +32,10
my $url = /$alias/not_executable.pl;
ok t_cmp(
- 403 Forbidden,
- HEAD($url)-status_line(),
- $modules{$alias} non-executable file,
-);
+403 Forbidden,
+HEAD($url)-status_line(),
+$modules{$alias} non-executable file,
+);
}
# test environment pre-set
-43,22 +43,22
my $url = /$alias/env.pl?foo=bar;
ok t_cmp(
- foo=bar,
- GET_BODY($url),
- $modules{$alias} mod_cgi-like environment pre-set,
-);
+foo=bar,
+GET_BODY($url),
+$modules{$alias} mod_cgi-like environment pre-set,
+);
}
-# chdir is not safe yet!
-#
-# require (actually chdir test)
+# XXX: chdir is not safe yet!
+
+## require (actually chdir test)
#for my $alias (aliases) {
#my $url = /$alias/require.pl;
#ok t_cmp(
-# it works,
-# GET_BODY($url),
-# $modules{$alias} mod_cgi-like environment pre-set,
-#);
+#it works,
+#GET_BODY($url),
+#$modules{$alias} mod_cgi-like environment pre-set,
+#);
#}
cvs commit: modperl-2.0/ModPerl-Registry/lib/ModPerl RegistryCooker.pm
stas2002/08/14 07:38:07
Modified:ModPerl-Registry/lib/ModPerl RegistryCooker.pm
Log:
syncing with 1.0's registry: geoff's patch to set error-notes on error
Revision ChangesPath
1.12 +7 -2 modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryCooker.pm
Index: RegistryCooker.pm
===
RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryCooker.pm,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- RegistryCooker.pm 14 Aug 2002 12:52:37 - 1.11
+++ RegistryCooker.pm 14 Aug 2002 14:38:07 - 1.12
-205,7 +205,7
my $r = $o-[REQ];
unless (-r $r-finfo -s _) {
-$r-log_error($$: $o-[FILENAME] not found or unable to stat);
+xlog_error($r, $$: $o-[FILENAME] not found or unable to stat);
return Apache::NOT_FOUND;
}
-649,7 +649,7
sub error_check {
my $o = shift;
if ($ and substr($,0,4) ne at ) {
- $o-[REQ]-log_error($$: $o-[CLASS]: `$');
+ xlog_error($o-[REQ], $$: $o-[CLASS]: `$');
$@{$o-[REQ]-uri} = $;
#$ = ''; #XXX fix me, if we don't do this Apache::exit() breaks
return Apache::SERVER_ERROR;
-688,6 +688,11
$o-[REQ]-log_error($$: $o-[CLASS]: . join '', _);
}
+sub xlog_error {
+my($r, $msg) = _;
+$r-log_error($msg);
+$r-notes('error-notes', $msg);
+}
1;
__END__
cvs commit: modperl-2.0/xs/Apache/RequestIO Apache__RequestIO.h
stas2002/08/14 07:54:47
Modified:src/modules/perl modperl_filter.c modperl_log.h
t/response/TestAPI aplog.pm
xs/Apache/Log Apache__Log.h
xs/Apache/RequestIO Apache__RequestIO.h
Log:
eliminate the use of the deprecated APLOG_NOERRNO macro
Revision ChangesPath
1.37 +1 -1 modperl-2.0/src/modules/perl/modperl_filter.c
Index: modperl_filter.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_filter.c,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -r1.36 -r1.37
--- modperl_filter.c 29 Jun 2002 20:38:33 - 1.36
+++ modperl_filter.c 14 Aug 2002 14:54:47 - 1.37
-18,7 +18,7
return APR_SUCCESS; /* XXX: HTTP_MOVED_TEMPORARILY ? */
}
else if (status != OK) {
-ap_log_error(APLOG_MARK, APLOG_WARNING|APLOG_NOERRNO,
+ap_log_error(APLOG_MARK, APLOG_WARNING,
0, r-server, %s did not send an HTTP header,
r-uri);
}
1.10 +5 -5 modperl-2.0/src/modules/perl/modperl_log.h
Index: modperl_log.h
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_log.h,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- modperl_log.h 21 Jun 2002 20:30:27 - 1.9
+++ modperl_log.h 14 Aug 2002 14:54:47 - 1.10
-39,19 +39,19
void modperl_trace_level_set(server_rec *s, const char *level);
#define modperl_log_warn(s,msg) \
-ap_log_error(APLOG_MARK, APLOG_WARNING|APLOG_NOERRNO, 0, s, %s, msg)
+ap_log_error(APLOG_MARK, APLOG_WARNING, 0, s, %s, msg)
#define modperl_log_error(s,msg) \
-ap_log_error(APLOG_MARK, APLOG_ERR|APLOG_NOERRNO, 0, s, %s, msg)
+ap_log_error(APLOG_MARK, APLOG_ERR, 0, s, %s, msg)
#define modperl_log_notice(s,msg) \
-ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_NOTICE, 0, s, %s, msg)
+ap_log_error(APLOG_MARK, APLOG_NOTICE, 0, s, %s, msg)
#define modperl_log_debug(s,msg) \
-ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_DEBUG, 0, s, %s, msg)
+ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s, %s, msg)
#define modperl_log_reason(r,msg,file) \
-ap_log_error(APLOG_MARK, APLOG_ERR|APLOG_NOERRNO, 0, r-server, \
+ap_log_error(APLOG_MARK, APLOG_ERR, 0, r-server, \
access to %s failed for %s, reason: %s, \
file, \
get_remote_host(r-connection, \
1.9 +1 -1 modperl-2.0/t/response/TestAPI/aplog.pm
Index: aplog.pm
===
RCS file: /home/cvs/modperl-2.0/t/response/TestAPI/aplog.pm,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- aplog.pm 4 Jun 2002 13:04:47 - 1.8
+++ aplog.pm 14 Aug 2002 14:54:47 - 1.9
-46,7 +46,7
$s-log_serror(Apache::LOG_MARK, Apache::LOG_DEBUG,
APR::ENOTIME, log_serror test 2 ok);
-$r-log_rerror(Apache::LOG_MARK, Apache::LOG_DEBUG|Apache::LOG_NOERRNO,
+$r-log_rerror(Apache::LOG_MARK, Apache::LOG_DEBUG,
APR::ENOTIME, log_rerror test ok);
$r-log_error('$r-log_error test ok');
1.11 +2 -2 modperl-2.0/xs/Apache/Log/Apache__Log.h
Index: Apache__Log.h
===
RCS file: /home/cvs/modperl-2.0/xs/Apache/Log/Apache__Log.h,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- Apache__Log.h 19 Jun 2002 05:18:04 - 1.10
+++ Apache__Log.h 14 Aug 2002 14:54:47 - 1.11
-57,10 +57,10
}
if (r) {
-ap_log_rerror(file, line, APLOG_NOERRNO|level, 0, r, %s, str);
+ap_log_rerror(file, line, level, 0, r, %s, str);
}
else {
-ap_log_error(file, line, APLOG_NOERRNO|level, 0, s, %s, str);
+ap_log_error(file, line, level, 0, s, %s, str);
}
if (svstr) {
1.28 +1 -2 modperl-2.0/xs/Apache/RequestIO/Apache__RequestIO.h
Index: Apache__RequestIO.h
===
RCS file: /home/cvs/modperl-2.0/xs/Apache/RequestIO/Apache__RequestIO.h,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- Apache__RequestIO.h 30 May 2002 02:33:48 - 1.27
+++ Apache__RequestIO.h 14 Aug 2002 14:54:47 - 1.28
-157,8 +157,7
/* only do this once per-request */
if ((rc = ap_setup_client_block(r, REQUEST_CHUNKED_ERROR)) != OK) {
-ap_log_error(APLOG_MARK, APLOG_ERR|APLOG_NOERRNO, 0
cvs commit: modperl-2.0/lib/Apache Build.pm
stas2002/08/14 19:10:32
Modified:lib/Apache Build.pm
Log:
make it possible to build mod_perl against the source tree, where apr.h is
located in srclib/include/apr/ and not include/
Revision ChangesPath
1.104 +6 -1 modperl-2.0/lib/Apache/Build.pm
Index: Build.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/Build.pm,v
retrieving revision 1.103
retrieving revision 1.104
diff -u -r1.103 -r1.104
--- Build.pm 14 Aug 2002 02:33:00 - 1.103
+++ Build.pm 15 Aug 2002 02:10:32 - 1.104
-765,7 +765,12
my $dir = $self-ap_includedir;
-my $header = $dir/apr.h;
+my $header;
+for my $d ($dir, $dir/../srclib/apr/include) {
+$header = $d/apr.h;
+last if -e $header;
+}
+
open my $fh, $header or do {
error Unable to open $header: $!;
return undef;
Re: Compiling problems with Apache 2.040 (Win32)and mod_perl2 lastversion.
Stefan Sabolowitsch wrote: Hi NG. I has here the current Apache 2.040 for Win32. With compile of the last mod_perl2 version, get I the following error message. [...] mod_perl.c(511) : warning C4047: 'function' : Anzahl der Dereferenzierungen bei 'int (__cdecl *)(struct ap_filter_t *)' und 'int ' unterschiedlich mod_perl.c(511) : warning C4024: 'ap_register_output_filter' : Unterschiedliche Typen fuer formalen und uebergebenen Parameter 3 mod_perl.c(511) : error C2198: 'ap_register_output_filter' : Nicht genuegend Par ameter uebergeben [...] With Apache 2.039 (Win32) there are no problems. Possibly does someone have an idea? Try building with the cvs mod_perl version: http://perl.apache.org/docs/2.0/user/install/install.html#Installing_from_Source __ 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
Re: naming convention
Michael Robinton wrote: I have a proposed perl / modperl module that will go to CPAN Graphics::ColorPicker : A perl module for WYSIWYG web applications that allow selection of HEX color numbers I think this is an appropriate name, but have not submitted in this category before. Please advise. I guess that this module is not extending mod_perl functionality, but simply optionally uses it and therefore you better off discussing this at [EMAIL PROTECTED], [EMAIL PROTECTED] without even mentioning mod_perl so not to confuse people. If my guess is wrong (you provided too little info) and it *requires* mod_perl it should probably be named something like Apache::ColorPicker, but again, you've provided too little info to tell. See: http://www.bizsystems.net/downloads/graphics/demo.html FWIW, it doesn't seem to do anything on mozilla-1.0/linux. __ 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
Re: naming convention
Michael Robinton wrote:
Stas wrote:
Michael Robinton wrote:
I have a proposed perl / modperl module that will go to CPAN
Graphics::ColorPicker : A perl module for WYSIWYG web
applications that allow selection of HEX color numbers
I think this is an appropriate name, but have not submitted in
this category before. Please advise.
I guess that this module is not extending mod_perl functionality,
but simply optionally uses it and therefore you better off
discussing this at [EMAIL PROTECTED], [EMAIL PROTECTED] without
even mentioning mod_perl so not to confuse people. If my guess is
wrong (you provided too little info) and it *requires* mod_perl it
should probably be named something like Apache::ColorPicker, but
again, you've provided too little info to tell.
Sorry bout that. It does optionally use mod_perl -- it tests
eval{require Apache} and proceeds, otherwise uses print statements to STDOUT
so my guess was right, take it to one of the lists I've mentioned for
the best effect. Here we discuss modules which extend or exclusively use
mod_perl.
See: http://www.bizsystems.net/downloads/graphics/demo.html
FWIW, it doesn't seem to do anything on mozilla-1.0/linux.
hmm works fine on my mozilla-1.0/linux build #2001061002
tested on above + windoze MSIE5.5, Netscape 4.7, Mozilla 1.0
If you can tell me more that would be nice.
I cannot tell you more, because it doesn't do anything ;). I enter
FA23DB as suggested, click on the button, and get a window whose source is
!DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01
Transitional//ENhtmlheadtitle/title/headbody/body/html
but we are going OT here, let's take it off the list.
__
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
Re: mod_perl install on SGI
Tom Keller wrote: Greetings, I am trying to install mod_perl with apache_1.2.26 on and SGI running 6.5.16. apache was installed from the freeware.sgi.com website using their very nice installer. Unfortunately, the clean up after installation seems to remove the Makefile that is used by mod_perl's Makefile. So running install mod_perl from cpan, I get the question Please tell me wher I can find your apache src [ ../apache_x.x/src] I can't seem to give it a path that works. I know the executable is at /usr/freeware/apache, but that gives the message can't open /Makefile No such file. I've also tried using /var/inst/fw_apache which is the downloaded source file. No dice. CPAN asks for your apache '/src' dir, not the location of the binary or the source base dir. e.g. if you've untarred the apache source in /tmp/apache_1.3.26, you should pass /tmp/apache_1.3.26/src when prompted by mod_perl installer. See http://perl.apache.org/docs/1.0/guide/install.html for more info. __ 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
Re: Mismatched Prototyped with mod_perl
Yair Lenga wrote:
I've currently in the process of moving from CGI to mod_perl. I noticed several
people that complain about Mismatched prototype warning. while most of the messages
are caused by perl handling of function declaration, I think that some of the
messages can be reduced by fixing 'mod_perl':
The flush_namespace was not checking for empty prototypes (i.e.,function that does
take zero parameters, like most of the constant functions). I.e.
sub PI () { 3.1415 } was treated the same as
sub PI { 3.1415 }
I made a minor modication to the code, and that has eliminated many warnings
(especially from libwww). I hope that someone can review those changes and commit
them to the master source code, for the next mod_perl release).
Thank you Yair, committed.
__
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
Re: Handler Concept / Question
Rick Myers wrote: On Aug 12, 2002 at 11:50:56 -0600, Thomas Whitney wrote: I was following this thread with interest because I want to do something like this. I started searching on list archive for the above mentioned syntax, I searched for 'static content', then 'default handler', but with no luck. I do not mind doint the the searching, if you would perhaps suggest a couple other search topics. You were close. It's default-handler. http://httpd.apache.org/docs/handler.html And in mod_perl docs: http://perl.apache.org/docs/1.0/guide/config.html#Overriding_E_lt_LocationE_gt__Setting_in__Sub_Location_ __ 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
Re: please unsubscribe me
[EMAIL PROTECTED] wrote: please unsubscribe me Only you can do that. Look at the email header, it says: list-unsubscribe: mailto:[EMAIL PROTECTED] __ 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
Re: error_log [info] [debug] lines
Anton Permyakov wrote: Hello, all. My error_log is abounded with following lines. What does it mean, and how it impacts on Apache performance in general? You sometimes get these when clients abort their connections. There is not much you can do about that. It doesn't impact the performance. Thank you. [Sat Aug 10 12:50:03 2002] [info] [client 24.165.240.166] (104)Connection reset by peer: client stopped connection before rwrite completed [Sat Aug 10 12:50:03 2002] [debug] Apache.c(364): (104)Connection reset by peer: mod_perl: rwrite returned -1 (fd=3, B_EOUT=8) [Sat Aug 10 12:50:04 2002] [info] [client 24.165.240.166] (104)Connection reset by peer: client stopped connection before rwrite completed [Sat Aug 10 12:50:04 2002] [debug] Apache.c(364): (104)Connection reset by peer: mod_perl: rwrite returned -1 (fd=3, B_EOUT=8) [Sat Aug 10 12:50:05 2002] [info] [client 24.165.240.166] (104)Connection reset by peer: client stopped connection before rwrite completed __ 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
Re: Apache-server-dir_config-{DocumentRoot} is null on startup
How else can i find the server-document_root ? e.g: Apache-server_root_relative(htdocs); __ 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
cvs commit: modperl Changes
stas2002/08/12 00:11:39
Modified:lib/Apache PerlRun.pm
.Changes
Log:
eliminate warnings when flushing functions with empty () prototypes in
Apache::PerlRun::flush_namespace
Submitted by: Yair Lenga [EMAIL PROTECTED]
Reviewed by: stas
Revision ChangesPath
1.40 +1 -1 modperl/lib/Apache/PerlRun.pm
Index: PerlRun.pm
===
RCS file: /home/cvs/modperl/lib/Apache/PerlRun.pm,v
retrieving revision 1.39
retrieving revision 1.40
diff -u -r1.39 -r1.40
--- PerlRun.pm29 May 2002 16:52:17 - 1.39
+++ PerlRun.pm12 Aug 2002 07:11:39 - 1.40
@@ -354,7 +354,7 @@
if (defined $fullname) {
no warnings;
local $^W = 0;
-if (my $p = prototype $fullname) {
+if (defined(my $p = prototype $fullname)) {
*{$fullname} = eval sub ($p) {};
}
else {
1.655 +3 -0 modperl/Changes
Index: Changes
===
RCS file: /home/cvs/modperl/Changes,v
retrieving revision 1.654
retrieving revision 1.655
diff -u -r1.654 -r1.655
--- Changes 31 Jul 2002 02:10:16 - 1.654
+++ Changes 12 Aug 2002 07:11:39 - 1.655
@@ -10,6 +10,9 @@
=item 1.27_01-dev
+eliminate warnings when flushing functions with empty () prototypes in
+Apache::PerlRun::flush_namespace [Yair Lenga [EMAIL PROTECTED]]
+
fix Apache::Status to not use :: in filenames, which is not allowed on
certain OSs [DH [EMAIL PROTECTED]]
Re: solaris 2.6, mod_perl 1.27, apache 1.3.26, resulting server fails
Lupe Christoph wrote:
On Thursday, 2002-08-08 at 15:48:48 -0700, John E. Mendenhall wrote:
On Thu, 8 Aug 2002, Lupe Christoph wrote:
Since mod_perl seems to play tricks with bootstrap, I don't really
know how this comes into play.
I have done all you have asked. All output appears similar. Three files,
including Log.xs. Nine entries in httpd for XS_Apache__Log, as follows:
So, where to from here? Any ideas?
Well, this proves that Apache::Log *is* linked into the httpd binary.
The questions is why bootstrap is called at all. I'm afraid, I have
to hand this over to people who know the internal logic of mod_perl.
bootstrap *should* not be called, I think.
bootstrap() is always needed, because that's the function that
installs XSUBs into the corresponding Perl functions. The only
difference between dynamically and statically linked libraries is the
former is loading the object first and the latter have everything loaded
already. Here is the explanation by Tim Bunce:
http://groups.google.com/groups?q=bootstrap+statically+linked+perlhl=enlr=ie=UTF-8oe=UTF-8selm=Cyy1rA.Lnp%40ig.co.ukrnum=1
So as Tim says a statically linked library should already have its
::bootstrap function (which is boot_Apache__Log in your case).
mod_perl::boot() (lib/mod_perl.pm) is the place where it decides whether
to call DynaLoader's bootstrap() or the existing one:
sub boot {
my($class, $version) = @_;
no strict 'refs';
*{$class.'::dl_load_flags'} = DynaLoader-can('dl_load_flags');
if ($ENV{MOD_PERL}) {
(defined {$class.'::bootstrap'} ?
\{$class.'::bootstrap'} :
\DynaLoader::bootstrap)-
($class, $version);
}
}
In your case defined {$class.'::bootstrap'} should probably return a
ref to Apache::Log::bootstrap() (boot_Apache__Log) and then call it. For
some reason this doesn't happen and the DynaLoader's version is called,
which of course fails to load the object.
What do you get from running:
nm httpd | grep Apache__Log
there should be boot_Apache__Log there.
__
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
Re: Verifying Which Handler
Jeff Crist wrote: Can someone send me an example of a test Perl script that will display which Perl handler Apache is using - Apache::Registry or PerlRun. We just migrated our website to a new server that was initially setup to run Appache::Registry but we don't have time to cleanup the code so I change the configuration (at least thought I did) to PerlRun. However we are seeing random behavior when running scripts on our website (the content of the page unexplainably changes sometimes) that seem to indicate variables are not being reset (ie, maybe we are still using the Apache::Registry handler) From the scripts you can use Carp::cluck() or for the fine tuning caller(). You can also do it globally, set in the startup file: $Apache::Registry::Debug = 1; $Apache::PerlRun::Debug = 1; and then the handlers will spit some debug info which should help. Another tipoff was when he had to go change all the exit commands in the Perl scripts to Apache::exit(); You don't need to do that for registry scripts. It's being done for you behind the scenes. __ 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
Re: Apache::DProf not working
Randy Harmon wrote: I'm having trouble making Apache::DProf work. I've installed the module with CPAN, and I've added PerlModule Apache::DProf at the top of my httpd.conf. I've verified with 'httpd -l' that PerlChildInitHandler is OK - therefore, pushing a child-init handler should be OK, right? I've started the server, ran the web page I want to profile (that uses HTML::Mason), and then stopped the server. ServerRoot/dprof is not created, nor when I create it does it create dprof/$$ files as documented (likewise ServerRoot/logs/dprof/, as described elsewhere in the perldoc - not self-consistent). Also searched the entire system for tmon.out files (not found). Any suggestions? Permission problems? __ 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
Re: Some wierd problem with mod_perl and Apache
Ged Haywood wrote: Hi there, On Fri, 2 Aug 2002 [EMAIL PROTECTED] wrote: sometimes.when I enter the values in the form and click on the change password button, the same screen comes back to me without the change actually happening. After doing this couple of times, I would actually succeed. Have you checked out the Guide? http://perl.apache.org/guide/debug.html BTW, while /guide is still working, the real url is now /docs/1.0/guide/, so I'd rather see people use that, because you should remember that we enter the era of co-existence of mod_perl 1.0 and 2.0, so /guide is not the *only* guide anymore. Moreover parts of the /guide that aren't specific to 1.0 have moved into /docs/general/. __ 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
Re: Where's Apache::VarTest?
Oden Eriksson wrote: Hi. I'm using this as per documetation: Location /print_env2 SetHandler modperl PerlResponseHandler Apache::VarTest PerlSetVar VarTest VarTestValue /Location And are getting error 500 and this in the log: [Sat Aug 03 15:50:12 2002] [error] failed to resolve handler `Apache::VarTest' SERVER_SOFTWARE = Apache/2.0.40-dev MOD_PERL = mod_perl/1.99_05-dev You have to create that package. This was just an example of the configuration. You realize that we cannot supply a complete handler for each configuration example. __ 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
Re: 1.99_05-dev (from CVS) + 1.27?
Oden Eriksson wrote: Hi there. I'm new to this list so excuse me if I brake written or unwritten rules... I'm the apache2 (from CVS) packager for Mandrake Linux. Is there some voodoo magic trick I could do to enable both mod_perl bransches on the same machine? As it is now both apache versions can coexist, but when I try to compile latest mod_perl it complains when it finds 1.27 Any hints would be appreciated. True. MP_INST_APACHE2=1 was supposed to become a default, but it didn't yet :( So I've adjusted the docs too early. I've put it back: http://perl.apache.org/docs/2.0/user/install/install.html#Create_the_build_environment You should be all set now. __ 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
Re: No error log, no database
Joachim Zobel wrote: At 09:03 02.08.2002 +0800, you wrote: Joachim Zobel wrote: Hi. Yesterday it happened that our error log reached 2Gb. Since ours is a linux box writing to it stopped. At the same time all database driven functionality stopped working (Plain DBI on Mysql, no Apache::DBI). The database was still usable through the PHP admin interface. The filesystem was not full. When the log was rotated, everything returned to normal. This was on a virtual Apache 1.3.26, mod_perl 1.25. Does anybody have an idea what happened? You've hit the 2GB limit. Yes, I know. I should have stated my question more clearly. But normally it should not be a critical error if the error log can no longer be written. In our case the database was not accessible (except for one handler that does a very simple SELECT). My question is: How did reaching the error logs 2Gb limit affect the database driver? Could be the DBD driver problem. You should probably ask on the relevant list and if you find an answer please share the reason with us. Seems to be an interesting problem. __ 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
Re: mod_perl program
masilva3 wrote: Hi list, I converted an cgi for mod_perl and sometimes it execute ok, in the others, it show the code of cgi in browser. Anybody know what occur ? Did you use: Options +ExecCGI PerlSendHeader On __ 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
Re: 1.99_05-dev (from CVS) + 1.27?
Oden Eriksson wrote: On Fridayen den 2 August 2002 13.37, Stas Bekman wrote: Oden Eriksson wrote: Hi there. I'm new to this list so excuse me if I brake written or unwritten rules... I'm the apache2 (from CVS) packager for Mandrake Linux. Is there some voodoo magic trick I could do to enable both mod_perl bransches on the same machine? As it is now both apache versions can coexist, but when I try to compile latest mod_perl it complains when it finds 1.27 Any hints would be appreciated. True. MP_INST_APACHE2=1 was supposed to become a default, but it didn't yet :( So I've adjusted the docs too early. I've put it back: http://perl.apache.org/docs/2.0/user/install/install.html#Create_the_build_ environment You should be all set now. Thanks. It did build without any problems, but there's yet to tell if if conflicts on the file and file location level ;) It definitely doesn't if you use. PerlModule Apache2 as explained here: http://perl.apache.org/docs/2.0/user/config/config.html#Accessing_the_mod_perl_2_0_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
Re: Local file security (in 1.27)
[...] So, question is: How do I protect my data files from being accessed by anything else than my own perlhandler? Can I set another uid for all that has to do with my specific perlhandler? Hints are most welcome. You can't. The only solution is run a dedicated server for each user. Currently the pure Apache solution is to use suexec, which you cannot run under mod_perl. This is all covered at: http://perl.apache.org/docs/general/multiuser/multiuser.html this issue will be addressed in 2.0 with perchild Apache mpm which allows you to run different groups of servers/threads under different uids/gids. If I remember correctly this mpm is highly experimental at this point. __ 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
Re: No error log, no database
Joachim Zobel wrote: Hi. Yesterday it happened that our error log reached 2Gb. Since ours is a linux box writing to it stopped. At the same time all database driven functionality stopped working (Plain DBI on Mysql, no Apache::DBI). The database was still usable through the PHP admin interface. The filesystem was not full. When the log was rotated, everything returned to normal. This was on a virtual Apache 1.3.26, mod_perl 1.25. Does anybody have an idea what happened? You've hit the 2GB limit. First make sure that your OS/fs has a large file support. http://www.suse.de/~aj/linux_lfs.html Then re-build Apache (it should automatically add -D_LARGEFILE_SOURCE flag) and Perl with -Duselargefiles and finally rebuild mod_perl. -- __ 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
Re: Problems with Apache/Mod_perl Server
Alfred Vahau wrote: Thanks for the leads. My concentration definitely lapsed over the make test failure. I ran make install regardless and all was well. I attempted to start the server without success. Here's the error message from the error_log [Wed Jul 31 15:03:13 2002] [alert] httpd: Could not determine the server's fully qualified domain name, using 127.0.0.1 for ServerName add to /etc/hosts: 127.0.0.1 localhost.localdomain localhost [Wed Jul 31 15:03:13 2002] [warn] pid file /usr/local/apache/logs/httpd.pid overwritten -- Unclean shutdown of previous Apache run? [Wed Jul 31 15:03:13 2002] [notice] Apache/1.3.26 (Unix) mod_perl/1.27 configured -- resuming normal operations [Wed Jul 31 15:03:13 2002] [notice] Accept mutex: sysvsem (Default: sysvsem) So it starts normally. perl -V reports Perl version 5.6.0 which came with the Red Hat box whereas I downloaded 5.6.1 from CPAN and installed it. Conflict in libraries? I may have to try installing Perl 5.6.1 again. I'll report the results. If perl -V reports 5.6.0 you must be running 5.6.0 ;) may be you have installed perl into /usr/local/bin and /usr/bin comes earlier in the path so it picks 5.6.0. Doesn't RH carry 5.6.1 rpms? You could try to uninstall 5.6.0 binaries though I can see that you will have dependencies problems. __ 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
Re: while - modperl 2.0/Apache 2.0
Alessandro Forghieri wrote: Greetings. I have observed the same behavior (on win32). Scripts that are invoked from the same browser through the same URL appear to bind to the same perl thread and are therefore serialized. Changing the URL appears to bind the request to a different thread. (My observation regarded access from a different Location: Udei's experience shows that a URL change suffices). I have often wondered wether this is incidental or specified behaviour. OK, I've returned to this problem. And the bug is in Apache 2.0 not mod_perl. I was able to reproduce the serialization problem with a plain cgi-bin script. Will report to the httpd-dev list and hopefully it'll be resolved in the future version. __ 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
Re: while - modperl 2.0/Apache 2.0
Stas Bekman wrote: Alessandro Forghieri wrote: Greetings. I have observed the same behavior (on win32). Scripts that are invoked from the same browser through the same URL appear to bind to the same perl thread and are therefore serialized. Changing the URL appears to bind the request to a different thread. (My observation regarded access from a different Location: Udei's experience shows that a URL change suffices). I have often wondered wether this is incidental or specified behaviour. OK, I've returned to this problem. And the bug is in Apache 2.0 not mod_perl. I was able to reproduce the serialization problem with a plain cgi-bin script. Will report to the httpd-dev list and hopefully it'll be resolved in the future version. I'm taking my words back. I did some more testing and the same problem can be reproduced with Apache 1.3. So I have tried different browsers and chased the problem to be a browser's fault. Here is the status on linux: Opera, Mozilla, Galeon - serialize the requests to the same URL. Konqueror, lynx- run both in parallel. Luckily I didn't sent the bogus bug report to httpd-dev ;) __ 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
Re: Can you have mod_perl 1.26 with Apache 2.0.39?
Grant Cooper wrote: Can you have mod_perl 1.26 with Apache 2.0.39? I was unable to to install mod_perl from ports but was able to do a pkg_install mod_perl 1.26. Seems to work now but now I have apache version 1.3.22 where I use to have 2.0.39. Is this because mod_perl 2.0 is meant for apache 2 and is not compatible with 1.3.22? I can't find any compatibility documentation. No, you cannot mix these, see: http://perl.apache.org/docs/2.0/user/help/help.html#Wrong_Apache_mod_perl_combination Whenever you have a problem, remember to peruse the shortcuts menu on the left side of all pages at perl.apache.org and one of the two entries should save you (and us) a lot of time: Report 1.0 Problems Report 2.0 Problems __ 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
Re: $r-dir_config-(un)set issue...
simran wrote: Does that mean that $r-dir_config is not the same as $r-server-dir_config ? not the same, $r-dir_config is a merge of the Location section setting with Server/Vhost settings, $r-server-dir_config is only for Server/Vhost settings. __ 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
Re: while - modperl 2.0/Apache 2.0
Udlei Nattis wrote: hi, this problem is stranger when i use apache 1.3/modperl 1.27 this problem don't exist i think problem is because thread in apache2 or modperl2 That's the thing. I've had the same behavior with apache 1.3/modperl 1.27, so I don't think this has anything to do with Apache or mod_perl. (This is on linux) lynx dont have problem because is other instance if you open 2 instances of mozilla you dont have problem but if you open one mozilla and 5 tab navigator of instance problem persist []s nattis Stas Bekman wrote: Stas Bekman wrote: Alessandro Forghieri wrote: Greetings. I have observed the same behavior (on win32). Scripts that are invoked from the same browser through the same URL appear to bind to the same perl thread and are therefore serialized. Changing the URL appears to bind the request to a different thread. (My observation regarded access from a different Location: Udei's experience shows that a URL change suffices). I have often wondered wether this is incidental or specified behaviour. OK, I've returned to this problem. And the bug is in Apache 2.0 not mod_perl. I was able to reproduce the serialization problem with a plain cgi-bin script. Will report to the httpd-dev list and hopefully it'll be resolved in the future version. I'm taking my words back. I did some more testing and the same problem can be reproduced with Apache 1.3. So I have tried different browsers and chased the problem to be a browser's fault. Here is the status on linux: Opera, Mozilla, Galeon - serialize the requests to the same URL. Konqueror, lynx- run both in parallel. Luckily I didn't sent the bogus bug report to httpd-dev ;) __ 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 -- __ 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
Re: Warnings clarification
William McKee wrote: Hi, I've been using Perl for several years to develop simple CGI applications for my clients. I'm now in the process of migrating to mod_perl for the performance benefit it gives. In so doing, I've been lurking on this list and reading the Guide. Presently, I'm trying to debug a problem with a segmentation fault in the Petal module that Jean-Michel Hiver announced a couple weeks ago on this list. As I was reading the guide, The Importance of Warnings section in the Debugging chapter, suggested setting PerlWarn On on the development machine. My question is whether this setting is the same as the -w switch and the 'use warning' pragmas. I suspect it is, but the guide did not clarify this point. Have you read this? http://perl.apache.org/docs/1.0/guide/porting.html#Warnings If yes, what part you are still confused about? I think the definitions are very clear. -- __ 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
Re: Warnings clarification
William McKee wrote: On 31 Jul 2002 at 20:56, Stas Bekman wrote: Have you read this? http://perl.apache.org/docs/1.0/guide/porting.html#Warnings No, I was reading this-- http://perl.apache.org/docs/1.0/guide/debug.html#The_Importance_of_Warnings The information in the link you posted is I was seeking. Perhaps a cross-reference would be useful. I just added it. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
ANNOUNCE: Debug::SIGSEGVTrace
For all those who have troubles getting a backtrace or the core file,
when a mod_perl server (or a perl program) segfaults, here is a module
that attempts to do all the work for you. The rest of the doc follows.
Please read the TODO section, and help me with things that need to be
done if you know how. Thanks.
I've just uploaded it on CPAN, so it'll take a while before it gets
mirrored, but you can get it from here:
https://pause.perl.org/pub/PAUSE/authors/id/S/ST/STAS/Debug-SIGSEGVTrace-0.01.tar.gz
Also notice that the distro includes Debug::SIGSEGVFault, which simply
segfaults with a nice trace. I use it for the testing and you can use it
for testing core files dumping.
NAME
Debug::SIGSEGVTrace - Extract A Backtrace on SegFault
SYNOPSIS
use Debug::SIGSEGVTrace;
use File::Spec::Functions;
my $tmp_dir = File::Spec::Functions::tmpdir;
my $trace = Debug::SIGSEGVTrace-new(
dir= $tmp_dir,
#verbose= 1,
#exec_path = '/home/stas/perl/bin/perl',
#core_path_base = catfile($tmp_dir, mycore),
#command_path = catfile($tmp_dir, my-gdb-command),
#debugger = gdb,
);
# enable the sighandler
$trace-ready();
# or simply:
Debug::SIGSEGVTrace-new(dir = $tmp_dir)-ready;
DESCRIPTION
This module attempts to automatically extract a backtrace when a
segfault happens, rather then letting the core file be dumped. This has
the following benefits:
* no need to setup the environment to allow core file dumped.
Sometimes people just don't know how to set it up. Sometimes you
aren't allowed to set it up (e.g., when the webserver
environment is
not under your control).
* if many Perl programs are run in a row and more than one program
segfaults it's possible to collect all backtraces, rathen then
aborting the run on the first segfault or staying with only the
last
core file, which will overwrite all the previous ones. For example
consider a live webserver or a test suite which may segfault many
times for different reasons.
* for huge core files, this approach saves disk space. And can be a
saver when you don't have disk space left for various reasons
(passed the quota?), but still have a few kilo-bytes left.
METHODS
new()
my $trace = Debug::SIGSEGVTrace-new(
dir= $tmp_dir,
verbose= 1,
exec_path = '/home/stas/perl/bin/perl',
core_path_base = catfile($tmp_dir, mycore),
command_path = catfile($tmp_dir, my-gdb-command),
debugger = gdb,
);
Attributes:
*dir*
a writable by the process directory.
This is a required attribute.
*verbose*
Whether to be silent (0) or verbose (1).
This is an optional attribute. The default is 0.
Currently it's always a non-verbose, with just a few traces printed
out. Will work in the future.
*exec_path*
gdb needs to know the path to the executable in order to
attach to
the process (though gdb 5.2 and higher needs only pid to do that).
This module is trying to automatically figure out the executable
path, using several methods in the following order:
$^X, /proc/self/exe, $Config{perlpath}
If all these methods fail the module will die(), unless you
explicitly set the *exec_path* attribute. Notice I named it
*exec_path* because the executable doesn't have to be perl, when
Perl is embedded, which is the case with mod_perl, which sets $^X
to the path to the Apache httpd server.
*core_path_base*
The base path of the core file. e.g. if *core_path_base* is set to
*/tmp/mycore* and the pid of the process that has segfaulted is
12345, the generated core is written to the file
*/tmp/mycore12345*.
This is an optional attribute.
By default *core_path_base* is a concatenation of the *dir*
attribute and the string *core.*.
*command_path*
The path to the file with debugger commands. If this attribute is
set the file should already include the commands. Notice that the
commands should include 'quit' as the last command, so the debugger
will quit.
This is an optional attribute.
By default *command_path* is a concatenation of the *dir* attribute
and the string *gdb-command*, which is getting populated with the
following commands:
bt
quit
*debugger*
Curently not used. In the future could be used to specify which
debugger to use (when more than one debugger is supported). For the
future compatibility gdb is going to be the default.
ready
a new doc: Preparing mod_perl modules for CPAN
I've just added a new doc: Preparing mod_perl modules for CPAN http://perl.apache.org/docs/general/cpan_mod_dev/cpan_mod_dev.html If you have useful input please send it to me. __ 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
Re: get_remote_host for mod_perl2
Tim Keefer wrote: Hi All, Any ideas for retrieving the users ip address within a mod_perl2 module? mod_perl1 has $r-get_remote_host. Is their something similar in mod_perl2? I've searched all the mod_perl2 docs on perl.apache.org and couldn't find anything about this. in 2.0 it's: use Apache::Connection; $r-connection-remote_host(); I'm not sure why Doug renamed it, but I just committed a patch to the compat layer. will update the doc too. p.s. Lyle is working on automatic docs extraction from httpd header files. once this is done the 2.0 API will appear online. Currently use search t/ for API usage. __ 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
Re: Fwd: Re: Apache::DBI as a prerequisite
Simon Perrault wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On July 30, 2002 10:02 pm, Stas Bekman wrote: 2) See http://perl.apache.org/docs/2.0/devel/testing/testing.html Though you can really rely on it once Apache::Test is released, which will happen when mod_perl 2.0 is released. 1) That's an interesting problem. It seems that nobody has asked this question before. Here is my take on it. If you like this solution I'll add it to the docs. Thanks a lot. Your solution for Apache::DBI works and is very Perlish! Great. I've put it here: http://perl.apache.org/docs/general/cpan_mod_dev/cpan_mod_dev.html __ 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
Re: Mandrake defalut mod_perl dose not seem to be working.
Roy Souther wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 31 July 2002 08:40 pm, Stas Bekman wrote: What do you mean by doesn't work? Try: http://perl.apache.org/docs/1.0/guide/install.html#How_can_I_tell_whether_m od_perl_is_running_ The two tests they recommend give conflicting results. The log file says that mod_perl was started. The command line test httpd -l says it is not compiled in. The problem here is that mod_perl and apache doc recommend that you disable httpd and run httpd_modperl in it's place but Mandrake runs both httpd and httpd-perl that is the binary they ship with mod_perl. They must have renamed it. They both of them and each has it's own set of configuration files. So I did wget -S 127.0.0.1 and the mod_perl does not show there. So I can not confirm that mod_perl is running or not. I use Mandrake but I never use apache/mod_perl rpms but build my own, so I don't know. But it seems that you test the wrong binary 'httpd -l', if error_log says that you are running mod_perl you are running mod_perl. Is there a simple test file I could use to see if it is running? Or some other test I could do? Configure a registry section http://perl.apache.org/docs/1.0/guide/getwet.html#Configuring_and_Starting_the_mod_perl_Server and run a simple script: http://perl.apache.org/docs/1.0/guide/install.html#Testing_via_a_CGI_script -- __ 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
Re: Apache::Status bugfix ( :: doesn't play well in filenames)
thanks, but how about sending a patch using diff?
http://perl.apache.org/contribute/cvs_howto.html#Sending_Patches
sub noh_b_graph {
my $r = shift;
require B::Graph;
untie *STDOUT;
my $dir = $r-server_root_relative(
$r-dir_config(GraphDir) || logs/b_graphs);
mkdir $dir, 0755 unless -d $dir;
(my $thing = $r-path_info) =~ s:^/::;
$thing =~ s{::}{-}g; # cause some OS's dont' allow :: in filenames
## the line above you should add
## the line before it is # 516
__
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
--
__
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
Re: T switch is ignored modperl2.0
Kent, Mr. John wrote:
Greetings,
I have put PerlSwitches -T in my httpd.conf file, yet keep getting the
following warning
in the server's error_log:
[Tue Jul 23 10:43:06 2002] [warn] T switch is ignored, enable with
'PerlSwitches -T' in httpd.conf
Any suggestions?
the cvs version or the next release won't complain anymore. currently -T
on shebang line is simply ignored, but will complain again in the future
when we will have a flag indicating whether the taint mode is on or not.
in perl 5.8.0 it's easy:
% perl5.8.0 -Te 'print ${^TAINT}'
in older Perls one need to parse PerlSwitches to find -T and set some
magic flag (was $Apache::__T in mod_perl 1.0).
__
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
Re: hiding perl code
Michael Robinton wrote: see attached [...] BZS::License performs a similar load operation to BZS::Loader. First, however it looks for a hash pointer in the caller program called $ptr2_License. The hash contains the path to the License file and an optional 'private' key list of modules which will decrypt only with the 'private' key. BOR, a I thought that somebody has already said here that you cannot hide your perl code. if you have an access to the perl interpreter you can dump the source code after it was decrypted. wouldn't it be a good idea to add the truth to the POD so not to mislead the crowd? I've read through the doc but didn't see a word mentioning this little caveat. Shouldn't the module be renamed to BZS::Obscure::...? ;) __ 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
Re: Mention LoadFile in the mp2 docs?
Alessandro Forghieri wrote: Greetings. From: http://perl.apache.org/docs/2.0/user/config/config.html#Enabling_mod_perl [...] Win32 users need to make sure that the path to the Perl binary (e.g., C:\Perl\bin) is in the PATH environment variable. [...] Is it not true that the directive LoadFile C:\foo\perl58.dll makes path modifications unnecessary? I guess the generic doc should simply redirect win32 users to http://perl.apache.org/docs/2.0/os/win32/config.html and not bother providing incomplete info. But I don't see that doc mentioning this issue. Randy? If so, it should perhaps be mentioned here. (With caveats, as situations where Registry scripts are handled by one - LoadFil-ed - perl version and CGI scriptse by another one - or not at all - would probably be confusing...). Cheers, alf -- __ 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
Re: Win32: Apache2+modperl2 STDERR not going to error.log?
Alessandro Forghieri wrote: Greetings. I am using the binary distribution Apache/2.0.40-dev (Win32) mod_perl/1.99_05-dev Perl/v5.8.0 from uwinnipeg. OS is NTsp6 httpd.conf is basically unmodified. I have noticed that carp'ing or warn'ing or even printing to stderr from a Registry script does not send anything to error.log. The same from CGI does produce the expected log records - verified on printenv. Also I am under the impression that the same does *NOT* happen on Win2K, but I cannot confirm it right now. Is this a known issue with this version, a by-design thing, or is it just me? FWIW, there are no problems on linux. Do you have the same problem with v5.6.1? Meanwhile try using the logging methods if possible: http://perl.apache.org/docs/2.0/api/mod_perl-2.0/Apache/Log.html __ 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
Re: Apache::Reload - filtering include directories
[...] Anyway, I decided to add another directive to Apache::Reload PerlSetVar ReloadDirectories /site/lib /usr/local/apache/conf Apache::Reload allows you to define which modules to reload using the patterns like so: PerlSetVar ReloadAll Off PerlSetVar ReloadModules Apache::* My::* Is there any reason why you cannot use this approach? I've no objection to your proposal, just wondering whether the existing features can be used instead. __ 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
Re: Segmentation fault
Vitor wrote: Hello Folks, I am having a big problem here. While i try to open a new Mail::CClient connection, i get these message : [Fri Jul 19 17:56:28 2002] [notice] child pid 6146 exit signal Segmentation fault (11) I am using Perl 5.6.1, Apache/1.3.23 , PHP/4.1.1 mod_perl/1.26, without shared libraries, and HTML::Mason templating system. I don't know if is a callback problem, because to login, Mail::CClient uses a login callback. It works well as a cgi, but under mod_perl/Mason, i get those message. You need to send a backtrace and other info as explained at: http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems and probably post it to the mason list and not here if this happens only under mason. __ 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
Re: apache mod_perl + suid question
[EMAIL PROTECTED] wrote: Hello, I am trying to write a password changing program. this article by Lincoln Stein should resolve most of your problems: http://www.samag.com/documents/s=1286/sam03020006/ and no, don't try to disable the taint mode, instead read the perlsec manpage to learn how to make your program run under -T. -- __ 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
Re: Apache2 CWD Non-threaded MPM
Joshua Bernstein wrote: Hey All, After much hassle, I blew away my threaded MPM under Apache2 because mod_perl didn't seem to be accepting or processing the . (period) in my @INC path so that scripts called like: require blah.cgi were not being found in the include path. I understand there are still issues with SafeCWD'ing in a threading enviroment, but now that the MPM is prefork, it isn't threaded anymore. Any reason why mod_perl 2, still doesn't recognize the . in my @INC path? You are talking about ModPerl::Registry, not mod_perl 2.0 in general. ModPerl::Registry will always do the same thing, be it the prefork mpm or the threaded mpm. Because the same code should run identically no matter what the mpm is used. Therefore if chdir() cannot be used with the threaded mpm it won't work with the prefork mpm as well. Solution 1: Subclass ModPerl::Registry as ModPerl::RegistryPreFork and do whatever is fine with prefork. Subclassing the new registry family is extremely easy, though the API hasn't been frozen yet. See ModPerl::RegistryCooker for more info. Solution 2: Arthur Bergman is working on ex::threads::safecwd, which should resolve the problem for threaded mpms. So once it's available we can use chdir() in ModPerl::Registry again. __ 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
Re: apache/mod_perl help
Dinesh Patel wrote: I'm trying upgrade my mod_perl version from 1.27 to 1.99.02 for apache-2.0.39. version 1.27 of mod_perl was compiled using : CC=cc OPTIM=-O $INET_TOP/bin/$OPSYS/perl Makefile.PL \ DO_HTTPD=1 PERL_AUTHEN=1 PERL_SECTIONS=1 make The question is how do I compile 1.99.02 with the PERL_AUTHEN and PERL_SELCTIONS enabled! It's too early to upgrade to mod_perl 2.0. Not all features are implemented (which is the case with Perl sections). For more info see: http://perl.apache.org/docs/2.0/user/index.html I have compiled the new version of mod_perl without the PERL values, The httpd.conf was edited to include : # mod_perl stuff Alias /cgi-bin/ /INDATA/inet_data/httpd/cgi-bin/ Location /cgi-bin SetHandler perl-script PerlHandler Apache::Registry PerlSetupEnv On Options ExecCGI /Location PerlWarn On PerlScript /INDATA/inet_data/httpd/cgi-bin/startup.pl however when i try and start the apache server i get the error : Syntax error on line 1067 of /INDATA/inet_data/httpd/conf/httpd.conf: Invalid command 'PerlSetEnv', perhaps mis-spelled or defined by a module not included in the server configuration Any help would be appreciated Regards Dinesh Patel -- __ 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
Re: Apache::Reload - filtering include directories
Harry Danilevsky wrote: Two reasons : 1. My site-specific modules don't necessarily have a common namespace (or even several namespaces); they just all live in /site/lib. Without a ReloadDirectories-like filter every time I add another module, say, /site/lib/Reports.pm I'll need to add Reports to ReloadModules, and restart the server. That's the thing. It's a good idea to alway use some prefix package name in all your modules, to avoid future clashes with other modules. And it automatically solves your problem with Apache::Reload. 2. Much more obscure, related to HTML::Mason. As I mentioned in my post: In Mason components are precompiled and cached, so that perl code doesn't have to be re-parsed for every request. The cached files are require(d), and they end up in %INC. It appears from ReloadDebug's output that those cached files are being checked by Apache::Reload, and if they have been modified - they'll be reloaded. The problem is, if the code has a syntax error, that error will occur when Apache::Reload re-require()s that file, and the error message will be printed to a log file, not to the browser - which is what Mason would do. So your browser will simply tell you that 'Internal error has occurred' ReloadDirectories will simply ignore them, and let Mason deal with modified files. If you tell Apache::Reload to look only at certain namespaces, this problem doesn't exist anymore. Am I still missing something ? Harry Danilevsky [EMAIL PROTECTED] Stas Bekman wrote: [...] Anyway, I decided to add another directive to Apache::Reload PerlSetVar ReloadDirectories /site/lib /usr/local/apache/conf Apache::Reload allows you to define which modules to reload using the patterns like so: PerlSetVar ReloadAll Off PerlSetVar ReloadModules Apache::* My::* Is there any reason why you cannot use this approach? I've no objection to your proposal, just wondering whether the existing features can be used instead. __ 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 -- __ 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
Re: I can see Apache.pm, why can't he?
Dennis Daupert wrote: What's up with this? I'm trying to load Apache::DBI on startup. I have apache and mod_perl installed, and running ok, and have installed additional modules, including the Apache::Bundle. When I put the line in mod_perl.conf, PerlModule Apache::DBI I can't start the web server. Dennis: Doctor, I think my server is sick, it cannot start Doctor: Does it have a high temperature? http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems __ 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
Re: Trouble with RegistryCooker.pm modper2.0
Kent, Mr. John wrote: Greetings, Today, 30-July-02, :Re-built both bleedperl and modperl from cvs per http://perl.apache.org/docs/2.0/user/install/install.html When attempting to run modperl get: [Tue Jul 30 13:08:08 2002] [error] [client 192.160.159.24] Use of uninitialized value in concatenation (.) or string at /users/webuser/bleedperl/lib/site_perl/5.8.0/i686-linux-thread-multi/ModPerl /RegistryCooker.pm line 549. This seems to be related to PerlSwitches -T which was in earlier releases but now is commented out Mea Culpa, please try again the cvs version, should be ok now. __ 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
Re: Subject: Re: hiding perl code
You are correct. If you... use Hidden::Module then use Data::Dumper to reconstruct most of the raw code. This would be about as useful as decompiling 'B' code. If you had access to the intrepreter directly, you could probably even capture the decrypt stream before perl compiles it, but all of that would take a degree of sophistication that is better used to make real money instead of hacking stuff apart. How about BZS::VeryObscure :-) Be it BZS::VeryObscure or BZS::VeryVeryObscure, all I was asking for is to tell the thruth in the docs probably somewhere at the top. I agree that for certain purposes this module may satisfy those who use it, but not all of them. __ 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
Re: Fwd: Re: Apache::DBI as a prerequisite
Simon Perreault wrote:
You wrote on 2002-04-30 to apache-modperl about Apache::DBI not being testable
while not under mod_perl. You said this:
That's normal. You cannot test modules that use mod_perl API without
running them inside mod_perl server. I've the same problem as you've
reported. This test suite is simple broken.
...
All Apache:: module authors should be moving to use the new Apache::Test
framework soon, since it lets you test the code under running mod_perl
server and works with both versions of httpd/mod_perl.
This is exactly my situation. I develop a module which requires Apache::DBI,
so I include it in my Makefile.PL like this:
WriteMakefile(
'PREREQ_PM'= {
'Apache::DBI' = 0,
},
);
But that prints a warning because Apache::DBI can't find Apache::module(),
which is only available under mod_perl.
My question:
1) Can you tell me (or guide me toward some information) how I can properly
add Apache::DBI as a prerequisite so that it doesn't print a warning (which
is the subjet of 90% of user emails)?
2) How can I test my module running Apache::DBI with Apache::Test?
I'll answer these in reverse:
2) See http://perl.apache.org/docs/2.0/devel/testing/testing.html
Though you can really rely on it once Apache::Test is released, which
will happen when mod_perl 2.0 is released.
1) That's an interesting problem. It seems that nobody has asked this
question before. Here is my take on it. If you like this solution I'll
add it to the docs.
Makefile.PL
---
use ExtUtils::MakeMaker;
# set prerequisites
my %prereq = (
Foo = 1.56,
);
# Manually test whether Apache::DBI is installed and add it to the
# PREREQ_PM if it's not installed, so CPAN.pm will automatically fetch
# it. If Apache::DBI is already installed it will fail to get loaded by
# MakeMaker because it requires the mod_perl environment to load.
eval { require Apache::DBI };
if ($@ $@ !~ /Can't locate object method/) {
$prereq{Apache::DBI} = '';
}
WriteMakefile(
NAME = 'Apache::SuperDuper',
VERSION_FROM = 'SuperDuper.pm',
PREREQ_PM = \%prereq,
# ...
);
__
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
Re: Apache::Status patch, in diff -u format (finally ;)
DH wrote:
Index: Status.pm
===
RCS file: /home/cvspublic/modperl/lib/Apache/Status.pm,v
retrieving revision 1.26
diff -u -r1.26 Status.pm
--- Status.pm 23 May 2002 16:14:56 - 1.26
+++ Status.pm 30 Jul 2002 12:39:07 -
@@ -514,6 +514,7 @@
mkdir $dir, 0755 unless -d $dir;
(my $thing = $r-path_info) =~ s:^/::;
+$thing =~ s{::}{-}g; # cause some OS's dont' allow :: in filenames
my $type = dot;
my $file = $dir/$thing.$$.gif;
Thanks, committed
__
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
Re: mod_perl2 DBD::Oracle problem
Atsushi Fujita wrote:
Hi all,
I am trying to use DBD::Oracle1.12 on mod_perl2.
But it doesn't work fine.
It shows error as following in error_log at $dbh = DBI-connect.
[error_log]
DBI-connect(ynt0) failed: (UNKNOWN OCI STATUS 1804) OCIInitialize. Check
ORACLE_HOME and NLS settings etc. at
/yopt/httpd-2.0.39_prefork_perl5.6.1normal/cgi-bin/test1.cgi line 42
[Mon Jul 29 20:15:37 2002] [error] 25703: ModPerl::Registry: `Cannot connect:
(UNKNOWN OCI STATUS 1804) OCIInitialize. Check ORACLE_HOME and
NLS settings etc.at
/yopt/httpd-2.0.39_prefork_perl5.6.1normal/cgi-bin/test1.cgi line 42.
[test1.cgi]
use DBI;
my $dsn = 'dbi:Oracle:';
my $user = 'username/password';
my $password = '';
$ENV{'ORACLE_HOME'} = '/u01/app/oracle/product/9.0.1';
$ENV{'ORACLE_SID'} = 'ynt0';
$ENV{'NLS_LANG'}= 'japanese_japan.ja16euc';
print ORACLE_HOME=$ENV{'ORACLE_HOME'}br\n;
print ORACLE_SID=$ENV{'ORACLE_SID'}br\n;
print NLS_LANG=$ENV{'NLS_LANG'}br\n;
print DSN=$dsn$ENV{'ORACLE_SID'}br\n;
$dbh = DBI-connect($dsn$ENV{'ORACLE_SID'}, $user, $password)
or die Cannot connect: .$DBI::errstr;
...
At first, I suspect that the reason is %ENV in this script.
But I set surely, and this output as following.
[Broser output HTML]
ORACLE_HOME=/u01/app/oracle/product/9.0.1
ORACLE_SID=ynt0
NLS_LANG=japanese_japan.ja16euc
DSN=dbi:Oracle:ynt0
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to
complete your request.
And if I turned off the mod_perl, it works fine on normal CGI-script.
This error occurred only mod_perl.
(I tested mod_perl1.26 apache 1.3.26, it worked fine...)
My machine is as following.
- perl5.6.1(non thread)
- DBI-1.30
- DBD-Oracle-1.12
- mod_perl1.99_04(DSO build)
- apache2.0.39(prefork)
[httpd.conf](is this wrong??)
LoadModule perl_module modules/mod_perl.so
...
IfModule mod_perl.c
PerlModule ModPerl::Registry
Location /cgi-bin
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
Options +ExecCGI
/Location
/IfModule
Do you suggest that %ENV is getting lost along the way? Or can it be
some other problem? I don't have Oracle to test with. Or can you think
of some other way to reproduce the problem without depending on Oracle
being installed?
Can you please test with the following two approaches:
1.
instead of using ModPerl::Registry, use Apache::Registry. Of course
configure Location to use Apache::Registry.
use Apache::compat;
use Apache::Registry; # hopefull you have mod_perl 1.0 installed
any change when you use the Apache::Registry from 1.0? Currently the
only difference (mainly) is that ModPerl::Registry doesn't chdir() into
the script's dir. (which eventually will change)
2. use a mod_perl handler
__
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
Re: $r-dir_config-(un)set issue...
simran wrote:
Hi All,
I have a situation where it is convinent for me to define a global
PerlSetVar in my httpd.conf and then unset it for particular virtual
hosts.
I used to use the following configuration successfully:
httpd.conf
--
Perl
use Apache::Server;
Apache-server-dir_config-unset(MyVar);
/Perl
-
That stopped working for me ever since we compiled
Apache/1.3.26 (Linix - Debian) with mod_perl/1.27
Has anyone else had the same issue?
On a similar note:
The following pices of code do not work:
-
code sample 1
--
1. sub handler {
2.my $r = instance Apache::Request(shift);
3.
4.$r-dir_config(MyVar = undef);
5.
6.$r-dir_config-unset(MyVar);
7.
8.$r-dir_config-set(MyVar = undef);
9.
10. }
s/$r-dir_config/$r-server-dir_config/?
What's really needed is probably PerlUnSetEnv.
None of lines 4, 6 or 8 actually unset the variable.
A collegue tells me that if a true value (for the key MyVar) is not
passed to set then it ends up returning the value of MyVar - but then
how i want to set the value of MyVar to be false. I would have though
that unset/set would have specifically done what i told them to
unset/set rather than do fancy things with truth values...
Ideas anyone?
simran.
--
__
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
Re: Problems with Apache/Mod_perl Server
Alfred Vahau wrote: Hello, I am posting this matter to the list because it takes so long from my end of the world to download the relevant information for trouble shooting. My problem is as follows: I downloaded mod_perl-1.26 and apache_1.3.24 in May this year. I followed all the instructions in the mod_perl guide on how to set up the server and had it running successfully without any problems. Now I decided to upgrade to mod_perll-1.27 and apache_1.3.26. I downlloaded from the mirror site at nagoya. I am following the same instructions which are, after uncompressing them: 1. perl Makefile.PL APACH_SRC = ../apache_1.3.26/src \ DO_HTTPD = 1 USE_APACI = 1 EVERYTHING = 1 Everthing goes smoothly. Then: 2. make make test make install The executiion is smooth until the test part which I believe fails and hence the install leg is aborted? The error output at the end is: ../apache_1.3.26/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t httpd listening on port 8529 will write error_log to: t/logs/error_log letting apache warm up...\c done /usr/bin/perl t/TEST 0 still waiting for server to warm up...not ok server failed to start! (please examine t/logs/error_log) at t/TEST line 95. make: *** [run_tests] Error 9 The t/logs/error_log reads [notice] Destruction-DESTROY called for $global_object Prototype mismatch: sub Socket::INADDR_ANY vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 328. Prototype mismatch: sub Socket::INADDR_BROADCAST vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 329. Prototype mismatch: sub Socket::INADDR_LOOPBACK vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 330. Prototype mismatch: sub Socket::INADDR_LOOPBACK vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 331. [Wed Jul 31 13:12:16 2002] [warn] [notice] child_init for process 3690, report any problems to [no address given] [...] I think the failure is due to incomplete mod_perl installation. of course. You run: make make test make install 'make test' fails, and therefore 'make install' is not run. simply run it. regarding the failing 'make test', you say that you run 5.6.1, and the error shows 5.6.0 in the path, how so? what your 'perl -V' says? I guess you have libs from 5.6.0 installed and they get on the way. __ 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
Re: mod_perl 2.0 api and extending method in Apache
Alexandre Dulaunoy wrote:
Hello,
I have look around the documentation of mod_perl 2.0 and I'm looking if
it's possible with the current mod_perl API to add a method (like GET,
HEAD) in apache to extend the functionnaly of the HTTP server ?
There is also some possibility with the new framework to add new protocol
(like the echo example in the mod_perl doc). But I just want to extend
existing (or add new) method... Is it possible ?
I'm not sure what you mean by extending, but look at mod_dav which
extends the HTTP protocol: modules/dav/main/mod_dav.c (inside the
httpd-2.0 repository).
In mod_perl 2.0 you can support new request methods, by simply
registering them. e.g. let's support the method 'TNT' in the response
handler:
Location /extend
SetHandler perl-script
PerlResponseHandler Apache::Extend
/Location
package Apache::Extend;
use strict;
use warnings;
use Apache::RequestRec ();
use Apache::RequestIO ();
use Apache::RequestUtil ();
use Apache::Const -compile = 'OK';
use constant METHNAME = 'TNT';
sub handler {
my $r = shift;
$r-content_type('text/plain');
Apache::method_register($r-pool, METHNAME);
print Called with Method: . $r-method;
Apache::OK;
}
1;
Now, let's call:
perl -le 'require LWP::UserAgent; print
LWP::UserAgent-new-request(HTTP::Request-new(GET,
http://localhost:8002/extend/;))-content;'
Called with Method: GET
__
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
cvs commit: modperl Changes
stas2002/07/30 19:10:16
Modified:lib/Apache Status.pm
.Changes
Log:
fix Apache::Status to not use :: in filenames, which is not allowed on
certain OSs
Submitted by: DH [EMAIL PROTECTED]
Revision ChangesPath
1.27 +1 -0 modperl/lib/Apache/Status.pm
Index: Status.pm
===
RCS file: /home/cvs/modperl/lib/Apache/Status.pm,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- Status.pm 23 May 2002 16:14:56 - 1.26
+++ Status.pm 31 Jul 2002 02:10:15 - 1.27
@@ -514,6 +514,7 @@
mkdir $dir, 0755 unless -d $dir;
(my $thing = $r-path_info) =~ s:^/::;
+$thing =~ s{::}{-}g; # :: is not allowed in the filename on some OS
my $type = dot;
my $file = $dir/$thing.$$.gif;
1.654 +3 -0 modperl/Changes
Index: Changes
===
RCS file: /home/cvs/modperl/Changes,v
retrieving revision 1.653
retrieving revision 1.654
diff -u -r1.653 -r1.654
--- Changes 19 Jun 2002 16:31:52 - 1.653
+++ Changes 31 Jul 2002 02:10:16 - 1.654
@@ -10,6 +10,9 @@
=item 1.27_01-dev
+fix Apache::Status to not use :: in filenames, which is not allowed on
+certain OSs [DH [EMAIL PROTECTED]]
+
various cygwin fixes [Per Einar Ellefsen [EMAIL PROTECTED]]
fix to compile with 5.8.0 on win32 [Randy Kobes [EMAIL PROTECTED]]
Re: Problems using Perl v 5.8
[EMAIL PROTECTED] wrote: Does it help to update mod_perl to 1.27? and if not, please send to the list the shortest possible script that reproduces the problem. Pasquale Pagano [EMAIL PROTECTED] on 07/29/2002 12:35:10 PM To: Modperl [EMAIL PROTECTED] cc:(bcc: Wesley Sheldahl/Lex/Lexmark) Subject: Problems using Perl v 5.8 Hi, We have some problems using: 1) Perl v 5.8 2) Mod_Perl v 1.26 3) Apache v 1.3.26 In particular: a) if we use simple CGI, everything works fine; b) if we use a custom handler for mod_perl, everything works fine; but if we try to use our CGI via Apache::Registry or Apache::PerlRun handler the code is ran correctly but we are able to send back to the browser only the HTTP header (everything else is missed). Here below an example of the http response -__- HTTP/1.1 200 OK Date: Mon, 29 Jul 2002 17:20:02 GMT Server: Apache/1.3.26 (Unix) mod_perl/1.26 Transfer-Encoding: chunked Content-Type: text/html; charset=ISO-8859-1 0 -__- Any of you have some hints?? Any help will be welcome, Regards, Lino PS: The same code works fine using Perl v 5.7.2. .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- Pasquale Pagano CNR - Istituto di Elaborazione della Informazione Via G. Moruzzi, 1 - 56124 Pisa,Italy Area della Ricerca CNR di Pisa Tel +39 050 3152891 E-mail: [EMAIL PROTECTED] .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- -- __ 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
Re: make test problem error 111
Padraic Woods wrote: Hi, I'm trying to install apache + mod_perl + mod_ssl but get a error after running make test, I've tried skiping the make test but get a segmentation fault when I try starting apache. [...] ../apache_1.3.26/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t httpd listening on port 8529 will write error_log to: t/logs/error_log () gets absurdforkletting apache warm up...\c that's an interesing message: gets absurdfork where does it come from? no error_log is bad, have you tried following the install notes in: http://perl.apache.org/docs/1.0/guide/install.html#mod_perl_and_mod_ssl___openssl_ if you get a segfault, please follow the instructions at: http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems __ 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
Re: while - modperl 2.0/Apache 2.0
ok, looks like your setup is fine.
Though I cannot seem to reproduce your problem. Indeed it seems that the
unbuffered output doesn't work. I'm checking on that. But I've devised a
better test that verifies that the requests aren't serialized. If you
run this hander by two clients at the same time, you should see the
lines in /tmp/test123 being interleaved by two processes. If this
doesn't happen and you get first 100 lines from process A followed by
process B's 100 lines than indeed we have a problem.
sub handler {
my $r = shift;
$r-content_type('text/plain');
local $| = 1;
open my $fh, , /tmp/test123 or die $!;
my $oldfh = select($fh); local $| = 1; select($oldfh);
my $i = 0;
while ($i 100) {
$r-print($$: $i \n);
print $fh $$: $i \n;
sleep 1;
$i++;
}
$r-print(__PACKAGE__);
close $fh;
return Apache::OK;
}
If this indeed doesn't work, please try the suggestion at:
http://perl.apache.org/docs/1.0/guide/debug.html#Using_the_Perl_Trace
so you can see where the second process is stalled. If you don't get
anything from this approach try to attach to the second process with gdb
and see where it is stack on the C calls level. Though I suggest that
you test with prefork and this setup:
IfModule prefork.c
StartServers 2
MinSpareServers 2
MaxSpareServers 2
MaxClients 2
MaxRequestsPerChild 0
/IfModule
__
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
Re: New mod_perl site and oddness with IE
[Let's move this thread to the docs-dev list, otherwise we make an OT noise at the modperl list, so, please, when replying to this email, remove the modperl address from it. thanks!] Has anyone else had problems with this particular page under IE (6.0.2600 under XP) being extremly slow to update when paging up/down? It works fine under Mozilla, and it's not a memory or cpu issue (checked with task manager already). And when I say slow, I mean a simple down cursor causes the visible portion of the page to get painted in 4 noticble steps/chunks. --Jim please check if the problem exists on this url: http://www.bullitt.suite.dk/clean3/dst_html/docs/1.0/guide/performance.html if you have other browser software, please check and see if anything else is broken there as well. Allan, You are trying to solve it by applying HTML::Clean, which reduces the size of the page, right? But even if it does solve the problem for this particular page, what happens if the page grows, or there is some other page which is bigger, and no cleanup will make it small enough to make IE happy. __ 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
Re: How to see debug information in Net::Smtp?
[EMAIL PROTECTED] wrote: I use Net::Smtp module in my mod_perl script. When I run the fragment of my code from command line I can see the debug info. But running it on the production server I can't see the debug information. What can I do to see the debug info on the production server? look in the error_log file? __ 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
Re: How to see debug information in Net::Smtp?
Peter Werner wrote: and set your LogLevel to debug why? after all he is talking about perl logging, not Apache. LogLevel has nothing to do with it. -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 17, 2002 10:27 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: How to see debug information in Net::Smtp? [EMAIL PROTECTED] wrote: I use Net::Smtp module in my mod_perl script. When I run the fragment of my code from command line I can see the debug info. But running it on the production server I can't see the debug information. What can I do to see the debug info on the production server? look in the error_log file? __ 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 -- __ 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
Re: END subroutine in Apache::Registry
Hi Jim, The documentation is neither unclear nor confusing. However, the implication was not obvious (well... not obvious enough) when I first read this section three years ago. If you're sincere about wanting suggestions, here's mine: of course :) In addition to understanding the behavior of END blocks in Apache::Registry scripts, a script writer must realize that any module invoked via use or include may work differently than its designer intended, if that module contains END blocks. great, will add that. Though I've noticed that it works this way only if you 'use'. if you 'require' it's being ignored completely (not even run on the shutdown), is it just me or do you see the same? seems like a bug to me, unless I'm missing something. Thanks Jim! -Jim On Fri, 12 Jul 2002, Stas Bekman wrote: Jim Schueler wrote: I just read the fine print: Apache::Registry runs BEGIN subroutines just once per child process, but END routines run every time a script is run. The implication is that an otherwise robust module may behave unexpectedly when it's imported by an Apache::Registry script. Doesn't this cause problems for mod_perl users? There is no mention of this issue in either mod_perl_to_cgi or mod_perl_traps. Admittedly, most of the code in my END subroutines should probably be refactored into OO DESTROY subroutines anyways. But if not burned, I've been significantly scalded by this belated realization. I don't see anything on CPAN that can be easily applied to all of the modules that written. I'll happily fill that void, but I must be overlooking the obvious solution. Can anyone provide any insights? Please read: http://perl.apache.org/release/docs/1.0/guide/porting.html#END_blocks The special case is for registry scripts that include END blocks. If the the explanation at the above URL is unclear/confusing, please suggest how to improve it. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- __ 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
Re: TIPool / multiple database connections
Perrin Harkins wrote:
Elizabeth Mattijsen wrote:
Hmm... but you won't be able to fetch the $dbh from the thread. It
can only live in _that_ thread. You cannot pass objects between
threads. But you _can_ send queries to that thread, fetch a jobid for
that job and then obtain whatever was returned as a Perl datastructure.
(if anyone knows of a way to pass objects between threads, I'd really
would like to know)
Hmmm... That could really throw a wrench in things. If you have an
object based on a hash, and you share that hash, and you re-bless the
object in each thread, does that work? What if the hash contains
references to other variables. Do they need to be explicity shared as
well?
That's what I meant. Probably non need for Thread::Pool, at all. use a
shared datastructure, maintain a list of free and busy items and simply
hand pointers inside this datastructure to the threads asking for an
item. e.g.:
package DBI::Pool;
use threads::shared;
my @pool : shared;
sub init {} # pre-populate pool with N connections
sub get {} # return a ref to $dbh, grow the pool if needed
sub put {} # move the pointer from the busy list to the free list
won't this work? I guess Perrin is right in respect that the whole item
needs to be shared (deep-shared). can we have such an attribute/function
that will automatically traverse the datastructure and share it all? or
is this the case already with 'shared'?
Now since we want to have various connections, it can be:
my %pools : shared;
where each key is a unique identifier, compiled from the dbi connect's
DSN string and a value is the actual pool.
BTW, there is no more need for Apache prefix in Apache::DBI, this can be
a generic Pool class. I guess Apache::DBI can subclass DBI::Pool and add
things like connect_on_init(), but just to build the initial pool when
the process starts.
__
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
Re: Persistent Net::Telnet Objects in Apache2/mod_perl2
French, Shawn wrote: Stas Bekman wrote: It seems that you are after the same functionality as Apache::DBI, you want a pool of items that you want to be able to choose from. Look for threads::shared (perl 5.8.0), just create a shared hash with keys that you use for the map and the values for the actual connection objects. YES!!! That is exactly what I need! Where do I find perl 5.8.0 and threads::shared? I need a perl binary for windows since I'm without a compiler... Wait about one more week and it's going to be released. e.g. see http://use.perl.org/ As for the apache notes, I hope your right that it would be easy to implement, otherwise I can't upgrade to apache2 without some _huge_ workarounds... which are always nice to avoid :) Apache 2.0 wasn't released yet in any case. __ 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
Re: Getting to the Guide PDF on the new website
Gunther Birznieks wrote: At 09:24 PM 7/13/2002, Stas Bekman wrote: Gunther Birznieks wrote: I agree! It is great work. It looks really slick. :) Unfortunately, the mod_perl guide documentation area has lost functionality. I wanted to download the latest guide before my 23 hour flight to the USA (to read on the flight) and was dismayed to find hours before my flight that it is impossible to get a full HTML or full PDF download of the entire guide anymore... You can get a PDF of single pages (of which I don't know the reason?), but the guide itself is quite hard. eh? what do you mean? it's all there, go to: http://perl.apache.org/docs/1.0/guide/index.html click on the pdf button in the right upper corner and you get this: http://perl.apache.org/docs/1.0/guide/guide.pdf Notice though, that parts non-specific to mod_perl 1.0 has now moved to http://perl.apache.org/docs/general/index.html Oh I see it does work. I suppose the PDF buttons on every page is what confused me though. So if you go to the front-page of the docs section, just the front-page gets generated in a PDF, if you go to a page within the guide, then just that section gets generated. The only PDF icon that actually generates a full guide (and it is inconsistent with what the rest of the website PDF icons do) is the actually guide.pdf. A constructive suggestion would be that the icon for PDF on the main guide page should explicitly say PDF of entire guide or something other than the simple PDF icons on all the other pages of the website. Or perhaps remove the PDF icons entirely off the rest of the website. After all, who really wants to generate a PDF of a single HTML page they already read? Well, if you don't want to read the PDF of a single page, that doesn't mean that others think the same. People like reading of the paper and not the screen. The new site is based on docsets stacking. Each root node includes chapters and other docsets. Each root node builds the pdf of all its immediate leaf nodes (chapters). Each leaf (chapter) builds a pdf of itself. Notice that root nodes do *not* include chapters included in the nested docsets, otherwise the very root pdf will be of 50MB in size. I don't really follow your confusion. If you read the chapter 'help' and you click on the pdf icon you get this chapter in pdf. if you are reading the index page and click on the pdf you get the whole thing. It's just more flexible now than it used to be. I guess the only confusion might be with docsets that include no chapters, but only other docsets, so if you click on the pdf icon at /docs/1.0/ you get an almost empty pdf. But I guess people will learn how things work and find the infrastructure useful. __ 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
Re: TIPool / multiple database connections
Liz, should we move this thread to the perl-ithreads list so we can get some answers from the threads gurus? or p5p? I doubt Arthur is listening on this list. __ 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
Re: Working Directory
Matt Sergeant wrote: On Fri, 12 Jul 2002, Stas Bekman wrote: Josh Bernstein wrote: After just upgrading to mod_perl2 with Apache2. My current @INC path includes a . on the end, which should reference the current working directory, and therefore correctly locate include locate in the script's working directory. The problem is that the Working Directory is set to /. My question is how can I set the working directory to be the location of where the script is running. (This would make mod_perl correctly locate file that I have included in the running script ie: require ./file.pl) Can this be done from within Apache? I've tried variations of PerlSetEnv but I can't seem to get it to work. I've even read the mod_perl2 user's guide. Thanks for your help.. chdir is not a thread-safe function, (there is only one CWD per application) therefore the new ModPerl::Registry doesn't chdir to the dir of the script. We have discussed various workarounds on the dev list, but none of them has been applied yet. http://mathforum.org/discussions/epi-search/modperl-dev.html (search for 'chdir thread') Arthur told me he either had, or was going to fix this (on IRC). Yup, Arthur is working on an external package (ex::threads::safecwd?) which should solve this problem. Viva Arthur! I'll keep you updated once it gets released. __ 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
Re: Apache SSL - how to start it in -X mode
[EMAIL PROTECTED] wrote: How to restart SSL Apache in -X mode? This is a wrong forum. See: http://httpd.apache.org/lists.html#http-users __ 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
Re: Working Directory
Elizabeth Mattijsen wrote: At 06:10 PM 7/16/02 +, Stas Bekman wrote: Arthur told me he either had, or was going to fix this (on IRC). Yup, Arthur is working on an external package (ex::threads::safecwd?) which should solve this problem. Viva Arthur! I'll keep you updated once it gets released. Check out Arthur's article on Perl.com: http://www.perl.com/pub/a/2002/06/11/threads.html I read the article ;) The article doesn't say that there is going to be a module that will do all this work for you. I just wanted to share the happy news that such a module is about to emerge. Most of the people don't care how things are implemented, they just want to know that the API they use is thread-safe, which is how it should be with chdir() and friends. Though you realize that that this wrapper will incur a certain overhead, which needs to be benchmarked. And if that overhead is of any significant value, we should provide a switch to turn if off for those who don't rely on chdir() and therefore can get a better performance. I'm talking mainly about the Registry family in this case, but I can see that this functionality could be provided on the mod_perl core level (PerlSafeCwd flag?). __ 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
Re: worker thread
Pasquale Pagano wrote:
We are trying to use:
1)Apache 2.0.39 compiled with the option --with-mpm=worker
2)with modperl 2.0
under Sun Solaris 2.8 with Perl 5.8 RC2.
Although everything seems to work fine, the creation of a custom worker
thread takes more or less 2 minutes.
Here below a section of the code used:
my $t1 = new Thread(\my_thread,'t1');
my $t2 = new Thread(\my_thread,'t2');
$t1-join();
$t2-join();
sub my_thread{
my $name = shift;
print I'm $name\n
return $name: done\n;
}
In the example above, each new thread call takes about 2 minutes.
May I ask, why do you create these threads? Under worker you already
have the threads created for you and and the perl interpreters handed to
you when you need them.
BTW, what happens if you run the same code from the command line?
__
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
Re: relative path not accepted in mod_perl2 ?
[EMAIL PROTECTED] wrote: just found out the deeper reason - mod_perl now always has path=/ which is unexpected behaviour. While I can filter out the actual path from the cgi-environment I dont understand this .. See the parallel thread on the same topic. http://mathforum.org/epigone/modperl/smansheezhing Things will work as expected by the time mod_perl 2.0 is released. [funny that mathforum's engine has mixed this thread with a thread with the same title but from 5 years ago. Looks like the time has crossed itself] -- __ 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
Re: Apache::Registry and Apache::PerlRun
Boex,Matthew W. wrote: question, can i have both Registry and PerlRun running in the same environment? i have my cgi scripts running under Apache::Registry in one directory, and want to run a legacy cgi script under PerlRun in another directory. is this possible? matt of course. That's how it works. You can even run the same scripts under different handlers. Have you tried and it didn't work for you? -- __ 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
Re: R: worker thread
Pasquale Pagano wrote: From the command line, it works very well. We are impleminting a very complex digital library system. In same cases, we want to start parallel threads in order to minimize the wait. Let me try to explain with an example. 'A' start 4 threads, each of which prepares, and sends a request to another server, and then collects its result. When all threads will be terminated, 'A' will merge the 4 results. Is now more clear? sure, thanks your problem is that you use the *old* threads (5005threads, pre-5.6.0), whereas mod_perl 2.0 is using ithreads (5.6.0+). my $t2 = new Thread(\my_thread,'t2'); ^^^ do 'perldoc threads' with perl-5.8.0 __ 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
Re: Purify, Perl and mod_perl
Perrin Harkins wrote: [...] My question is this...can I run my application using this purified perl under mod_perl to track down potential memory leaks and other problems? You probably don't have any memory leaks. Most things that people refer to as leaks are just normal growth. A leak is when an area of memory gets lost because the program that allocated it forgets to free it. or cannot free it because of the closure or a circular reference, which seems to be the case with the bug in Apache::Request reported by Dave Rolsky. [...] A number of the most common sources of memory growth are explained in the guide: http://perl.apache.org/docs/1.0/guide/performance.html#Improving_Performance_by_Prevention Plus Apache::Leak, whose reports should be carefully analyzed because not everything that it reports as a leak is actually a leak: http://perl.apache.org/docs/1.0/guide/debug.html#How_can_I_find_out_if_a_mod_perl_code_has_a_memory_leak __ 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
Re: problem compiling modperl2.0
Harry Zhu wrote: I am trying to create a test environment for modperl2.0/apache2/perl5.8 under RedHat7.3. As root, I did the first step, download using the cvs to get the modperl-2.0, httpd-2.0 and apr, apr-util (placed in httpd-2.0/srclib). make make install is fine. I using rsync to get the Perl, and the 'make's are fine and linked to /root/bleedperl/bin/perl. The install LWP under the new perl is also fine. Now come to the modperl2.0: root /root/bleedperl/bin/perl Makefile.PL MP_AP_PREFIX=/root/httpd-2.0 Reading Makefile.PL args from @ARGV MP_AP_PREFIX = /root/httpd-2.0 Configuring Apache/2.0.40-dev mod_perl/1.99_05-dev Perl/v5.8.0 And a bunch of the following !!! Unable to open /root/httpd-2.0/include/apr.h: No such file or directory Have you configured httpd-2.0 already? do that first before moving onto modperl __ 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
Re: [modperl2] Perl Connection Handlers for SSL connections
Pete Rothermel wrote:
I've got the example echo() handler working for a non-HTTP protocol as
outlined on the new web site:
http://perl.apache.org/docs/2.0/user/handlers/handlers.html#Command__Protocol__Phases
Anybody have a similar example for the same protocol handler over SSL?
the echo protocol working over the socket skips filters, so it won't
work with SSL.
at the above URL scroll down to the Apache::Eliza2 example, which uses
bucket brigades and therefore should work over SSL.
I didn't have a chance to document it yet, but for simple things you
just change the code inside this snippet:
if ($data) {
$data =~ s/[\r\n]*$//;
$last++ if $data =~ /good bye/i;
$data = $eliza-transform( $data ) . \n\n;
$bucket = APR::Bucket-new($data);
}
the rest most likely will stay unmodified.
__
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
Re: while - modperl 2.0/Apache 2.0
Udlei Nattis wrote:
hi
sorry my english
i have one problem
when i open 2 browsers intance and access my perl script
instance 1 run script OK
instance 2 waiting instance 1 finalize to run :/
i need run simultane 2 instance
(modperl 2.0 dev 5 / perl 8 rc 3 / apache 2.0 prefork or worker )
how many servers do you run? Are you testing this in the single server
mode? Seems that you run only one server or only one process with one
thread.
a few comments regarding the code (irrelevant to your problem):
#!/usr/bin/perl
use Apache2;
this should go into startup/httpd.conf.
$| = 1;
my $r = Apache-request;
that should be just:
my $r = shift;
since your code is wrapped into sub handler { }.
what you are doing is expensive under threads.
__
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
Re: Working Directory
Josh Bernstein wrote: Sounds great? Does he have anything that I could play with? I'm really dying for that chdir(), my programmer says he depends on that functionality. I'd even volunteer to do some benchmarks and what not associated with the extra overhead of making the function thread safe. He should probably announce it soon, when he returns from vacation. why don't you test with prefork for now? and Apache::compat + Apache::Registry from 1.x? If its not really yet, what do you feel is currently the best work around? I've read through the archives and I'm just try to figure which one to use... there are no workarounds to having a thread-safe cwd, other than using full paths. -Josh Stas Bekman wrote: Elizabeth Mattijsen wrote: At 06:10 PM 7/16/02 +, Stas Bekman wrote: Arthur told me he either had, or was going to fix this (on IRC). Yup, Arthur is working on an external package (ex::threads::safecwd?) which should solve this problem. Viva Arthur! I'll keep you updated once it gets released. Check out Arthur's article on Perl.com: http://www.perl.com/pub/a/2002/06/11/threads.html I read the article ;) The article doesn't say that there is going to be a module that will do all this work for you. I just wanted to share the happy news that such a module is about to emerge. Most of the people don't care how things are implemented, they just want to know that the API they use is thread-safe, which is how it should be with chdir() and friends. Though you realize that that this wrapper will incur a certain overhead, which needs to be benchmarked. And if that overhead is of any significant value, we should provide a switch to turn if off for those who don't rely on chdir() and therefore can get a better performance. I'm talking mainly about the Registry family in this case, but I can see that this functionality could be provided on the mod_perl core level (PerlSafeCwd flag?). __ 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 -- __ 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
Re: New mod_perl site and oddness with IE
Jim Helm wrote: Has anyone else had problems with this particular page under IE (6.0.2600 under XP) being extremly slow to update when paging up/down? It works fine under Mozilla, and it's not a memory or cpu issue (checked with task manager already). And when I say slow, I mean a simple down cursor causes the visible portion of the page to get painted in 4 noticble steps/chunks. An older version I tracked down with Google (http://www.apache.jp/perl/guide/performance.html) which is also 300K+ doesn't have the same problem - just to show that it's not purely the raw size of the page that is the problem. Just a little feedback for the new site (which is great, btw). If it's just me with the problem, I'll go find a rock to hide under. :) Is the size of the page causes the trouble? I don't have IE to try so hopefully someone will help us out here. What happens if you shorten the content of the page? My guess is that IE simply cannot cope with a long page and the current complex stylesheet (because as say it works fine with the same page and a simpler stylesheet, which includes no layout instructions). Suggestions on how to fix that are welcome. __ 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
Re: Accessing mod_ssl information from mod_perl modules
Byron Ellacott wrote: Hi, I've been trying rather unsuccessfully to write an Authen handler that is able to detect an SSL connection and use the SSL certificate serial as an index into a database table. The problem I'm facing is how to discover the SSL connection information in an Authen handler. At a later phase, the SSL certificate is available in $r-subprocess_env(), in various forms. I can, for example, turn on SSLOptions +StdEnvVars and access $r-subprocess_env(SSL_CLIENT_M_SERIAL) and get what I'd expect. However, authenticating and authorizing in the Response phase has several downsides. The first is that there are phases specifically for this work. The second is that if (when) I want to replace SSL authentication with Basic, or with JRandomAuthenModule, I'll have to modify my Response handler, or have it do an ifthenelsifthenelse block. So, from reading the mod_ssl source, it appears all the information I want is attached to the request object in a pool. APR::Pool has no manpage, I can't figure out how APR::Pool ties into the mod_perl source code, and basically I'm completely stuck with no idea how to, or even if I can, access this information. You are talking about mod_perl 2.0, aren't you? Please make that clear upfront, preferrably in the subject of your post. What do you need APR::Pool for? What are you trying to do (code sample) and failing to? APR::Pool is just a class that encapsulates the apr_pool objects. There is not much you can do with these objects. You can find the sample usage in t/response/TestAPR/pool.pm. As previously mentioned here, currently if you need to know how a new Apache:: or APR:: class works, your best source of information is the test suite, unless you prefer to look at the source code. The new manpages won't be written until we get the automated docs generation based on httpd-2.0 header files working. There are too many manpages and the API is still changing so it doesn't worth doing any manual work before it gets frozen. __ 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
Re: TIPool / multiple database connections
Tim Keefer wrote: I need to have several database connections within one modperl application (sharing the connections across all modules would ideal). Could anyone suggest a way to cache these connection with Apache2/modperl2 on win32? The modperl2 docs talk about a TIPool module along with a DBIPool module. Has anyone had success using these modules? I can't seem to find them in the apache2/modperl2 distribution from Randy Kobes. Thanks for any help, If you are talking about prefork, Apache::compat with Apache::DBI should do. If you are talking about threaded mpms, the TIPool idea stays just as an idea, because now we have threads::shared that will do. Just give it some time because there is lot of work being done in that direction as you read this. Gerald Richter and Tim Bunce are working on the thread-safe DBI. A few folks at p5p are creating a bunch of new modules around threads:: and threads::shared::, just yesterday a new module: Thread::Pool was released by Elizabeth Mattijsen. Which seems to be what's needed for Apache::DBITPool. Feel free to join the efforts and make things happen faster. __ 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
Re: TIPool / multiple database connections
Elizabeth Mattijsen wrote: At 12:18 AM 7/16/02 +, Stas Bekman wrote: ...A few folks at p5p are creating a bunch of new modules around threads:: and threads::shared::, just yesterday a new module: Thread::Pool was released by Elizabeth Mattijsen. Which seems to be what's needed for Apache::DBITPool. Hmmm... I guess you're right. I hadn't thought of applying Thread::Pool in this situation, but it sure makes sense. This would however imply that jobs would be submitted from different threads. That _should_ work, but I just realised that I don't have a test-case for that. Will work on one and let you know the result. I think that's a reverse case, the pool creates the dbh items (tools) and workers pick the items use them and then put back when they are done with them. So it's the pool who creates the things. btw, one thread should be able to pick more than one item at once. but in this particular case of DBI, I think there should be a different pool for each connectin group. similar to what Doug has suggested in his original TIPool prototype in the overview doc. __ 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
Re: Persistent Net::Telnet Objects in Apache2/mod_perl2
French, Shawn wrote: Hey everyone, It's me again... the persistent telnet mod_perl newbie! (http://msgs.securepoint.com/cgi-bin/get/apache0205/204.html) I have implemented my project using persistent telnet connections (one for each user session accessible throught the session to perform various functions through telnet) on win2000: Apache/1.3.26 (Win32) mod_perl/1.27_01-dev Now for my next trick! When I started I didn't realize that mod_perl on win32 could only handle one request at a time!!! This is obviously not acceptable for deployment. So, I would like to upgrade to Apache2/mod_perl2 to take advantage of the multi-process mod_perl model that the _very_ kind Randy Kobes told me about (http://groups.google.ca/groups?dq=hl=enlr=ie=UTF-8oe=UTF-8selm=afv3gu% 24qt2%242%40canopus.cc.umanitoba.ca). However, with a multi-process model, I'm not sure how I will be able to keep a user's telnet-session-object accessible throughout multiple requests. Currently it's not a problem since there's only one process for ALL mod_perl requests. In Apache2/mod_perl2 there will be more than one process so I need some sort of mapping to make sure my clients are aways served by the same process. Is this possible? Am I in way over my head (again!!) ? It seems that you are after the same functionality as Apache::DBI, you want a pool of items that you want to be able to choose from. Look for threads::shared (perl 5.8.0), just create a shared hash with keys that you use for the map and the values for the actual connection objects. If you can have the client persist the connection, you can implement a real protocol module. e.g., see: http://perl.apache.org/docs/2.0/user/handlers/handlers.html#PerlProcessConnectionHandler Another problem is that I have also been informed that my _MUCH_ used apache_notes function in php will not be available to me in Apache2 (http://bugs.php.net/bug.php?id=17557). I realize this is an Apache2 thing, but I was wondering if anyone here knows of a workaround that will allow my php scripts to communicate with mod_perl (and vice-versa) until (hopefully) the function is ported to Apache2. From what I understood mod_php in 2.0 is going to be implemented as a filter. Is that right? Is that the reason why notes won't work anymore? I don't think so. Practically there should be a problem to implement this feature, because you have a connection object which persists for the whole connection, so you should be able to register some data in this object and then retrieve it later in some other phase/filter. in mod_perl handler you simply get the connectin object and stick something into the notes, e.g. inside request handlers: my $r = shift; my $c = $r-connection; $c-notes-set(mod_perl = 'rules'); and then later for example in a mod_perl filter handler you do: my $f = shift; my $c = $f-connection; my $is = $c-notes-get(mod_perl); $f-print(mod_perl $is); you should ask php folks why cannot they get c-notes working, the C datastructure is all there waiting to be used. __ 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
Re: duplicate output with Registry.pm
Eric Frazier wrote: Hi, I know this is a FAQ sort of question, but I can't find it in the faq and I am going nuts. Like I know I know the answer to this, but I just can't get it back in my head. Any output under Registry.pm gets duplicated. One page = two doubled pages. I am using CGI::Application and HTML::Template, but I believe this is a mod_perl problem since it doesn't happen when I use the same scripts in a regular cgi-bin. Also if someone knows where I can find this on the web I would be grateful. I just can't seem to get the keywords right today. Looks like an application logic bug. Can you strip the extra elements (HTML::Template, etc), create a *short* script that reproduces the problem and post it to the list? __ 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
ANNOUNCE: mod_perl guide v1.32
This is probably the last announcement regarding the mod_perl guide's changes, because on the new mod_perl site all the changes are almost instant and the need for releases is pretty much not needed any more. Therefore remember to refer to the Changes file if you want to know what has changed since the last time you've read some docs. That said, there will be no more separate mod_perl_guide's releases on CPAN as they used to be, since the guide has now been merged into the mod_perl documentation. It's possible that we will start releasing the modperl-docs repository on CPAN instead. We will see. Meanwhile you can download and install locally the guide and the rest of the docs here: http://perl.apache.org/download/docs.html So here are the changes in the guide since Nov 15 2001: =head1 Jul 14 2002 ver 1.32 * snippets.pod: o new recipe: File Upload with Apache::Request [Rich Bowen] * cookbook o ported Passing Arguments to a SSI script from the modperl faq * method_handlers.pod o moved here from the faqs * databases.pod o correct the notes regarding Opening Connections With Different Parameters for Apache::DBI. Must localize local changes. * getwet.pod o a new chapter to get you started fast * porting.pod o add a new section Preventing Apache::Constants Stringification [Per Einar] o add a new section presenting a hackish solution for libraries collision, via do() or %INC mangling. o bring the warnings section up to date with perl 5.6 (Rafael Garcia-Suarez) o cover the 5.6's CHECK block in addition to INIT (Rafael Garcia-Suarez) * troubleshooting.pod o solution to the 'readdir()/opendir() not working' problem (Louis Semprini) o clearify how to solve the segfault problem caused by built-in mysql support in mod_php (Paul Buder) * modules.pod o extend on Apache::Filter (Per Einar Ellefsen) * config.pod o adopt sections from the modperl faq and rewrite the whole security configuration section o extended on method handlers (Per Einar Ellefsen) o show an example on how to load the mod_perl related config only when mod_perl is loaded (Rafael Garcia-Suarez) o More information about PerlSetEnv/PerlPassEnv/PerlSetupEnv w/ practical example[Per Einar] o Extend on PerlSetVar/PerlAddVar but more importantly, add information about subrequests w/ lookup_file and dir_config provided by Matt Sergeant in this thread: http://mathforum.org/epigone/modperl/praxdwumze [Per Einar] * debug.pod o extended on curinfo macro (Per Einar Ellefsen) * help.pod o chroot(1) urls o jail(8) urls (Andrew McNaughton) o link to the internal resources (Per Einar Ellefsen) * install.pod o James G Smith has uploaded his Apache Builder to CPAN, update the download links, to reflect this change. * performance.pod o add more benchmarking tools refs: HTTP::WebTest, HTTP::Monkeywrench, HTTP::TestEngine, HTTPD::Bench::ApacheBench o update the benchmark in the section Apache::args vs. Apache::Request::param vs. CGI::param using Apache::Request 1.0. o Update the documentation on Apache::SizeLimit and Apache::GTopLimit which now both sport the shared and unshared memory thresholds. o added a new section: Potential Drawbacks of Memory Sharing Restriction * intro o major additions to the introduction, including information about the C API and the Perl API and Apache::PerlRun, as well as some more corrections of links relative to the site. [Per Einar] * guide o most of the internal links were changed to use the whole title and not only first few words. The new build system support this. o The documents themselves are now referenced as guide::something, e.g. guide::modules, because now the guide is a part of a much bigger collection of the documents, which need to be fully qualified, so each document can link to other documents in different projects/subprojects. o added descriptions to all chapters (Per Einar Ellefsen) o The document structure has been reorganized and decentralized: some general chapters have left the Guide in favor of the General Documentation section, which is where you should look now for some of the sections that were earlier here [Thomas Klausner] * Minor corrections: o remove qw() or variables list in general::perl_reference (Tim Noll [EMAIL PROTECTED]) o install: (Per Einar Ellefsen [EMAIL PROTECTED], Karl Olson [EMAIL PROTECTED]) __ 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
ANNOUNCE: Perl 5.8.0 Release Candidate 3
). If all tests are not successful, you may get a more detailed report by changing to the t/ subdirectory and running the harness script, something like this cd t ./perl harness You may need to set up your dynamic library path before that (the final message of make test should tell all the needed details). The more detailed report will be very useful when your report problems. Knowing your exact configuration is essential, too: usually running the myconfig script from the build directory produces this information. Note that some systems or configurations have known problems, see perldelta for details, no need to report them. In case you still see errors, please document them via the perlbug system, as detailed in the INSTALL file, section Reporting Problems. Finally note that if you happen to have a less common platform, like some of the rarer UNIXes, or something even more exotic, we will be glad to hear even of successes, not just about possible problems. =head2 Installing Once you are happy with the test results of Perl itself (or you are just feeling extraordinarily brave), you may consider installing it. The Perl development team has tried to guarantee that popular Perl applications like CGI, LWP, mod_perl and DBI/DBD work with 5.8.0. Note work, not necessarily work without warnings: for example DBD::Oracle works, but during compilation and testing you may see various warnings. Also in some cases not all the functionality of the modules may be available (yet). However... THIS IS A REAL NEW PERL RELEASE THAT IS BINARY INCOMPATIBLE WITH ANY PREVIOUS PERL RELEASE. THIS MEANS THAT YOUR OLD EXTENSIONS (.xs code, those Perl modules requiring a C compiler) WILL NOT WORK AND WILL HAVE TO BE RECOMPILED. (Pure Perl modules should continue working.) INSTALLING THIS PERL RELEASE WILL OVERWRITE YOUR CURRENT PERL RELEASE. (For example, /usr/bin/perl will become Perl 5.8.0.) DO NOT INSTALL THIS INTO PRODUCTION USE UNLESS YOU REALLY MEAN IT. If you still feel like installing this, you can do so by make install. If you want to install this, but want to install it into some less dangerous place (and not overwrite your current installation), do the following make realclean sh Configure -des -Dprefix=/test/perl580 -Uinstallusrbinperl make all make test and then the make install. The -Dprefix will place the Perl installation at the said directory (the Perl executable will be /test/perl580/bin/perl), and the -Uinstallusrbinperl will avoid overwriting /usr/bin/perl with a copy of the Perl 5.8.0 executable. =head1 Testing The Perl Installation You should test both your own code, and other code that you use. =head2 Testing Your Own Code Test your own code with perl 5.8.0, but in case of surprises read the perldelta.pod carefully before judging something as a bug. In some cases the behaviour of Perl has changed. =head2 Testing Perl Modules You should try reinstalling your favourite CPAN modules to guarantee that they will continue working under Perl 5.8. Note that if you find some module either failing its tests or you see the tests emitting warning messages, please first and foremost report these problems to the author of the module. Advise him/her about the impending 5.8.0 release and where to get the RC3 (you might for example point the author to this very message). Since there are hundreds of modules available, the Perl 5 developer team is not qualified to be experts on all of them; it is much faster if the module author resolves any problems. In some cases you may also consider contacting some mailing lists to ask for help (and to spread awareness of the upcoming 5.8.0), for example if your operating system or the modules have mailing lists of their own. =head2 That's it. =head1 AUTHOR Jarkko Hietaniemi on behalf of the Perl 5 developer team =cut __ 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
Re: ANNOUNCE: the new perl.apache.org is alive now!
Nick Tonkin wrote: The content seems great. But whatever font you've used is rendering skinny and pixelated and hard to read and makes me want to egt of the site asap ... why not leave font face undetermined so the font that each has chosen for his platform is employed? Agreed 100%, my fonts suck too :( When I've changed the font-family to pick the good fonts on linux, users on other platforms didn't like that. We were thinking to try removing font-family completely. Does anybody know of any problems with this approach? __ 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
Re: Working Directory
Francesc X.Noria wrote: On Thu, 11 Jul 2002 16:56:38 -0700 Josh Bernstein [EMAIL PROTECTED] wrote: : /. My question is how can I set the working directory to be the : location of where the script is running. (This would make mod_perl : correctly locate file that I have included in the running script ie: : require ./file.pl) Can this be done from within Apache? Maybe you could use this trick: use FindBin qw($Bin); use lib $Bin; You cannot. FindBin does its magic in the BEGIN block, which will run only once under mod_perl. http://perl.apache.org/release/docs/1.0/guide/snippets.html#More_on_Relative_Paths you can do 'do FindBin', but you add the overhead. __ 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
Re: END subroutine in Apache::Registry
Please read: http://perl.apache.org/release/docs/1.0/guide/porting.html#END_blocks The special case is for registry scripts that include END blocks. If the the explanation at the above URL is unclear/confusing, please suggest how to improve it. It's pretty clear, and the bit about BEGIN blocks is right next to it, but it might be worth adding a note about the imbalance between BEGIN blocks and END blocks under Apache::Registry to cover this issue. I don't think there is really a need, but if we do so, the imbalance is between END and all *other* special blocks, like INIT, CHECK, BEGIN etc. So I believe that what is says now is just fine. The registry END block is the black sheep... __ 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
ANNOUNCE: the new perl.apache.org is alive now!
As you may know, the work on the new mod_perl site started in September 2001, and after almost a year we are glad to present to you the outcome of this work at the expected location: http://perl.apache.org/ and say good bye to the old site, which has now retired, but still can be retrieved from http://cvs.apache.org/snapshots/modperl-site/. This new site is a result of a collaborative effort of the mod_perl community. Thank you all! Without you the new site won't be as good as it is now. Special acknowledgements go to the following folks: Allan Juul Bill Moseley Jonathan M. Hollin Per Einar Ellefsen Thomas Klausner The new mod_perl site's goal wasn't only to create a nice design, but mainly to improve its documentation organization and navigation aspects, because of the ever-growing amount of documentation that the mod_perl community generates. One of the important new features is that any documentation modifications are now almost instant, so you don't have to wait for the next guide's release to get the latest fixes and improvements. We also hope that the new site will bring more contributors to the documentation. You will find the mod_perl documentation under http://perl.apache.org/docs/ which is split into sections specific to mod_perl 1.0 and 2.0, and a section for general docs which apply to any mod_perl generation. Under each generation specific you will find another separation for user documents, core developers, API and OS-specific docs, which didn't fit into general docs. The new tutorials sections sports a few interesting features, which aren't strictly mod_perl but very useful to most mod_perlers. And of course we now have the feature: What's mod_perl: http://perl.apache.org/start/index.html, which is our newbie orientation procedure, which they hopefully find useful. If you would like to build the site locally, read: http://perl.apache.org/download/docs.html If you have any questions regarding the use of the new site, read: http://perl.apache.org/help/help_with_site.html For other questions see: http://perl.apache.org/help/index.html I'd like to point your attention to the 'Short Cuts' menu on the left, which I hope you will find useful. The main menu includes the 'Site Map' and of course use the force^H^H^H^H^Hsearch if you don't know where to find things. The site includes many more new features, I don't want to spoil your (hopefully pleasant) surprises. Enjoy your new site, mod_perlers, and please help to spread the word. __ 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
Re: solaris9+apache2+mod_perl2
Well I commented the little switch statement what was giving me the problems and all seems to be resolved. Josh, have you tried with the latest cvs as I've suggested, it seems like you didn't. [...] Stas Bekman wrote: Josh Bernstein wrote: Hey All, I'm getting this error when I try to make mod_perl2, under solaris 9 ... Any one have any ideas? Oh and I'm running Solaris 9, with Apache 2.0.40cvs, it should also be noted that the mod_perl was pulled from CVS on July 8th. Is this just a broken build? Try again with the current cvs. ^ __ 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
Re: nice mod_perl statistics to share
Kevin Berggren wrote: Stas Bekman wrote: I've just updated the mod_perl with the latest stats and I'm glad to say that the results are nice, so you can show your bosses that they did the right choice (or should) ;) This is the netcraft.com: http://perl.apache.org/release/outstanding/stats/netcraft.html With the new perl.apache.org site, this seems to have disappeared. Any chance it has a new home? The /release/ prefix was for only for the preview stage. Simply remove this prefix segment and you get the same page on the new site. We don't want to add redirects for /release/, so people will not link to /release, it was a temporal thing after all. All the stats are here: http://perl.apache.org/outstanding/stats/ __ 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
Re: ANNOUNCE: the new perl.apache.org is alive now!
Gunther Birznieks wrote: I agree! It is great work. It looks really slick. :) Unfortunately, the mod_perl guide documentation area has lost functionality. I wanted to download the latest guide before my 23 hour flight to the USA (to read on the flight) and was dismayed to find hours before my flight that it is impossible to get a full HTML or full PDF download of the entire guide anymore... You can get a PDF of single pages (of which I don't know the reason?), but the guide itself is quite hard. eh? what do you mean? it's all there, go to: http://perl.apache.org/docs/1.0/guide/index.html click on the pdf button in the right upper corner and you get this: http://perl.apache.org/docs/1.0/guide/guide.pdf Notice though, that parts non-specific to mod_perl 1.0 has now moved to http://perl.apache.org/docs/general/index.html __ 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
Re: ANNOUNCE: the new perl.apache.org is alive now!
Nate Campi wrote: I hate to be a party pooper, but I single handedly brute upgraded www.wired.com from Vignette Storyserver 5.0 to V/6 this month - it's not mod_perl. The new page is incorrect. I do the ServerTokens Min thing to hide what modules we run. If the authors of the page want to ask me about different mod_perl stuff we do at Wired/Lycos feel free to contact me off list. We have some cool stuff. sure, please send the updates and the page will be adjusted. Nobody expects this page to stay the same. We did remove many sites that used to be there, either because they couldn't be reached or because they didn't seem to be running mod_perl. -- __ 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
Re: ANNOUNCE: the new perl.apache.org is alive now!
fist, let me say: Great Job! the new site looks fantastic, a *vast* and long-awaited improvement. ;) i still notice, however that the *content* of the Sites Running mod_perl page doesn't seem to have been updated. about 6 months ago, i sent notices about two sites that we (Vanguard Media) had launched to the email address that used to be on that page, but they were never included. is this being actively maintained now? Very actively. should i re-send now to the docs-dev mailing list? Yes, please. While you've raised this issue, I'd like to remind everybody that we want your (long) success stories for: http://perl.apache.org/outstanding/success_stories/index.html or simply (short) reports of cool sites running mod_perl for: http://perl.apache.org/outstanding/sites.html __ 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
