Re: Apache::Cookie -> Apache2::Cookie API Change?
Derek R. Price wrote:
> Now, using the same Perl source with Apache2::Cookie->new, an undefined
> value is returned instead of the new cookie. At best, this appears to
> be an API change and should be documented. At worst it appears to be a
> bug in libapreq2 that should be fixed.
http://svn.apache.org/viewvc?view=rev&rev=447770
How's that ?
I agree back compat is good, but I can't change the API at this juncture or we
break backcompat in the 2.x series
with itself.
my $cookie = Apache2::Cookie->new($r, name => 'n');
if ($cookie) {
}
These ifs would suddenly be executed.
> I discovered this using libapreq2 2.0.7.
2.08 is out :)
--
Philip M. Gollucci ([EMAIL PROTECTED]) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
"In all that I've done wrong I know I must have done something right to
deserve a hug every morning and butterfly kisses at night."
__ ___ ___ __
/ |/ /_ __/ __/ __ \/ /
/ /|_/ / // /\ \/ /_/ / /__
/_/ /_/\_, /___/\___\_\___/
<___/
Occasional problems with URI package under mp
Hi all!
We've been seeing some really weird things with LWP, but only when
running it on the web server. It works fine when running from the
command line.
For example, doing this:
my $netloc = URI->new('http://www.blogger.com/feeds/default/blogs');
currently results in a
Can't locate object method "new" via package "URI"
error.
The first suspicion is of course that there exists a different package
URI somewhere in the system, which is only used by the web server, but
I can't find anything. So, I'm totally in the dark here... This email
is a shot in the dark too, but with all the good people here, perhaps
someone might have some light to shed?
Cheers,
Kjetil
--
Kjetil Kjernsmo
Information Systems Developer
Opera Software ASA
RE: Occasional problems with URI package under mp
Kjetil Kjernsmo wrote:
> Hi all!
>
> We've been seeing some really weird things with LWP, but only when
> running it on the web server. It works fine when running from the
> command line.
>
> For example, doing this:
> my $netloc = URI->new('http://www.blogger.com/feeds/default/blogs');
> currently results in a
> Can't locate object method "new" via package "URI"
> error.
Maybe a stupid question, but do you have "use URI" in that program?
Philip
Re: hmm..testing with mod_perl and lwp
Greger wrote: > Okey so this is the situation I have right now: > 0)mysql based application > 1)server with mod_perl > 2)client is browser for time being, might be a mobile terminal or "custom > client application" in the future > 3)testing ( with perl-unit ) I usually use Test::Class and Test::More, but that's my preference. > 3.1)testing package method functionality separately from the ui > 3.2)testing web interface of the entire application with LWP::UserAgent and > XML::XPath Again, I use WWW::Mechanize, Test::WWW::Mechanize and maybe Test::HTML::Content > The thing is:I'd like to discuss the issues that might arise as the > development goes on further with this way of working. As for now, I am happy > with what I am doing, it feels quite good and correct:but=>if anyone has > experience working this way I'd like to know what you/they have experienced. One of the main irritants in testing the UI of a web application is that it can change quite frequently. Now changing your tests when the program changes is to be somewhat expected, but depending on the changes, it can get annoying. I would recommend against testing for a specific structure and just testing for the data. But hopefully most of the markup is abstracted enough that most UI changes are done in the style sheets. Even with this irritant, these kind of tests have caught many bugs for me that straight unit-testing would not have found. -- Michael Peters Developer Plus Three, LP
Re: Occasional problems with URI package under mp
On Tuesday 19 September 2006 15:26, Garrett, Philip (MAN-Corporate)
wrote:
> Maybe a stupid question, but do you have "use URI" in that program?
Yep! But an entirely appropriate question in this situation. :-)
Actually, the problem was far less reproducible than I first thought...
At some point, I would get this error with
use URI;
use LWP::UserAgent;
my $netloc = URI->new('http://www.blogger.com/feeds/default/blogs');
my $ua = LWP::UserAgent->new;
warn "foo";
print "Content-Type: text/plain\n\nfoo";
but that works right now...
For a while, I could rearrange the use statements to make it work, but
that now appears to be random...
--
Kjetil Kjernsmo
Information Systems Developer
Opera Software ASA
Re: Occasional problems with URI package under mp
Kjetil Kjernsmo wrote:
> The first suspicion is of course that there exists a different package
> URI somewhere in the system, which is only used by the web server, but
> I can't find anything.
Print out $INC{'URI.pm'} from both Apache and the cmd line just to be sure
they're using the same thing.
--
Michael Peters
Developer
Plus Three, LP
RE: Occasional problems with URI package under mp
Kjetil Kjernsmo wrote:
>
> Actually, the problem was far less reproducible than I first
> thought... At some point, I would get this error with
> use URI;
> use LWP::UserAgent;
> my $netloc = URI->new('http://www.blogger.com/feeds/default/blogs');
> my $ua = LWP::UserAgent->new;
>
> warn "foo";
> print "Content-Type: text/plain\n\nfoo";
>
> but that works right now...
>
> For a while, I could rearrange the use statements to make it work, but
> that now appears to be random...
Well, that is pretty weird. If some of the Apache children are using a
different URI.pm than the standard system one, you could find out by
logging the %INC entry before you try to call URI->new.
warn "URI.pm location: $INC{'URI.pm'}\n";
If it's different for the failures than it is for the successes, you
have your culprit.
Regards,
Philip
Re: Occasional problems with URI package under mp
On Tuesday 19 September 2006 16:05, Garrett, Philip (MAN-Corporate)
wrote:
> warn "URI.pm location: $INC{'URI.pm'}\n";
>
> If it's different for the failures than it is for the successes, you
> have your culprit.
Hmmm, nope, that was OK...
So, I have
use URI;
warn "URI.pm location: $INC{'URI.pm'}\n";
my $netloc;
eval {
$netloc = URI->new('http://www.blogger.com/feeds/default/blogs');
}; warn $@;
to which I get
URI.pm location: /usr/lib/perl5/Apache2/URI.pm
Can't locate object method "new" via package "URI" at [blah]
Now, there is quite a lot of our internal code around, out of which
quite a few things suck, but still, this really mystifies me...
--
Kjetil Kjernsmo
Information Systems Developer
Opera Software ASA
Re: Occasional problems with URI package under mp
Kjetil Kjernsmo wrote:
> On Tuesday 19 September 2006 16:05, Garrett, Philip (MAN-Corporate)
> wrote:
>> warn "URI.pm location: $INC{'URI.pm'}\n";
>>
>> If it's different for the failures than it is for the successes, you
>> have your culprit.
>
> Hmmm, nope, that was OK...
Doesn't look OK to me...
> URI.pm location: /usr/lib/perl5/Apache2/URI.pm
> Can't locate object method "new" via package "URI" at [blah]
That's Apache2::URI, not URI. What does the command line version of that same
script print? Do you have "/usr/lib/perl5/Apache2" in your @INC? If so, you
shouldn't (I believe that was an old 1.99 thing before the change into the
Apache2 namespace).
--
Michael Peters
Developer
Plus Three, LP
bug report : "make test" failure when compiling from source.
1. Problem Description: Trying to build and install mod_perl from source. Have already built perl and apache 2.2 from source, they both seem to be fine (latest stable, both). But it is my first cut at this, so I could have made a dumb error. Anyhow, all help appreciated. "make test" fails. Here are the failures: t/apache/content_length_header..FAILED test 17 t/api/statusFAILED tests 4-5 (verbose output:) /usr/local/apache2/bin/httpd -d /home/daniel/build/mod_perl-2.0.2/t -f /home/daniel/build/mod_perl-2.0.2/t/conf/httpd.conf -D APACHE2 -D PERL_USEITHREADS using Apache/2.2.3 (prefork MPM) [Tue Sep 19 23:31:54 2006] [info] 6 Apache2. waiting 120 seconds for server to start: ok (waited 1 secs) server localhost:8529 started server localhost:8530 listening (filter_out_apache) server l# Failed test 17 in t/apache/content_length_header.t at line 71 fail #2 # Failed test 4 in t/api/status.t at line 35 # Failed test 5 in t/api/status.t at line 36 [warning] server localhost:8529 shutdown [ error] error running tests (please examine t/logs/error_log) erver localhost:8536 listening (TestVhost::log) server localhost:8537 listening (TestVhost::config) server localhost:8538 listening (TestProtocol::pseudo_http) server localhost:8539 listening (TestProtocol::echo_bbs) server localhost:8540 listening (TestProtocol::echo_filter) server localhost:8541 listening (TestProtocol::echo_bbs2) server localhost:8542 listening (TestProtocol::echo_timeout) server localhost:8543 listening (TestProtocol::echo_block) server localhost:8544 listening (TestProtocol::echo_nonblock) server localhost:8545 listening (TestPreConnection::note) server localhost:8546 listening (TestHooks::hookrun) server localhost:8547 listening (TestHooks::init) server localhost:8548 listening (TestHooks::trans) server localhost:8549 listening (TestHooks::stacked_handlers2) server localhost:8550 listening (TestHooks::startup) server localhost:8551 listening (TestFilter::in_bbs_inject_header) server localhost:8552 listening (TestFilter::in_str_msg) server localhost:8553 listening (TestFilter::both_str_con_add) server localhost:8554 listening (TestFilter::in_bbs_msg) server localhost:8555 listening (TestDirective::perlmodule) server localhost:8556 listening (TestDirective::perlrequire) server localhost:8557 listening (TestDirective::perlloadmodule4) server localhost:8558 listening (TestDirective::perlloadmodule5) server localhost:8559 listening (TestDirective::perlloadmodule3) server localhost:8560 listening (TestDirective::perlloadmodule6) server localhost:8561 listening (TestHooks::push_handlers_anon) t/apache/content_length_header1..27 # Running under perl version 5.008008 for linux # Current time local: Tue Sep 19 23:31:56 2006 # Current time GMT: Tue Sep 19 21:31:56 2006 # Using Test.pm version 1.25 # Using Apache/Test.pm version 1.27 # testing : GET /TestApache__content_length_header code # expected: 200 # received: 200 ok 1 # testing : GET /TestApache__content_length_header C-L header # expected: 0 # received: 0 ok 2 # testing : GET /TestApache__content_length_header content # expected: # received: ok 3 # testing : GET /TestApache__content_length_header?set_content_length code # expected: 200 # received: 200 ok 4 # testing : GET /TestApache__content_length_header?set_content_length C-L header # expected: 0 # received: 0 ok 5 # testing : GET /TestApache__content_length_header?set_content_length content # expected: # received: ok 6 # testing : GET /TestApache__content_length_header?send_body code # expected: 200 # received: 200 ok 7 # testing : GET /TestApache__content_length_header?send_body C-L header # expected: undef # received: undef ok 8 # testing : GET /TestApache__content_length_header?send_body content # expected: This is a response string # received: This is a response string ok 9 # testing : GET /TestApache__content_length_header?send_body+set_content_length code # expected: 200 # received: 200 ok 10 # testing : GET /TestApache__content_length_header?send_body+set_content_length C-L header # expected: 25 # received: 25 ok 11 # testing : GET /TestApache__content_length_header?send_body+set_content_length content # expected: This is a response string # received: This is a response string ok 12 # testing : HEAD /TestApache__content_length_header code # expected: 200 # received: 200 ok 13 # testing : HEAD /TestApache__content_length_header C-L header # expected: undef # received: undef ok 14 # testing : HEAD /TestApache__content_length_header content # expected: # received: ok 15 # testing : HEAD /TestApache__content_length_header?set_content_length code # expected: 200 # received: 200 ok 16 # testing : HEAD /TestApache__content_length_header?set_content_length C-L header # expected: undef # received: 25 not ok 17 # testing : HEAD /TestApache__content_length_header?set_content_length content # expected: # received: ok 18 # testing : HEAD /TestApache__content_length_header?send_body code # expected: 200 #
Re: bug report : "make test" failure when compiling from source.
Daniel McBrearty wrote: 1. Problem Description: Trying to build and install mod_perl from source. Have already built perl and apache 2.2 from source, they both seem to be fine (latest stable, both). But it is my first cut at this, so I could have made a dumb error. Anyhow, all help appreciated. "make test" fails. Here are the failures: t/apache/content_length_header..FAILED test 17 t/api/statusFAILED tests 4-5 Both are fixed in SVN. And Will be in 2.0.3. 2.0.3 is in Release Candidate Phase NOW. These errors btw are completely harmless. mod_perl is fine to use with them. Only the tests themselves changed. See the list archives.
install mp1 under linux 2.6 kernel
Hello,friends, I installed the mp1 (modperl-1.29) and apache1.3 on linux 2.6 kernel.First I compile the modperl lib: perl Makefile.PL \ APACHE_SRC=../apache_1.3.36/src \ NO_HTTPD=1 \ USE_APACI=1 \ PREP_HTTPD=1 \ EVERYTHING=1 make;make install Then I install the apache: ./configure --prefix=/home/apache1.3 --disable-module=all \ --enable-module=alias --enable-module=log_config \ --enable-module=dir --enable-module=mime --enable-module=cgi \ --activate-module=src/modules/perl/libperl.a make;make install It can't get finished.I got the error messages like: modules/perl/libperl.a(Server.o)(.text+0x22df): In function `XS_Apache__Server_gid':: undefined reference to `Perl_Gthr_key_ptr' modules/perl/libperl.a(Server.o)(.text+0x24f6): In function `XS_Apache__Server_is_virtual':: undefined reference to `Perl_Gthr_key_ptr odules/perl/libperl.a(Server.o)(.text+0x2bdd): In function `boot_Apache(...)(long double, void,...)(long double) static':: undefined reference to `Perl_Gthr_key_ptr' ... lots of these. Could you tell me how to resolve it?Thanks. -- Jeff Pang NetEase AntiSpam Team http://corp.netease.com
