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 have
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
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 perl-5.8.1
>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
[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 14:07:02
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 and
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
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_pe
;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 the example code from the site and failed stil.Error:Undefined subroutine &main::CISCHeader cal
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
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:
http://perl.apache.org/docs/2.0/user/porting/compat.html#C_Apache__Re
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/Per
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 doe
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 appr
> 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.
Well, making a given module aware of who imported it (whether it's a
module or a Registry scr
ry (depending on which 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
> How can you tell? Can you post some sample code? You might be doing
> something that doesn't work when reloaded, like closures.
Well, here's the code I'm trying to run. (I have verified that
Param('script_root') returns D:/htdocs, as expected). The initial code
was this:
<
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 );
a
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 wrot
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.
> http://perl.apache.org/docs/2.0/api/Apache/Reload.html#Problems_with_Scripts_Running_with_Registry_
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.
http://perl.apache.org/docs/2.0/api/Apache/Reload.html#Problems_with_Scripts_Runni
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 tryin
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
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 reloaded one of those since the last request and
if so, reload the script itsel
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 probl
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
> 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 actu
f you restart the
server, does 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
read
http://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
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 );
I think that's the problem. You are creating an alias to the sub
Perrin,
> > use Hybride::Projects qw(getImage );
>
> 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 module, not t
much typing. 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
Shannon Eric Peevey wrote:
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 documen
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
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 re
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 p
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
ause_04about#conventions
I've added a note about 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);
[...]
Tha
Apache::Constants->import('HTTP_UNAUTHORIZED','OK');
}
}
# 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
x27;,
"Failed commands:", "-" x 16,
map { join("\n\t", $_, @{ $report{failed}{$_}||[] }),"\n"} @failed;
}
}
__DATA__
# need to test all these combinations
### mp2 DSO ###
make clean && /usr/bin/env CCFLAGS="-g"
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 upl
rt Apache::RequestRec;
require Apache::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
questRec;
require Apache::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
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 modpe
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 insta
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
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...
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!
gt;
Sent: Saturday, June 07, 2003 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? I
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
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 always see 2) will the module code exist in all
processes?
mma
x27;t
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
;[EMAIL PROTECTED]>
To: "modperl" <[EMAIL PROTECTED]>
Sent: 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
um
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
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 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
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
(http://perldoc.com/perl5.8.0/pod/perlfaq3.html#How-can-I-hide-the-source-for-my-Pe
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
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:
>>
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
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
eagle
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 wha
per'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::AuthCoo
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
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 th
:compat my 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&#x
:compat my 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*
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:
ht
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::comp
use 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::Reg
y one directory if they are
actually longer than that) from site1.pl and site2.pl, then call the
perl modules like:
site1.pl:
...
use lib1::Site;
...
and
site2.pl:
...
use lib2::Site;
...
You will also have to change the Site.pm files to be:
package lib1::Site;
and
package lib2::Site;
In gen
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
requ
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 (as
it's supposed to be more forgiving that
Apa
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::Pe
e to share 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 h
* 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, inst
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&#
> 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 then this
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 ;)
_
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
why it
doesn't 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
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 DoubleTe
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 s
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 {
$s
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
ECTED]]
> >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?
run the failed tests
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 Probl
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 --
OS: Slackware Linux 2.2.16
Perl:
ppened to
me :)
Aloha => Beau.
-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 mod
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:
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:
/usr/local/lib/perl5/5.8.0/i686-linux-thread-multi
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/MyC
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:
> /usr/local/li
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
/usr/local/li
tten using mod_perl2 and apache::ASP.
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 ?
Also note the nat
pache::ASP.
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
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
The changes are documented here:
http://perl.apache.org/docs/2.0/user/compat/compat.html
I haven't put it into the developer's guide, but the user's guide.
Because the user's guide is for all people who write mod_perl code. The
developer's guide is for those who tinker with the core. I'll put an
Clare, Bruce W wrote:
I'm attempting to run Scoop 0.9 (scoop.kuro5hin.org) under Apache2/mod_perl
2.0 running on Windows 2000, but the application was written for Apache/mp
1.x, so it uses Apache::SIG (and possibly other) modules that are no longer
in mod_perl.
The mod_perl deve
I'm attempting to run Scoop 0.9 (scoop.kuro5hin.org) under Apache2/mod_perl
2.0 running on Windows 2000, but the application was written for Apache/mp
1.x, so it uses Apache::SIG (and possibly other) modules that are no longer
in mod_perl.
The mod_perl developer documentation for porting f
1 - 100 of 549 matches
Mail list logo
