> Use of uninitialized value in concatenation (.) or string at
> /home/sctemme/asf/perl-framework/Apache-Test/lib/Apache/TestRequest.pm
> The single request for /index.html is the framework's ping to see if
> the server has started. It is not part of the errordoc tests, which
> suggests that these don't get to the server at all.
yes. with 'use warnings FATAL => 'all'' the above error is causing the test
to die before it ever starts.
the problem seems to be in Apache::TestRequest::resolve_url(), but there is
no way for me to tell from here which part isn't being found properly.
are you running ssl? maybe putting this line
Apache::TestRequest::scheme('http');
just prior to the
Apache::TestRequest::module('error_document');
line in t/apache/errordoc.t would help. this appears to be the only
difference between errordoc.t and other modules that use a similar set of
directives to configure the test.
outside of that make sure that it's a fresh, pristine checkout, as if you
have some files hanging around it might collide with some of the
autogenerated stuff.
if neither of these work we'll have to poke around a bit in the internals,
but let's wait and see.
>>
>> it would be great to have the tests at 100% for current 1.3, 2.0, and
>> 2.1.
>> if we can get it to that point I volunteer to be the project watchdog
>> who
>> will pipe up if some commit causes the framework to suddenly fail (at
>> least
>> on the platform I run, currently fedora). but until we get to 100% the
>> framework is kinda useless for RC testing as far as I'm concerned -
>> "known
>> failures" don't really mean much for this kind of thing.
>
>
> It has long been one of my desires to do an automated nightly
> build/test run on all three branches. As I get my lab set up here
> (which should happen in the next couple of weeks), I may be able to
> finally get that set up.
cool, that would be great.
>
> When I was testing a product based on httpd 2.0, I would keep a list of
> known failures (we had some patches that the framework didn't deal
> with) on our internal Wiki, so I would know that a test had been
> failing and I wouldn't have to analyze every failure to death every
> time.
yeah, that's the problem, wasting time trying to figure out whether the
failure is real or not, then somebody else doing the same thing. and it's
not an easy process, getting gritty with the code to make absolutely sure
whether the failure is in the codebase or the test expectations.
> That was stuff like OpenSSL would put the email field name of a
> certificate DN in uppercase, and RSA SSLC would put it in lowercase. Or
> was it the other way around?
it would be great if we could capture that kind of thing in the test itself,
either in the actual test or in the framework (allow for case-insensitive
matches, for instance).
if you're willing (and can share internal knowledge publically, etc), I can
help integrate this particular issue into the framework. really, I'll do
whatever is required to get us at 100% - massive handholding if you know
what the issue is but can't quite grok the framework, verbose non-RTFM
explanations over irc or email, whatever...
>
> Anyway, it would be great to get something like that going on a daily
> basis. Kinda like an httpd project interpretation of Gump, like, Httpump.
agreed. well, let's see about what we can do to get the framework at 100%
and we can go from there. it's great to have someone else interested in all
of this :)
--Geoff
