e-mol Development Team wrote:
diff -u 5.6.1.txt 5.8.0.txt
The two builds are quite different, I have pointed out below at least a few
major differences.
[EMAIL PROTECTED] src]# diff -u 5.6.1.txt 5.8.0.txt
--- 5.6.1.txt 2003-09-03 14:07:02.0 -0400
+++ 5.8.0.txt 2003-09-03
I think next I may try and see if perl 5.6.1 can be build on the 5.8.0 system
and see what this leads to.
I wonder if it could be the newer gcc or glibc?
This is quite possible, since the sharing mostly comes from your OS, not
specificly from Perl.
You may also want to try the latest
After some thinking time I decided to compile perl 5.8.0 on the older system
that did have 5.6.1. It would seem it has nothing to do with perl 5.8.0. I
compiled perl 5.8.0 on the older system and preloading worked just like it should.
Now I know that it does not have anything to do with perl or
e-mol Development Team wrote:
After some thinking time I decided to compile perl 5.8.0 on the older system
that did have 5.6.1. It would seem it has nothing to do with perl 5.8.0. I
compiled perl 5.8.0 on the older system and preloading worked just like it should.
Now I know that it does not
I have two servers running Apache 1.3.27 and mod_perl 1.27 both severs are
running identical httpd.conf and startup.pl configurations. One is running
Perl 5.8.0 the other is running 5.6.1. When I do the preloading of modules on
the 5.6.1 system all seems well and shared memory goes up while
e-mol Development Team wrote:
I have two servers running Apache 1.3.27 and mod_perl 1.27 both severs are
running identical httpd.conf and startup.pl configurations. One is running
Perl 5.8.0 the other is running 5.6.1. When I do the preloading of modules on
the 5.6.1 system all seems well
[make sure to keep the replies on the list. Thank you!]
e-mol Development Team wrote:
diff -u 5.6.1.txt 5.8.0.txt
The two builds are quite different, I have pointed out below at least a few
major differences.
[EMAIL PROTECTED] src]# diff -u 5.6.1.txt 5.8.0.txt
--- 5.6.1.txt 2003-09-03
I in the process of switching my scripts over to Mod Perl.
I decide since Mod Perl doesn't like Sub routine in the the main program I'd
export make Modules out of the more come ones. Simple process I thought.
However no mater what I do I get an error. I tried making a simple one using
in the the main program I'd export make Modules out of the more come ones. Simple process I thought. However no mater what I do I get an error. I tried making a simple one using the example code from the site and failed stil.Error:Undefined subroutine main::CISCHeader called at /var/www/perl
On Thu, 2003-08-28 at 16:09, Tim Edwards wrote:
I in the process of switching my scripts over to Mod Perl.
I decide since Mod Perl doesn't like Sub routine in the the main program I'd
export make Modules out of the more come ones.
Just to be clear, mod_perl has no problem with subroutines
All,
I'm having problems loading .PM modules (apache2, mod_perl2) that are in the
root directory and am not quite sure where to begin (Been here
http://perl.apache.org/docs/general/perl_reference/perl_reference.html#The__INC_hash
but no success).
I am converting code from an IIS/Perl CGI
On Wed, 2003-08-27 at 14:48, js wrote:
My question is, why isn't Apache2/Mod_perl finding the library to load, if
the PM file is in the same directory as the perl-script?
This is a mod_perl 2 issue, which is documented here:
. There has to be another
solution, isn't there?
I'm asking you to try it and see if it works.
A possible solution if that is the problem is to make all the modules
that import it reload as well. You can do that with a touch file.
- Perrin
Perrin,
use Hybride::Projects qw(getImage other imports);
I think that's the problem. You are creating an alias to the sub
here,
and when it gets reloaded the alias is still pointing to an old
version.
Actually, I just saw that the sub is exported in the EXPORT section of
the Projects
On Thu, 2003-08-14 at 13:41, Jean-Sebastien Guay wrote:
Is there anything unusual about the
way you call this sub (AUTOLOAD, function ref, etc.)?
Not at all. It is imported with
use Hybride::Projects qw(getImage other imports);
I think that's the problem. You are creating an alias to
://perl.apache.org/docs/2.0/api/Apache/Reload.html#Problems_With_Reloading_Modules_Which_Do_Not_Declare_Their_Package_Name
but all my modules declare their package names. I have also checked,
using the perl-status Apache module, and all my modules are in %INC with
absolute paths, not relative ones.
I have also
it pick up the change? Is there anything unusual about the
way you call this sub (AUTOLOAD, function ref, etc.)?
Reloading modules is not foolproof. Perl doesn't actually support it,
so things like Apache::Reload fake it by removing the module from %INC
and making it get compiled again
I'm asking you to try it and see if it works.
Ok, I tried it and it works.
A possible solution if that is the problem is to make all the modules
that import it reload as well. You can do that with a touch file.
The file that imports it is not a module, it's the actual script. No
other file
On Thu, 2003-08-14 at 14:29, Jean-Sebastien Guay wrote:
I'm asking you to try it and see if it works.
Ok, I tried it and it works.
I guess we need to add this to the docs: Apache::Reload will have
problems if you import subs from a module you are trying to reload.
The file that imports it
Perrin Harkins wrote:
On Thu, 2003-08-14 at 14:29, Jean-Sebastien Guay wrote:
I'm asking you to try it and see if it works.
Ok, I tried it and it works.
I guess we need to add this to the docs: Apache::Reload will have
problems if you import subs from a module you are trying to reload.
The
be implemented to integrate it
better with Apache::Reload? Something along the lines of keeping track
of which modules a certain script use()s, and at request time, checking
if Apache::Reload has reloaded one of those since the last request and
if so, reload the script itself? That would remove
On Thu, 2003-08-14 at 15:01, Jean-Sebastien Guay wrote:
Could something in Apache::Registry be implemented to integrate it
better with Apache::Reload? Something along the lines of keeping track
of which modules a certain script use()s, and at request time, checking
if Apache::Reload has
Hi Perrin,
I don't see anything wrong with that chunk of code. If you restart
the
server, does it pick up the change?
Yes.
Is there anything unusual about the
way you call this sub (AUTOLOAD, function ref, etc.)?
Not at all. It is imported with
use Hybride::Projects qw(getImage other
you are using) and the code for
Apache::Reload. These are all pure perl modules.
However, there will always be things that Apache::Reload doesn't
handle. For example, you might import functions from one module into
another module, as opposed to importing into a Registry script. My
advice
Perrin Harkins wrote:
If you're interested
in working on it, we could discuss possible approaches on the list and
review your patch.
In a week or so I'll have a bit more free time, and I might try
implementing it. I'll start by reading up on mod_perl internals... :-)
I'd suggest a different
On Thu, 2003-08-14 at 15:10, Stas Bekman wrote:
OK, I've written a proper entry for the man page, Jean-Sebastien can you
please verify that it all works, as I wrote it without testing. Thanks.
Stas Bekman wrote:
OK, I've written a proper entry for the man page, Jean-Sebastien can
you
please verify that it all works, as I wrote it without testing.
Great work Stas, you're quick :-) Other than the little mistake Perrin
pointed out, the suggested change works.
Perrin Harkins wrote:
Perrin Harkins wrote:
On Thu, 2003-08-14 at 15:10, Stas Bekman wrote:
OK, I've written a proper entry for the man page, Jean-Sebastien can you
please verify that it all works, as I wrote it without testing. Thanks.
Stas Bekman wrote:
Perrin Harkins wrote:
On Thu, 2003-08-14 at 14:29, Jean-Sebastien Guay wrote:
I'm asking you to try it and see if it works.
Ok, I tried it and it works.
I guess we need to add this to the docs: Apache::Reload will have
problems if you import subs from a module you are
On Thu, 2003-08-14 at 11:24, Jean-Sebastien Guay wrote:
I'm using Apache::Reload, and I can see that my modified module is
getting reloaded (with ReloadDebug On), but the program still uses the
old code.
How can you tell? Can you post some sample code? You might be doing
something that
Stas Bekman wrote:
Shannon Eric Peevey wrote:
Hi!
Is there a list of CPAN modules that have already been ported to work
with mod_perl2?
Not at the moment, but it's a great idea. Where should we add it? I
suppose that this should be a short-life document and eventually it
will be removed
to support this module. (BTW, I found the same offending
code in Apache::AuthzLDAP.)
I have compared the functionality of these two module to
Apache::AuthNetLDAP and Apache::AuthzNetLDAP, and found that the latter
two modules contain all of the functionality of the Bodnar/Gilmore
modules
Hi!
Is there a list of CPAN modules that have already been ported to work
with mod_perl2? If so, can I add my two modules to it?
(Apache::AuthNetLDAP and Apache::AuthzNetLDAP).
thanks,
speeves
cws
Shannon Eric Peevey wrote:
Hi!
Is there a list of CPAN modules that have already been ported to work
with mod_perl2?
Not at the moment, but it's a great idea. Where should we add it? I suppose
that this should be a short-life document and eventually it will be removed.
So we can put
');
}
}
# Preloaded methods go here.
#handles Apache requests
sub handler {
...
}
Thanks again for all of your help! If you know of any modules that need
porting in a like manner, feel free to contact me and I would be happy
to help out.
speeves
cws
this to the porting docs.
package Apache::AuthNetLDAP;
[...]
$VERSION = '0.21';
# setting the constants to help identify which version of mod_perl
# is installed
use constant MP2 = ($mod_perl::VERSION = 1.99);
[...]
Thanks again for all of your help! If you know of any modules that need
porting
of modules depending
on the existence of either modperl1 or 2... use dies and require is
not importing the symbols correctly at runtime... My bad for not
completely understanding how to use require. (Am trying to work this
out as we speak.) Thanks again!
On Mon, 2003-06-09 at 12:12, Shannon Eric Peevey wrote:
PS Am having problems with the compile time loading of modules depending
on the existence of either modperl1 or 2... use dies and require is
not importing the symbols correctly at runtime...
If you read the docs for use (perldoc -f use
Perrin Harkins wrote:
On Mon, 2003-06-09 at 12:12, Shannon Eric Peevey wrote:
PS Am having problems with the compile time loading of modules depending
on the existence of either modperl1 or 2... use dies and require is
not importing the symbols correctly at runtime...
If you read
On Mon, 2003-06-09 at 13:57, Shannon Eric Peevey wrote:
Yeah, I've been messing with that, but it seems to me that I need
something similar to a preprocessor directive, where I can load the
appropriate use MODULE lines into the module bases upon which version
of modperl they have installed.
Perrin Harkins wrote:
On Mon, 2003-06-09 at 13:57, Shannon Eric Peevey wrote:
Yeah, I've been messing with that, but it seems to me that I need
something similar to a preprocessor directive, where I can load the
appropriate use MODULE lines into the module bases upon which version
of
Apache::RequestUtil;
}
You don't need to import anything, since none of these modules import
anything. Just require will do.
Here is the code that is coughing up the error:
102 #Look for user based on UIDAttr
103
104my $attrs = ['dn'];
105 $mesg = $ldap-search(
106
::RequestUtil;
import Apache::RequestUtil;
}
You don't need to import anything, since none of these modules import
anything. Just require will do.
Here is the code that is coughing up the error:
102 #Look for user based on UIDAttr
103
104my $attrs = ['dn'];
105 $mesg = $ldap
speeves wrote:
Stas Bekman wrote:
[...]
http://search.cpan.org/src/STAS/Apache-Peek-1.01/t/response/TestApachePeek/basic.pm
That did it!!! Thank you so much for your patience and help with all
that I am working on here. After I test these changes on modperl 1
tomorrow, I should be able to
/modules/mod_perl-5.6.1.so -port select MOD_PERL=2
make make test
make clean /usr/bin/env CCFLAGS=-g perl-5.8.0 Makefile.PL -httpd
/home/stas/httpd/prefork/bin/httpd -libmodperl mod_perl-5.8.0.so -port select
MOD_PERL=2 make make test
make clean /usr/bin/env CCFLAGS=-g perl-5.8.0-ithread
1:21 AM
Subject: Apache modules and mod_perl threads in same process?
For Apache 2.0.46 / mod_perl 1.99.10-dev:
If I have an Apache module configured in httpd.conf, will the module code
be
executing in the same process as the mod_perl code? If there are multiple
Apache processes (on W2K I
For Apache 2.0.46 / mod_perl 1.99.10-dev:
If I have an Apache module configured in httpd.conf, will the module code be
executing in the same process as the mod_perl code? If there are multiple
Apache processes (on W2K I always see 2) will the module code exist in all
processes?
mma
Marc M. Adkins wrote:
For Apache 2.0.46 / mod_perl 1.99.10-dev:
If I have an Apache module configured in httpd.conf, will the module code be
executing in the same process as the mod_perl code? If there are multiple
Apache processes (on W2K I always see 2) will the module code exist in all
i have a collection of perl modules (running under the mod_perl umbrella)
and would like to distribute the application to several different sources
(clients with open internet web servers). but i dont want to send it out
without at least making it somewhat difficult for some hacker to just simply
hi
( 03.05.29 14:25 -0700 ) Kirk Rogers:
but i dont want to send it out without at least making it somewhat
difficult for some hacker to just simply steal it and load it
somewhere else without my consent.
why not? have you ever read the GNU manifesto?
http://www.gnu.org/gnu/manifesto.html
why the scarcasm?
-Original Message-
From: John Saylor [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 29, 2003 2:34 PM
To: [EMAIL PROTECTED]
Cc: modperl
Subject: Re: how to secure perl modules?
hi
( 03.05.29 14:25 -0700 ) Kirk Rogers:
but i dont want to send it out without at least
have a collection of perl modules (running under the mod_perl umbrella)
and would like to distribute the application to several different sources
(clients with open internet web servers). but i dont want to send it out
without at least making it somewhat difficult for some hacker to just simply
steal
On Thu, 2003-05-29 at 17:41, Kirk Rogers wrote:
why the scarcasm?
You asked a very loaded question that is guaranteed to get you a lot
angry responses on most Perl mailing lists. Hiding your source code is
a FAQ
Hi there,
On Thu, 29 May 2003, Kirk Rogers wrote:
i have a collection of perl modules ... i dont want to send it out
without at least making it somewhat difficult for some hacker to just simply
steal it and load it somewhere else without my consent.
This is getting to be an old chestnut, I
i have a collection of perl modules (running under the mod_perl umbrella)
and would like to distribute the application to several different sources
(clients with open internet web servers). but i dont want to send it out
without at least making it somewhat difficult for some hacker to just simply
Hi!
On Thu, May 29, 2003 at 10:27:54AM -0700, iCap wrote:
i have a collection of perl modules (running under the mod_perl umbrella)
and would like to distribute the application to several different sources
(clients with open internet web servers). but i dont want to send it out
without
: Friday, May 30, 2003 8:58 AM
Subject: Re: how to secure perl modules?
Hi!
On Thu, May 29, 2003 at 10:27:54AM -0700, iCap wrote:
i have a collection of perl modules (running under the mod_perl
umbrella)
and would like to distribute the application to several different
sources
(clients
really make sense, but the errors went away when I stopped using Switch.
Wes
Perrin Harkins [EMAIL PROTECTED] on 05/29/2003 05:56:05 PM
To:[EMAIL PROTECTED]
cc:John Saylor [EMAIL PROTECTED], modperl
[EMAIL PROTECTED]
Subject:RE: how to secure perl modules?
On Thu, 2003-05
cookbook) seems to be centered around mp1 and libapreq.
My newbie question is then, what would the best way to implement an
authorization scheme in mp2 and are there any helpful modules ported? I am thinking of something pretty standard, like what Apache::AuthCookie provides with a DB backend verifying
book, developer's cookbook) seems to be centered around mp1 and libapreq.
My newbie question is then, what would the best way to implement an
authorization scheme in mp2 and are there any helpful modules
ported? I am thinking of something pretty standard, like what
Apache::AuthCookie provides
dorian wrote:
i know Apache::Module can get at all the installed modules and their
directives, and even the spec of those directives, but what about the
actual values of those directives? i notice Apache::Module is old, but
i don't see anything else out there that looks like it will come close
i know Apache::Module can get at all the installed modules and their
directives, and even the spec of those directives, but what about the
actual values of those directives? i notice Apache::Module is old, but
i don't see anything else out there that looks like it will come close
to doing the job
Since the questions of porting to mp 2.0 are on raise, and there is some
confusion regarding use of Apache::compat. I've done a massive porting docs
update:
Please review the following if you are involved in porting, and let me know if
I've missed something or if something is still unclear:
code is
forced to use the potentially slower method. Which is quite bad.
Some users may choose to keep using Apache::compat in production and it
may perform just fine. Other users will choose not to use that module.
It should be users' choice.
Therefore CPAN modules should *not* preload Apache
method. Which is quite bad.
Some users may choose to keep using Apache::compat in production and it
may perform just fine. Other users will choose not to use that module.
It should be users' choice.
Therefore CPAN modules should *not* preload Apache::compat, but use the
mp2 API or copy
to use
the potentially slower method. Which is quite bad.
Some users may choose to keep using Apache::compat in production and it may
perform just fine. Other users will choose not to use that module. It should
be users' choice.
Therefore CPAN modules should *not* preload Apache::compat, but use
stas2003/02/07 20:36:35
Modified:src/modules/perl modperl_filter.c
Log:
use a faster way to check whether we need to use a truncated buffer,
strlen on an 8k buffer is not cool.
Revision ChangesPath
1.52 +2 -1 modperl-2.0/src/modules/perl/modperl_filter.c
stas2003/02/06 18:30:53
Modified:src/modules/perl modperl_filter.c
Log:
we have no choice but to truncate wb-outbuf to the size of 'len'. All
kind of weird problems pop-up when the previous request was proper and the
current request has messed up with headers, because
having problems due to the fact
that each web site refers to their own copy of my
module called Site.pm (to contain functions, global
variables etc). The problem is that the my scripts get
confused and use variables from the other site's
modules randomly.
The following example is using Apache::PerlRun
copy of my
module called Site.pm (to contain functions, global
variables etc). The problem is that the my scripts get
confused and use variables from the other site's
modules randomly.
The following example is using Apache::PerlRun (as
it's supposed to be more forgiving that
Apache::Register). I am
David Dick wrote:
this is probably evil, and apologies to those who have seen suspiciously
familiar code before, but is this possible?
package MyPrefix::Apache::Registry;
use strict;
BEGIN {
use Apache::Registry();
}
sub handler {
delete $INC{'Site.pm'};
# mess with @INC
variables from the other site's
modules randomly.
[...]
If your module which has an indentical name but different contents and it
never calls functions and accesses variables by prefixing the module name
(e.g. Site::foo and $Site::bar), i.e. everything is exported, you could hack
Apache::Registry
stas2003/02/02 22:40:33
Modified:.Changes
src/modules/perl modperl_config.c
Added: t/hooks cleanup.t
t/hooks/TestHooks cleanup.pm
Log:
PerlCleanupHandler implementation + tests
Revision ChangesPath
1.119 +8 -1
stas2003/01/28 17:04:34
Modified:.Changes
src/modules/perl modperl_callback.c
Added: t/hooks stacked_handlers.t
t/hooks/TestHooks stacked_handlers.pm
Log:
Stacked handlers chain execution is now aborted when a handler returns
these
modules with the public.
I know there are allready some modules that provides ways to do simliar
things, but (hopefully) my modules work a bit different. Basically I
would like to know if there is some interest for these modules. It would
be too much to write all features down here, but I
stas2003/01/11 18:15:59
Modified:xs/tables/current/ModPerl FunctionTable.pm
src/modules/perl modperl_filter.h mod_perl.c
modperl_filter.c
Log:
improve the code readability by s/filter_register/filter_add/g because the
filters are actually
* Perrin Harkins [EMAIL PROTECTED] [2002-12-30 19:07]:
Explanations and other suggested approaches to handling this problem
will be most welcome.
My suggestion in the past has been to PerlRequire a startup.pl that
does a use on your modules, instead of pulling them in with
PerlModule.
I
Hi All,
I'm developing a new module for mod_perl 1.27, and I'm noticing that
some code is getting executed twice when the Apache server starts up.
Here's a simple example. Say I have two modules in separate files:
package DoubleTest;
use strict;
my $seen;
sub test_seen {
$seen++;
warn
David Wheeler wrote:
Hi All,
I'm developing a new module for mod_perl 1.27, and I'm noticing that
some code is getting executed twice when the Apache server starts up.
It was supposed to be fixed in 1.25_01:
=item 1.25_01 - July 6, 2001
...
fix double-loading bug of Perl{Require,Module}s at
that several people have reported that
they still had this problem since 1.26 was released.
I have a better workaround, now. I found that I could make the problem
go away by reversing the order in which the modules are loaded in
httpd.conf:
PerlModule TestSeen
PerlModule DoubleTest
Not exactly sure
work for you. I know that several people have reported that
they still had this problem since 1.26 was released.
I have a better workaround, now. I found that I could make the problem
go away by reversing the order in which the modules are loaded in
httpd.conf:
PerlModule TestSeen
PerlModule
Is anyone getting duplicates (i.e. 2 of the same email) of this thread? It just
started happening today.
Brian
-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 30, 2002 5:06 PM
To: David Wheeler
Cc: [EMAIL PROTECTED]
Subject: Re: Modules Executed
Hann, Brian wrote:
Is anyone getting duplicates (i.e. 2 of the same email) of this thread? It just started happening today.
I can't tell, since I never receive dups because of the procmail rule:
:0 Wh: msgid.lock
| formail -D 8192 saved/msgid.cache
hint, hint ;)
Explanations and other suggested approaches to handling this problem
will be most welcome.
My suggestion in the past has been to PerlRequire a startup.pl that does a
use on your modules, instead of pulling them in with PerlModule.
Of course, if you turn PerlFreshRestart
On Monday, December 30, 2002, at 04:09 PM, Perrin Harkins wrote:
My suggestion in the past has been to PerlRequire a startup.pl that
does a
use on your modules, instead of pulling them in with PerlModule.
Of course, if you turn PerlFreshRestart on then this is the intended
behavior.
That's
stas2002/12/26 17:28:26
Modified:src/modules/perl apache_inc.h
Log:
s/\cM//
Revision ChangesPath
1.7 +1 -1 modperl/src/modules/perl/apache_inc.h
Index: apache_inc.h
===
RCS file
12:00 PM
To: [EMAIL PROTECTED]
Subject: Install Problem: make test: modules/src.t
When I 'make test' I'm getting failures relating to modules/src.t
Can anyone help?
-- PLATFORM --
OS: Slackware Linux 2.2.16
Perl: 5.6.0
mod_perl
Mark Hawkes wrote:
When I 'make test' I'm getting failures relating to modules/src.t
[...]
$ make test TEST_VERBOSE=1
--snip--
dir=../src
ok 2
main=
not ok 3
module_magic_number = 0
not ok 4
httpd_version =
not ok 5
-I../src -I../src/modules/perl
ok 6
FAILED tests 3-5
Failed 3/6 tests
When I 'make test' I'm getting failures relating to modules/src.t
Can anyone help?
-- PLATFORM --
OS: Slackware Linux 2.2.16
Perl: 5.6.0
mod_perl: 1.27
Apache: Apache/1.3.12 (Unix) PHP/4.2.3
Apache root:/var/lib/apache
.
-Original Message-
From: Mark Hawkes [mailto:[EMAIL PROTECTED]]
Sent: Saturday, December 21, 2002 12:00 PM
To: [EMAIL PROTECTED]
Subject: Install Problem: make test: modules/src.t
When I 'make test' I'm getting failures relating to modules/src.t
Can anyone help?
-- PLATFORM
]
Subject: Install Problem: make test: modules/src.t
When I 'make test' I'm getting failures relating to modules/src.t
Can anyone help?
-- PLATFORM --
OS: Slackware Linux 2.2.16
Perl: 5.6.0
mod_perl: 1.27
Apache: Apache/1.3.12
alone in -v mode? For mod_perl 2 you can say: t/TEST -v testname.
Sorry I'm not much help...
Aloha = Beau.
-Original Message-
From: Mark Hawkes [mailto:[EMAIL PROTECTED]]
Sent: Saturday, December 21, 2002 2:19 PM
To: [EMAIL PROTECTED]
Subject: RE: Install Problem: make test: modules/src.t
Hi,
I am trying to configure a working apache2/modperl2 setup, unfortunately
I can not seemt to get a critical module Apache::Cookie to install, I
keep getting this error.
Can't locate Apache/MyConfig.pm in @INC (@INC contains:
/usr/local/lib/perl5/5.8.0/i686-linux-thread-multi
On Thu, 19 Dec 2002, b. ash wrote:
Hi,
I am trying to configure a working apache2/modperl2 setup, unfortunately
I can not seemt to get a critical module Apache::Cookie to install, I
keep getting this error.
Can't locate Apache/MyConfig.pm in @INC (@INC contains:
To: [EMAIL PROTECTED]
Subject: modperl 2.0 problems with Apache::Cookie and related modules.
Hi,
I am trying to configure a working apache2/modperl2 setup, unfortunately
I can not seemt to get a critical module Apache::Cookie to install, I
keep getting this error.
Can't locate Apache/MyConfig.pm
b. ash wrote:
Hi,
I am trying to configure a working apache2/modperl2 setup, unfortunately
I can not seemt to get a critical module Apache::Cookie to install, I
keep getting this error.
Can't locate Apache/MyConfig.pm in @INC (@INC contains:
the changes appear to all children.
Is there a way of avoiding this - maybe with an apache directive - so that
all modules are re-read by all children without a restart ?
Thanks
Richard
.
When I change the code in a perl module, I have to restart apache to make
the changes appear to all children.
Is there a way of avoiding this - maybe with an apache directive - so that
all modules are re-read by all children without a restart ?
Apache::Reload ships standard with mod_perl 2.0
stas2002/12/12 02:12:41
Modified:src/modules/perl modperl_module.c
Log:
handle correct perlmodules (directives) with vhosts:
- handle gracefully cases when things are undef/NULL
- handle the case when scfg==NULL, by stealing the base_servers's config
Revision Changes
stas2002/12/12 03:45:26
Modified:src/modules/perl modperl_cmd.c
Log:
handle correctly the switches, when the server starts early. e.g., a
sample config at the base server's level:
PerlLoadModule Foo
PerlSwitches -Iwhatever
When PerlLoadModule returns, mod_perl
1 - 100 of 748 matches
Mail list logo
