On 03/25/2015 09:44 AM, Jan Kaluža wrote:
On 03/25/2015 06:52 AM, Fred Moyer wrote:
Here's my latest results from testing 2.0.9-dev with httpd 2.4.12 on
OS X 10.10.2
Configured httpd with:
./configure --prefix=$HOME/dev/httpd_24 --with-included_apr
--with-mpm=prefork
By default http
On 03/25/2015 06:52 AM, Fred Moyer wrote:
Here's my latest results from testing 2.0.9-dev with httpd 2.4.12 on
OS X 10.10.2
Configured httpd with:
./configure --prefix=$HOME/dev/httpd_24 --with-included_apr --with-mpm=prefork
By default httpd 2.4 builds with the event MPM I found.
I
Here's my latest results from testing 2.0.9-dev with httpd 2.4.12 on
OS X 10.10.2
Configured httpd with:
./configure --prefix=$HOME/dev/httpd_24 --with-included_apr --with-mpm=prefork
By default httpd 2.4 builds with the event MPM I found.
I built mod_perl with:
perl Makefile.PL MP_NO_TH
Hello list.
I'm trying to use Apache::Test for testing a web client
(fusioninventory-agent, if that matters), not a server component.
Basically, I have to test the agent can contact a web server with http
or https, directly or through a proxy, check ssl cert, etc...
So far, I figured o
.t
t/00-load.# bootstrapping mp1 only
mod_perl not present, cannot bootstrap mp1 at
/home/adam/Apache-Bootstrap-0.07-rc1/blib/lib/Apache/Bootstrap.pm line 96.
# bootstrapping mp2 only
t/00-load.ok 3/11# Testing Apache::Bootstrap 0.07-rc1, Perl
5.008006, /usr/bin/perl5.8.6
t/00-lo
-b t
t/00-load.ok 1/11# bootstrapping mp1 only
# bootstrapping mp2 only
mod_perl2 not present, cannot bootstrap mp2 at
blib/lib/Apache/Bootstrap.pm line 121.
# Testing Apache::Bootstrap 0.07-rc1, Perl 5.008008, /opt/local/bin/perl
t/00-load.ok
7/11 skipped: various reasons
I'd love it if you could take this rc for a spin and report back. Passing
all tests on OS X 10.5, 5.8.8, 2.2.6
and Centos 5.2, 5.8.9, 2.2.8.
I resolved some issues while implementing this version for Apache::Dispatch.
Changes since 0.06
- fix syntax error in params validation in new (mp2 pa
--
Philip M. Gollucci ([EMAIL PROTECTED]) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/EC88A0BF 0DE5 C55C 6BF3 B235 2DAB B89E 1324 9
On Thu, 31 Aug 2006, Philip M. Gollucci wrote:
Fred Moyer wrote:
[EMAIL PROTECTED] ~/dev/src/Apache-SizeLimit $ perl Makefile.PL
You don't seem to have mod_perl 1.0 installed at Makefile.PL line 110.
Here's a really dumb question -- Do you have mod_perl 1.0 installed AND the
PERL GLUE in your
Fred Moyer wrote:
> [EMAIL PROTECTED] ~/dev/src/Apache-SizeLimit $ perl Makefile.PL
> You don't seem to have mod_perl 1.0 installed at Makefile.PL line 110.
Here's a really dumb question -- Do you have mod_perl 1.0 installed AND the
PERL GLUE in your PERL5LIB path
(specifically mod_perl.pm)?
Even
Hi,
I wasn't able to get Apache::SizeLimit trunk to build. Any suggestions
appreciated.
[EMAIL PROTECTED] ~/dev/src/Apache-SizeLimit $ perl Makefile.PL
You don't seem to have mod_perl 1.0 installed at Makefile.PL line 110.
[EMAIL PROTECTED] ~/dev/src/Apache-SizeLimit $ which httpd
which: no h
On Sat, 17 Dec 2005 22:57:15 -0500
Geoffrey Young <[EMAIL PROTECTED]> wrote:
> Frank Wiles wrote:
> > Attached is a patch that moves all have_min_apache_version('2.1')
> > s to have_min_apache_version('2.2')s.
>
> I thought about that, but I don't think we need to do it - the 2.1
> assertion i
Frank Wiles wrote:
> Attached is a patch that moves all have_min_apache_version('2.1')s to
> have_min_apache_version('2.2')s.
I thought about that, but I don't think we need to do it - the 2.1 assertion
is still valid, and it's somewhat nice to have knowledge of when things
changed for hist
Attached is a patch that moves all have_min_apache_version('2.1')s to
have_min_apache_version('2.2')s.
-
Frank Wiles <[EMAIL PROTECTED]>
http://www.wiles.org
-
apache2.2-test.patch
Description: Binary data
---
Jim Martinez wrote:
On May 9 Stas Bekman wrote:
So the next stage is probably to move:
svn move src/docs/general/testing/testing.pod \
src/projects/Apache-Test/user/perl/guide.pod
is that good? I suppose it'd be a good idea to split it in smaller docs?
I like it. Thanks.
The te
Steve Hay wrote:
Stas Bekman wrote:
Stas Bekman wrote:
Also this core files scan, is it relevant at all to WIN32? When you
get a coredump, do you get a core file?
No, there's no core files on Win32. "Dr Watson's log files" would
be the closest thing I suppose, but you don't really want to
Stas Bekman wrote:
Stas Bekman wrote:
Also this core files scan, is it relevant at all to WIN32? When you
get a coredump, do you get a core file?
No, there's no core files on Win32. "Dr Watson's log files" would
be the closest thing I suppose, but you don't really want to go
there. Perh
Stas Bekman wrote:
Also this core files scan, is it relevant at all to WIN32? When you
get a coredump, do you get a core file?
No, there's no core files on Win32. "Dr Watson's log files" would be
the closest thing I suppose, but you don't really want to go there.
Perhaps if we skip the cor
I've committed the latest version plus the cleanup suggested in the last email
of yours.
This only leaves the problem of it occasionally picking up the "wrong"
PID file:-
Anyway, I thought I'd add some code in try_exit_opts() to remove the
PID file, but it still didn't always work. I added mo
Stas Bekman wrote:
Steve Hay wrote:
Perhaps just slip in "$old_pid = 0;" at the end of the "if (WIN32) {
... }" section to fix this?
Sure, the adjusted patch below does that.
Cool.
However, there is still a bigger problem with this new patch. You've
removed the little hack that I'd left
Steve Hay wrote:
[...]
You did break one thing for sure: After your patch, the beginning of
TestServer::start() looks like this:
=
my $self = shift;
my $old_pid = -1;
if (WIN32) {
[...]
if (-f $self->pid_file) {
error "Removing old PID file -- " .
Stas Bekman wrote:
Steve Hay wrote:
Stas Bekman wrote:
Steve Hay wrote:
[...]
I suppose we could have Apache::TestSmoke::run_test() look for the
"server is not running" message, and have it just warn about it
rather than error and exit, but there's nearly nothing else after
that anyway so we
Steve Hay wrote:
Stas Bekman wrote:
Steve Hay wrote:
[...]
I suppose we could have Apache::TestSmoke::run_test() look for the
"server is not running" message, and have it just warn about it
rather than error and exit, but there's nearly nothing else after
that anyway so we don't gain much by no
Stas Bekman wrote:
Steve Hay wrote:
[...]
I suppose we could have Apache::TestSmoke::run_test() look for the
"server is not running" message, and have it just warn about it
rather than error and exit, but there's nearly nothing else after
that anyway so we don't gain much by not exiting. In fa
Steve Hay wrote:
[...]
I suppose we could have Apache::TestSmoke::run_test() look for the
"server is not running" message, and have it just warn about it rather
than error and exit, but there's nearly nothing else after that anyway
so we don't gain much by not exiting. In fact, if the server is
Randy Kobes wrote:
[...]
1. I've changed the warning in the "else" part of the "if kill(0, $pid)"
in stop() to simply say that the server has gone away, which is what
that would mean -- there is no Windows error to retrieve at that point.
That's true ... I have one suggestion: in this sect
On Tue, 14 Oct 2003, Stas Bekman wrote:
> Randy Kobes wrote:
> > On Tue, 14 Oct 2003, Stas Bekman wrote:
[ .. ]
> >>p.s. I'd let you guys figure it out on win32 and once you
> >>are happy we will see how to make that behavior similar on
> >>other platforms. Of course if you need to change things i
On Wed, 15 Oct 2003, Steve Hay wrote:
[ .. ]
> I agree it is undesirable to have A::T depend on W::P::I unless
> necessary, and I think we can get pretty close to what we want without it.
>
> How about the attached patch, which is a slight refinement of Randy's
> first patch. There are three refi
Stas Bekman wrote:
Randy Kobes wrote:
Given that, it seems to me better to use
Win32::Process::Info to get the name of the process, and
kill that if the name is 'Apache.exe' (of course, this
isn't foolproof, as it may be a legitimate Apache process
started from somewhere else, but one has to draw
Randy Kobes wrote:
On Tue, 14 Oct 2003, Stas Bekman wrote:
Steve Hay wrote:
[...]
Would it be possible to change TestSmoke to create a TestServer object
and call the start() and stop() methods on it, rather than using "t/TEST
-start" and "t/TEST -stop", or is that a really stupid question?
As som
On Tue, 14 Oct 2003, Stas Bekman wrote:
> Steve Hay wrote:
> [...]
> > Would it be possible to change TestSmoke to create a TestServer object
> > and call the start() and stop() methods on it, rather than using "t/TEST
> > -start" and "t/TEST -stop", or is that a really stupid question?
>
> As som
Steve Hay wrote:
[...]
Would it be possible to change TestSmoke to create a TestServer object
and call the start() and stop() methods on it, rather than using "t/TEST
-start" and "t/TEST -stop", or is that a really stupid question?
As someone said, there are no stupid questions ;)
Sure, we can d
Randy Kobes wrote:
On Mon, 13 Oct 2003, Steve Hay wrote:
[ .. ]
It's true that we don't need the PID file on Win32. In fact, we don't
even need the PID -- the following chunk of your patch below:
if (my $pid = $obj->GetProcessID) {
Win32::Process::KillProcess($pid, 0);
}
else
On Mon, 13 Oct 2003, Steve Hay wrote:
[ .. ]
> It's true that we don't need the PID file on Win32. In fact, we don't
> even need the PID -- the following chunk of your patch below:
>
> if (my $pid = $obj->GetProcessID) {
> Win32::Process::KillProcess($pid, 0);
> }
> else {
>
Randy Kobes wrote:
On Mon, 13 Oct 2003, Steve Hay wrote:
Randy Kobes wrote:
[ patch included ]
which kills the process (if it's alive - that's what
kill(0, $pid) is supposed to check), and if it does so,
explicitly unlinks the pid file. It also, when the server
starts, unlinks a pid fi
On Mon, 13 Oct 2003, Steve Hay wrote:
> Randy Kobes wrote:
[ patch included ]
> >which kills the process (if it's alive - that's what
> >kill(0, $pid) is supposed to check), and if it does so,
> >explicitly unlinks the pid file. It also, when the server
> >starts, unlinks a pid file if that exists
id file that it creates in
C:\apache2\logs *does* get deleted. I wonder why that doesn't happen
to mp2's t\logs\httpd.pid when the testing code starts & stops it?
well, you explained the reason later on. it's the same on unix.
I also find that if there is such a httpd.pid fi
Randy Kobes wrote:
On Fri, 10 Oct 2003, Steve Hay wrote:
[ ... ]
I don't know how to do the "graceful" stop, though. What
we want is a bit like trying TERM then KILL on Unix, but
that doesn't work on Win32 -- see the entry for kill() in
the perlport manpage! Win32::Process doesn't have any
"
n C:\apache2\logs
*does* get deleted. I wonder why that doesn't happen to mp2's
t\logs\httpd.pid when the testing code starts & stops it?
well, you explained the reason later on. it's the same on unix.
I also find that if there is such a httpd.pid file in place from some
pr
Randy Kobes wrote:
On Fri, 10 Oct 2003, Steve Hay wrote:
[ ... ]
I don't know how to do the "graceful" stop, though. What
we want is a bit like trying TERM then KILL on Unix, but
that doesn't work on Win32 -- see the entry for kill() in
the perlport manpage! Win32::Process doesn't have any
"gra
On Fri, 10 Oct 2003, Steve Hay wrote:
[ ... ]
> I don't know how to do the "graceful" stop, though. What
> we want is a bit like trying TERM then KILL on Unix, but
> that doesn't work on Win32 -- see the entry for kill() in
> the perlport manpage! Win32::Process doesn't have any
> "graceful" kil
tes in C:\apache2\logs
*does* get deleted. I wonder why that doesn't happen to mp2's
t\logs\httpd.pid when the testing code starts & stops it?
Don't know why I didn't see this before, but the answer is obvious,
isn't it? - The PID file doesn't get removed because
*does* get deleted. I wonder why that doesn't happen to mp2's
t\logs\httpd.pid when the testing code starts & stops it?
I also find that if there is such a httpd.pid file in place from some
previous run then t/SMOKE generates an error on my Windows machine
because it tries t
Steve Hay wrote:
I notice that running tests via nmake test, t/TEST or t/SMOKE leaves a
httpd.pid file behind in t/logs after the server has stopped. Is this
supposed to happen? I thought Apache normally deleted the httpd.pid
file when it is stopped.
That's not under Apache-Test's control, it'
I notice that running tests via nmake test, t/TEST or t/SMOKE leaves a
httpd.pid file behind in t/logs after the server has stopped. Is this
supposed to happen? I thought Apache normally deleted the httpd.pid
file when it is stopped.
I also find that if there is such a httpd.pid file in place
On Sun, 26 Jan 2003, Stas Bekman wrote:
> Randy Kobes wrote:
> > With the current cvs mod_perl 2.0, I get a problem about
> > deciding which modules to load from the installed httpd.conf.
> > This patch
>
> Thanks Randy for pointing this out. I was trying to resolve the
> same bug for t/conf/http
Randy Kobes wrote:
With the current cvs mod_perl 2.0, I get a problem about
deciding which modules to load from the installed httpd.conf.
This patch
Thanks Randy for pointing this out. I was trying to resolve the same bug for
t/conf/httpd.conf created in sub-dirs, but broke it for the main serv
With the current cvs mod_perl 2.0, I get a problem about
deciding which modules to load from the installed httpd.conf.
This patch
=
Index: Apache-Test/lib/Apache/TestConfigParse.pm
=
Hi all,
Just want to say thanks for all the great work.
Figure its time for me to start contributing more actively to our
communities.
I have the following setup, and would be happy to test some things for
people not having access to an envirnment like this.
Architecture
350MHz Intel PII w/ 64M
Stas Bekman wrote:
> please test that 5.8.0 has no problems with Apache:: modules on your
> platforms/configs. 5.8.0-RC1 is to be released in 2 days.
>
> I've reinstalled a bunch of Apache:: modules that I usually have with
> 5.8.0-tobe and all were installed fine but these two:
>
> Apache:
please test that 5.8.0 has no problems with Apache:: modules on your
platforms/configs. 5.8.0-RC1 is to be released in 2 days.
I've reinstalled a bunch of Apache:: modules that I usually have with
5.8.0-tobe and all were installed fine but these two:
Apache::SubProcess
Apache::Module
these tw
>>While debugging the problem, I've noticed that if the Makefile.PL in
>>sub-dirs fails, it's silently swallowed. I think it should croak. Is it
>>a problem with MakeMaker in general or something specific to
>>modperl-2.0/Makefile.PL? Most likely the former.
>
>
> this would be a MakeMaker i
On Mon, 8 Apr 2002, Stas Bekman wrote:
> ok, the patch at the end solves the problem. Now any sub-dir can enjoy
> from imported My::test, etc.
looks right to me, +1
> While debugging the problem, I've noticed that if the Makefile.PL in
> sub-dirs fails, it's silently swallowed. I think it sh
Doug MacEachern wrote:
> On Sun, 7 Apr 2002, Stas Bekman wrote:
>
>
>>Yes, but how does it help with Apache::TestMM?
>
>
> well, there's a comment explains what's going on.
> and code to work around the problem.
>
>
>>Its import() already does a similar thing.
>
>
> no, that is not the sa
>>>you could just do:
>>> $self->{conf_opts}->{src_dir} = "$cwd/../..";
>>
> ^^
>
>> $self->{conf_opts}->{src_dir} = "$cwd/../../src";
>>
>>doesn't seem to do the trick, still finds the one installed on the system.
>
>
> try without
On Sun, 7 Apr 2002, Stas Bekman wrote:
> Yes, but how does it help with Apache::TestMM?
well, there's a comment explains what's going on.
and code to work around the problem.
> Its import() already does a similar thing.
no, that is not the same.
> Should it unconditionaly force the aliasing?
Doug MacEachern wrote:
> On Sat, 6 Apr 2002, Stas Bekman wrote:
>
>
>>but that's not what we want. I'm not sure why MY package can be seen
>>only in the first caller of Apache::TestMM::import.
>
>
> see ModPerl::MM::my_import
Yes, but how does it help with Apache::TestMM? Its import() alread
On Sat, 6 Apr 2002, Stas Bekman wrote:
> but that's not what we want. I'm not sure why MY package can be seen
> only in the first caller of Apache::TestMM::import.
see ModPerl::MM::my_import
> $self->{conf_opts}->{maxclients} = 2;
> +$self->{conf_opts}->{libmodperl} = "$cwd/../../src
There are at least two problems with sub-projects which want to have their
own test suite. These problems are relevant to the Apache-Test sub-project
as well:
1. Apache::TestMM's export of MY::test and MY::clean works only once,
which is the top level. Any other attempts to repeat the import
Doug MacEachern wrote:
> i'm going to sync with perl-current (been a few weeks), if there is indeed
> a new $^TAINT var, i think we can just add one for older Perls that works
> the same in perl-current.
cool, the right name is ${^TAINT}
./t/op/taint.t:ok( ${^TAINT}, '$^TAINT is on' );
--
i'm going to sync with perl-current (been a few weeks), if there is indeed
a new $^TAINT var, i think we can just add one for older Perls that works
the same in perl-current.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For add
Registry is supposed to complain if a script sets -T flag on the first
line, but PerlSwitches -T wasn't set in httpd.conf. In 1.x there was a
whole func which was turning the taint mode on and at the same time a
special var Apache::__T was created.
In 2.0 there is no special sub, since we can
On Thu, 3 May 2001, barries wrote:
> > it will be made to work the same as 1.xx, only bootstrapping the .so
> > when inside httpd.
>
> s/inside/outside/?
no. the current .so's contain references to symbols that only exist
inside httpd. if they are loaded outside of httpd, Perl croaks.
the 1.x
On Thu, May 03, 2001 at 02:44:50PM -0700, Doug MacEachern wrote:
> On Thu, 3 May 2001, barries wrote:
>
> > I'm looking for cheap and easy ways to test Perl code without
> > killing/launching a server.
>
> you're talking 2.0, right?
Yup.
> it will be made to work the same as 1.xx, only bootst
On Thu, 3 May 2001, barries wrote:
> Are there any plans to fire up a perl interpreter at httpd -t time,
> perhaps with an implied addition of -c to PerlSwitches?
in 2.0 'httpd -t' will not run any Perl code. it might when
sections are implemented, in which case would should be able to set
PL_
Are there any plans to fire up a perl interpreter at httpd -t time,
perhaps with an implied addition of -c to PerlSwitches?
I'm looking for cheap and easy ways to test Perl code without
killing/launching a server.
FWIW, I started down this trail because I have a button mapped to "perl
-cw %" in
66 matches
Mail list logo
