Re: mod_perl segfaulting (Redhat 7.2, DSO, Apache 1.3.20)
On 26 November 2001 23:41 (+), Ged Haywood wrote: > Did you compile Perl yourself? Yep. -- john chia <[EMAIL PROTECTED]> starnix inc. tollfree: 1-87-pro-linuxthornhill, ontario, canada http://www.starnix.com professional linux services & products
Re: array's first element is empty
Well, I don't want to cry wolf (or Bug in this case). I wasn't going to bring it up except that this was getting shoved off of mod_perl, and I didn't think that it should... I'm not going to cry bug unless I can back it up - it just might be a fluke coincidence - I don't know. I just wanted to let people know. Issac PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B - Original Message - From: "Joshua Chamas" <[EMAIL PROTECTED]> To: "Issac Goldstand" <[EMAIL PROTECTED]> Cc: "Viljo Marrandi" <[EMAIL PROTECTED]>; "modperl list" <[EMAIL PROTECTED]> Sent: Tuesday, November 27, 2001 1:38 Subject: Re: array's first element is empty > Issac Goldstand wrote: > > > > I don't think this is OT. I have had a similar error in which SELECT > > statements return fine under mod_cgi, but mysteriously get an extra null > > field underl mod_perl with Apache::DBI... I don't know what causes it, nor > > have I looked into it, but I think it is somewhat related to or caused by > > mod_perl or some of its' modules... > > > > This sounds like it might be a bug then, and I might bring it up on > the DBI list and see if there is a solution. It might be that something > in the glue of Apache::DBI is causing this problem too, but would > doubt that, as I believe this glue only overrides behavior > for connect/disconnect. > > Note that I have never seen this bug, working with Oracle & mysql > under various perls & mod_perl builds, so you might look at your > particular software versions as having the problems, or even your > particular database driver ( DBD::* ) for the problem. Also, > sometimes DBD::* drivers are guided by %ENV settings, like Oracle, > so make sure that your mod_perl has the same %ENV as your > when running under mod_cgi. > > --Josh > _ > Joshua Chamas Chamas Enterprises Inc. > NodeWorks Founder Huntington Beach, CA USA > http://www.nodeworks.com1-714-625-4051 >
Re: mod_perl segfaulting (Redhat 7.2, DSO, Apache 1.3.20)
Hi there, On Mon, 26 Nov 2001, John Chia wrote: > Still segfaulting. Same place. [snip] > Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: [snip] > Compiler: [snip] > gccversion='2.96 2731 (Red Hat Linux 7.12.96-98)', Did you compile Perl yourself? 73, Ged.
Re: array's first element is empty
Issac Goldstand wrote: > > I don't think this is OT. I have had a similar error in which SELECT > statements return fine under mod_cgi, but mysteriously get an extra null > field underl mod_perl with Apache::DBI... I don't know what causes it, nor > have I looked into it, but I think it is somewhat related to or caused by > mod_perl or some of its' modules... > This sounds like it might be a bug then, and I might bring it up on the DBI list and see if there is a solution. It might be that something in the glue of Apache::DBI is causing this problem too, but would doubt that, as I believe this glue only overrides behavior for connect/disconnect. Note that I have never seen this bug, working with Oracle & mysql under various perls & mod_perl builds, so you might look at your particular software versions as having the problems, or even your particular database driver ( DBD::* ) for the problem. Also, sometimes DBD::* drivers are guided by %ENV settings, like Oracle, so make sure that your mod_perl has the same %ENV as your when running under mod_cgi. --Josh _ Joshua Chamas Chamas Enterprises Inc. NodeWorks Founder Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Re: array's first element is empty
I don't think this is OT. I have had a similar error in which SELECT statements return fine under mod_cgi, but mysteriously get an extra null field underl mod_perl with Apache::DBI... I don't know what causes it, nor have I looked into it, but I think it is somewhat related to or caused by mod_perl or some of its' modules... Issac PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B - Original Message - From: "Joshua Chamas" <[EMAIL PROTECTED]> To: "Viljo Marrandi" <[EMAIL PROTECTED]> Cc: "modperl list" <[EMAIL PROTECTED]> Sent: Tuesday, November 27, 2001 1:19 Subject: Re: array's first element is empty > Viljo Marrandi wrote: > > > > Hello, > > > > Not sure if this is mod_perl related, but i hope someone can help me > > anyway. When i do DBI queries from mod_perl handler and put all returned > > results in array then array's first element is empty, I wonder why? I > > don't like to shift off first element every time i return the result. > > Has anyone seen this before and what could cause this? > > > > This is off topic for mod_perl, and should as such either not be posted, > or posted with a [OT] in the beginning of the subject line. > > The DBI mailing lists would be of greater help, listed here at: > > http://www.isc.org/services/public/lists/dbi-lists.html > > To answer your question, a query like: > > select nothing,something from table > > would have a undef value returned from the nothing column > if the data in that column were NULL. You probably should > remove the nothing column from your query instead of shifting > the results. > > --Josh > _ > Joshua Chamas Chamas Enterprises Inc. > NodeWorks Founder Huntington Beach, CA USA > http://www.nodeworks.com1-714-625-4051 >
Re: array's first element is empty
Viljo Marrandi wrote: > > Hello, > > Not sure if this is mod_perl related, but i hope someone can help me > anyway. When i do DBI queries from mod_perl handler and put all returned > results in array then array's first element is empty, I wonder why? I > don't like to shift off first element every time i return the result. > Has anyone seen this before and what could cause this? > This is off topic for mod_perl, and should as such either not be posted, or posted with a [OT] in the beginning of the subject line. The DBI mailing lists would be of greater help, listed here at: http://www.isc.org/services/public/lists/dbi-lists.html To answer your question, a query like: select nothing,something from table would have a undef value returned from the nothing column if the data in that column were NULL. You probably should remove the nothing column from your query instead of shifting the results. --Josh _ Joshua Chamas Chamas Enterprises Inc. NodeWorks Founder Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Re: receiving XML by POST
On Mon, 26 Nov 2001, Joshua Chamas wrote:
> Maarten Stolte wrote:
> >
> > Hello,
> >
> > i'm trying to figure out how to receive an xml message/file/stream(?)
> > using POST, and how to be able to then send that to somewhere else
> > (DBI).
> > We're using MASON, don't know if that is information needed in this, but
> > i saw something about MASON picking up all posts.
>
> I believe the usual way to access POST data, $r->content, is only
> for form data. To get XML data, try this:
>
> my $buf = '';
> $r->read($buf, $ENV{CONTENT_LENGTH});
>
> This is a general mod_perl API issue, and not necessarily specific
> to Mason, though Mason may have some other API specific to this.
> This may in fact collide with Mason form processing if there is
> any, since a mod_perl application will hang if it tries to
> read the POST data twice.
>
Mason generally does an automatic read of POST data, specify what form
fields you want, and it'll stuff the values into variables named the same
as the name fields in the POST data. You should just be able to have the
XML be the value for some name/value pair, then do all your XML
parsing/DBI work on that value.
Re: receiving XML by POST
Maarten Stolte wrote:
>
> Hello,
>
> i'm trying to figure out how to receive an xml message/file/stream(?)
> using POST, and how to be able to then send that to somewhere else
> (DBI).
> We're using MASON, don't know if that is information needed in this, but
> i saw something about MASON picking up all posts.
I believe the usual way to access POST data, $r->content, is only
for form data. To get XML data, try this:
my $buf = '';
$r->read($buf, $ENV{CONTENT_LENGTH});
This is a general mod_perl API issue, and not necessarily specific
to Mason, though Mason may have some other API specific to this.
This may in fact collide with Mason form processing if there is
any, since a mod_perl application will hang if it tries to
read the POST data twice.
-- Josh
_
Joshua Chamas Chamas Enterprises Inc.
NodeWorks Founder Huntington Beach, CA USA
http://www.nodeworks.com1-714-625-4051
ANNOUNCEMENT: HTML::Template::JIT 0.02
HTML::Template::JIT - a just-in-time compiler for HTML::Template CHANGES - Added support for loop_context_vars. - Added support for global_vars. - Fixed bug in loop param handling that made loop variables case-sensitive. DESCRIPTION This module provides a just-in-time compiler for HTML::Template. Templates are compiled into native machine code using Inline::C. The compiled code is then stored to disk and reused on subsequent calls. HTML::Template::JIT is up to 4 times as fast as HTML::Template using caching. NOTE This module is not feature-complete. Be sure to read the CAVEATS section in the documentation before using! AVAILABILITY This module is available on SourceForge. Download it at: http://prdownloads.sourceforge.net/html-template/HTML-Template-JIT-0.02.tar.gz The module is also available on CPAN. You can get it using CPAN.pm or go to: http://www.cpan.org/authors/id/S/SA/SAMTREGAR/ CONTACT INFO You can join the HTML::Template mailing-list by sending a blank message to [EMAIL PROTECTED]
Re: mod_perl segfaulting (Redhat 7.2, DSO, Apache 1.3.20)
Hi. On 24 November 2001 12:35 (+0800), Stas Bekman wrote: > Check this out: > http://perl.apache.org/guide/install.html#When_DSO_can_be_Used Nope. Still segfaulting. Same place. > yes, the output of perl -V, the args used to build mod_perl (grab the > src.rpm, rpm -i and look at the spec file. But first see if the above > URL solves your problem. ** perl -V Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=linux, osvers=2.4.7-10, archname=i386-linux uname='linux europa.starnix.com 2.4.7-10 #1 thu sep 6 17:27:27 edt 2001 i686 unknown ' config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 -Dcc=gcc -Dcccdlflags=-fPIC -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dd_dosuid -Dd_semctl_semun -Di_db -Di_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Uuselargefiles -Ubincompat5005' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=undef usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='gcc', ccflags ='-fno-strict-aliasing -I/usr/local/include', optimize='-O2 -march=i386 -mcpu=i686', cppflags='-fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='2.96 2731 (Red Hat Linux 7.1 2.96-98)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4 alignbytes=4, usemymalloc=n, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -ldl -lm -lc -lcrypt -lutil perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil libc=/lib/libc-2.2.4.so, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: Built under linux Compiled at Nov 25 2001 12:57:07 @INC: /usr/lib/perl5/5.6.1/i386-linux /usr/lib/perl5/5.6.1 /usr/lib/perl5/site_perl/5.6.1/i386-linux /usr/lib/perl5/site_perl/5.6.1 /usr/lib/perl5/site_perl/5.6.0/i386-linux /usr/lib/perl5/site_perl/5.6.0 /usr/lib/perl5/site_perl/5.005/i386-linux /usr/lib/perl5/site_perl/5.005 /usr/lib/perl5/site_perl . ** mod_perl build: ** RPM_OPT_FLAGS="-O2 -march=i386 -mcpu=i686" CFLAGS="$RPM_OPT_FLAGS" \ perl Makefile.PL USE_APXS=1 \ WITH_APXS=/usr/sbin/apxs \ EVERYTHING=1 \ CCFLAGS="$RPM_OPT_FLAGS -fPIC" make ** usemymalloc/bincompat [root@h241 RPMS]# perl -V:usemymalloc usemymalloc='n'; [root@h241 RPMS]# perl -V:bincompat5005 bincompat5005='undef'; ** i386 modules perl-Array-RefElem-0.02-13mtl.i386.rpm perl-Authen-Smb-0.91-7mtl.i386.rpm perl-Compress-Zlib-1.14-9mtl.i386.rpm perl-Crypt-SSLeay-0.31-8mtl.i386.rpm perl-DBI-1.20-8mtl.i386.rpm perl-Filesys-Statvfs_Df-0.67-7mtl.i386.rpm perl-Filter-1.25-5mtl.i386.rpm perl-GD-1.33-11mtl.i386.rpm perl-GTop-0.10-6mtl.i386.rpm perl-HTML-Parser-3.25-8mtl.i386.rpm perl-IO-Interface-0.97-8mtl.i386.rpm perl-libapreq-0.33-13mtl.i386.rpm perl-MIME-Base64-2.12-9mtl.i386.rpm perl-Newt-1.08-6mtl.i386.rpm perl-Storable-1.0.13-5mtl.i386.rpm perl-Time-HiRes-01.20-9mtl.i386.rpm Thanks! -- john chia <[EMAIL PROTECTED]> starnix inc. tollfree: 1-87-pro-linuxthornhill, ontario, canada http://www.starnix.com professional linux services & products
Re: [modperl-site design challenge]
On Monday 26 November 2001 10:07, Bill Moseley wrote: ---snip--- > Does it need to render well in old browsers? (e.g. netscape 4.08) > > There's a lot of old browsers out there, but maybe anyone looking at > mod_perl would be a bit more up to date... > > > > Bill Moseley > mailto:[EMAIL PROTECTED] Hi: Think Accessibility! You really should be setting this up for global accessibility and for those with disabilities!Standards begin here, don't you think? Just a thought, Tom
Re: [modperl-site design challenge]
At 11:14 AM 11/26/01 -0500, John Saylor wrote: >> * While the design might not be to cool from the designers point of view, I >> like it because it is simple, doesn't use HTML-tables, is small and fast >> (/very/ little HTML-overhead) and accessible to disabled people. > >But that *is* cool. I think it's very well designed. To me, usability is >the main design goal. Keep up the good work! Does it need to render well in old browsers? (e.g. netscape 4.08) There's a lot of old browsers out there, but maybe anyone looking at mod_perl would be a bit more up to date... Bill Moseley mailto:[EMAIL PROTECTED]
Re: mod_perl segfaulting (Redhat 7.2, DSO, Apache 1.3.20)
I noticed you list XML::Simple. It is a favorite module of mine, but it uses
XML::Parser which uses the expat XML parser. It is seems that mod_perl has problems
with XML::Parser. This problem is supposed to be fixed in Apache 1.3.22, but I still
had problems with strange segfaults and munched scalers when using XML::Parser. I
recommend switching XML parsers to one that doesn't use expat. I had good luck using
XML::LibXML, especially after making a Simple API :)
Matthew Gerlach
John Chia wrote:
> Hi,
>
> I have a very annoying problem with mod_perl segfaulting. It must be
> some perl code, but I cannot isolate where. Here are the symptoms, all
> running on 7.2:
>
> 1) does not happen with apache/mod_perl compiled and linked on RedHat 6.2
> 2) does not happen with apache/mod_perl statically linked on Redhat 7.2
> 3) does happen with apache from 6.2 and mod_perl (re)linked on 7.2
>
> I don't really want to go static, plus I'm a good guinea pig for this
> sort of thing! Stack traces...
>
> ** gdb 'where' after segfaulting:
>
> #0 __pthread_mutex_lock (mutex=0x67617765) at mutex.c:99
> #1 0x401b0974 in __libc_free (mem=0x40515b18) at malloc.c:3152
> #2 0x404bdb08 in Perl_sv_clear () from /usr/lib/apache/libperl.so
> #3 0x404bdd3f in Perl_sv_free () from /usr/lib/apache/libperl.so
> #4 0x404b7bf4 in S_visit () from /usr/lib/apache/libperl.so
> #5 0x404b7c87 in Perl_sv_clean_all () from /usr/lib/apache/libperl.so
> #6 0x4046f08e in perl_destruct () from /usr/lib/apache/libperl.so
> #7 0x4044ee2b in perl_shutdown () from /usr/lib/apache/libperl.so
> #8 0x4044f2a5 in mp_dso_unload () from /usr/lib/apache/libperl.so
> #9 0x080525f9 in ap_run_cleanup () at eval.c:41
> #10 0x080510cb in ap_clear_pool () at eval.c:41
> #11 0x08060220 in ap_child_terminate () at eval.c:41
> #12 0x08060c03 in main () at eval.c:41
> #13 0x40150306 in __libc_start_main (main=0x8060780 , argc=2,
> ubp_av=0xbb54, init=0x804fb20 <_init>, fini=0x8089450 <_fini>,
> rtld_fini=0x4000d2cc <_dl_fini>, stack_end=0xbb4c)
> at ../sysdeps/generic/libc-start.c:129
>
> ** strace is not at all helpful.. reads mime.types, opens access_log
> and does some rt_sigprocmask stuff then SIGSEGV.
>
> ** Interactive debugger via Apache::DB .. (sorry bout the mess)
>
> DBI::CODE(0x884e440)(/usr/lib/perl5/site_perl/5.6.1/i386-linux/DBI.pm:349):
> 349:return unless defined &DBI::trace_msg; # return unless
> bootstrap'd ok
> DBI::CODE(0x884e440)(/usr/lib/perl5/site_perl/5.6.1/i386-linux/DBI.pm:350):
> 350:local ($!,$?);
> DBI::CODE(0x884e440)(/usr/lib/perl5/site_perl/5.6.1/i386-linux/DBI.pm:351):
> 351:DBI->trace_msg("-- DBI::END\n", 2);
> DBI::CODE(0x884e440)(/usr/lib/perl5/site_perl/5.6.1/i386-linux/DBI.pm:353):
> 353:$DBI::PERL_ENDING = $DBI::PERL_ENDING = 1; # avoid typo
> warning
> DBI::CODE(0x884e440)(/usr/lib/perl5/site_perl/5.6.1/i386-linux/DBI.pm:354):
> 354:DBI->disconnect_all() if %DBI::installed_drh;
> AppConfig::State::AUTOLOAD(/usr/lib/perl5/site_perl/5.6.1/AppConfig/State.pm:449):
> 449:my $self = shift;
> AppConfig::State::AUTOLOAD(/usr/lib/perl5/site_perl/5.6.1/AppConfig/State.pm:450):
> 450:my ($variable, $attrib);
> AppConfig::State::AUTOLOAD(/usr/lib/perl5/site_perl/5.6.1/AppConfig/State.pm:454):
> 454:($variable = $AUTOLOAD) =~ s/.*:://;
> AppConfig::State::AUTOLOAD(/usr/lib/perl5/site_perl/5.6.1/AppConfig/State.pm:457):
> 457:$variable eq 'DESTROY' && return;
> AppConfig::AUTOLOAD(/usr/lib/perl5/site_perl/5.6.1/AppConfig.pm:206):
> 206:my $self = shift;
> AppConfig::AUTOLOAD(/usr/lib/perl5/site_perl/5.6.1/AppConfig.pm:207):
> 207:my $method;
> AppConfig::AUTOLOAD(/usr/lib/perl5/site_perl/5.6.1/AppConfig.pm:211):
> 211:($method = $AUTOLOAD) =~ s/.*:://;
> AppConfig::AUTOLOAD(/usr/lib/perl5/site_perl/5.6.1/AppConfig.pm:214):
> 214:$method eq 'DESTROY' && return;
> Segmentation fault
>
> ** Semi-complete module list:
> perl-HTML-Table-1.12a-3mtl
> perl-Log-Agent-0.2.8-3mtl
> perl-MLDBM-2.00-7mtl
> perl-URI-1.17-5mtl
> perl-Storable-1.0.13-3mtl
> perl-Filesys-Statvfs_Df-0.67-4mtl
> perl-Proc-ProcessTable-0.33-4mtl
> perl-IO-Interface-0.97-6mtl
> perl-DBD-Pg-1.01-5mtl
> perl-libnet-1.0704-8mtl
> perl-Apache-GTopLimit-0.01-3mtl
> perl-Crypt-SSLeay-0.31-5mtl
> perl-Net-IMAP-Simple-0.93-4mtl
> perl-App-Config-1.09-5mtl
> perl-FreezeThaw-0.41-6mtl
> perl-GTop-0.10-4mtl
> perl-POE-0.17-4mtl
> perl-Authen-Smb-0.91-3mtl
> perl-Convert-ASN1-0.07-1
> perl-IMAP-Admin-1.5.1-3mtl
> perl-Net-SNMP-3.5-1
> perl-HTML-Mason-1.04-6mtl
> perl-GDGraph-1.33-6mtl
> perl-XML-Writer-0.4-0
> perl-Time-HiRes-01.20-7mtl
> perl-Archive-Tar-0.22-6mtl
> perl-XML-Parser-2.30-7
> perl-Adaptor-0.2-1
> perl-GD-1.33-9mtl
> perl-Apache-DB-0.06-1mtl
> perl-ldap-0.25-5mtl
> perl-Params-Validate-0.07-4mtl
> perl-GDTextUtil-0.80-6mtl
> perl-HTML-Parser-3.25-5mtl
> perl-Net-DNS-0.12-6mtl
> perl-Net-Printer-0.20-1
> perl-MIME-Base64-2.12-7mt
Re: [modperl-site design challenge] Thomas Klausner (domm)
Hi ( 01.11.25 22:37 +0100 ) Thomas Klausner: > You can look at my idea of the the new modperl-site design here: > http://domm.zsi.at/modperl-site-domm/ I like it. The main part of it is now just an elaboration of the contents, I imagine this will be a changing teaser of some sort. > * While the design might not be to cool from the designers point of view, I > like it because it is simple, doesn't use HTML-tables, is small and fast > (/very/ little HTML-overhead) and accessible to disabled people. But that *is* cool. I think it's very well designed. To me, usability is the main design goal. Keep up the good work! -- \js
Re: Apache::Registry HTTP HEAD "feature" fix ;-)
> well, I just gave you a patch that worked :) basically, it only provides a > solution for mod_cgi compatible scripts, but if you're using the mod_perl > API then it is up to you to check $r->header_only and take appropriate > action... True, however your patch also means that it's necessary to recompile stuff, which is not always possible. In addition (and as an exercise) I'd be happy to find a clean Perl way to do it. Best regards, -- == \__ = /\/\ IT'S TIME FOR A DIFFERENT KIND OF WEB / /\__/\ \ _/_/_/\/\_\_ Jean-Michel Hiver - Software Director \ \ \/*/ / [EMAIL PROTECTED]+44 (0)114 221 4968 \ \/__\/ \/\ VISIT HTTP://WWW.MKDOC.COM == / ===
RE: Apache::Registry HTTP HEAD "feature" fix ;-)
> -Original Message- > From: Jean-Michel Hiver [mailto:[EMAIL PROTECTED]] > Sent: Monday, November 26, 2001 9:18 AM > To: [EMAIL PROTECTED] > Subject: Re: Apache::Registry HTTP HEAD "feature" fix ;-) > > > > well, you should be subclassing Apache::RegistryNG instead of > > Apache::Registry - then your method calls would work :) > > Sorry, Although I'm good at OO-Perl and CGI programming, I'm really > quite new to mod_perl thus I really don't know what the I'm doing > :-) > > What is the difference between Apache::Registry and > Apache::RegistryNG ? > (a simple RTFM followed by a URI would be welcome). I believe that is in the perl.apache.org/guide > > > > personally, I'm not too keen on a core patch that comes > with "I don't > > understand why... but it works" and this approach seems kinda kludgy > > anyway... > > I totally agree, it's a horrible hack, and I'll be willing to provide > something much better when I understand what's going on and why > Apache::Registry seems to be reluctant to let its methods change ;-) > well, I just gave you a patch that worked :) basically, it only provides a solution for mod_cgi compatible scripts, but if you're using the mod_perl API then it is up to you to check $r->header_only and take appropriate action... --Geoff
Re: Apache::Registry HTTP HEAD "feature" fix ;-)
> well, you should be subclassing Apache::RegistryNG instead of > Apache::Registry - then your method calls would work :) Sorry, Although I'm good at OO-Perl and CGI programming, I'm really quite new to mod_perl thus I really don't know what the fuck I'm doing :-) What is the difference between Apache::Registry and Apache::RegistryNG ? (a simple RTFM followed by a URI would be welcome). > personally, I'm not too keen on a core patch that comes with "I don't > understand why... but it works" and this approach seems kinda kludgy > anyway... I totally agree, it's a horrible hack, and I'll be willing to provide something much better when I understand what's going on and why Apache::Registry seems to be reluctant to let its methods change ;-) Cheers, -- == \__ = /\/\ IT'S TIME FOR A DIFFERENT KIND OF WEB / /\__/\ \ _/_/_/\/\_\_ Jean-Michel Hiver - Software Director \ \ \/*/ / [EMAIL PROTECTED]+44 (0)114 221 4968 \ \/__\/ \/\ VISIT HTTP://WWW.MKDOC.COM == / ===
RE: Apache::Registry HTTP HEAD "feature" fix ;-)
> -Original Message-
> From: Jean-Michel Hiver [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, November 25, 2001 7:43 AM
> To: [EMAIL PROTECTED]
> Subject: Apache::Registry HTTP HEAD "feature" fix ;-)
>
>
> Hi guys,
>
> As promised I have been producing a fix for Apache::Registry. The
> module is called "MKDoc::Registry" because it will be integrated in
> the piece of software I'm working on, but feel free to do
> whatever you
> want with it.
>
> A slight litte issue is that I really don't understand why
> this module
> is working at all (read the code), but it's just working
> fine... could
> you please test it and tell me what's going on?
>
> PS: On my system the file is located here:
> /usr/lib/perl5/site_perl/5.6.0/i386-linux/MKDoc/Registry.pm
>
well, you should be subclassing Apache::RegistryNG instead of
Apache::Registry - then your method calls would work :)
personally, I'm not too keen on a core patch that comes with "I don't
understand why... but it works" and this approach seems kinda kludgy
anyway...
this simple patch to Apache::write_client seems to have the desired effect.
tested with both normal CGI script and mod_perl API calls.
--Geoff
--- src/modules/perl/Apache.xs Fri Sep 28 14:43:13 2001
+++ ../apache-1.3/src/modules/perl/Apache.xsMon Nov 26 08:46:04 2001
@@ -1166,7 +1166,7 @@
CODE:
RETVAL = 0;
-if (r->connection->aborted)
+if (r->connection->aborted || r->header_only)
XSRETURN_IV(0);
for(i = 1; i <= items - 1; i++) {
array's first element is empty
Hello, Not sure if this is mod_perl related, but i hope someone can help me anyway. When i do DBI queries from mod_perl handler and put all returned results in array then array's first element is empty, I wonder why? I don't like to shift off first element every time i return the result. Has anyone seen this before and what could cause this? Rgds, Viljo
RE: mod perl fails test on my Solaris 2.8 .. ?
> -Original Message- > From: Ged Haywood [mailto:[EMAIL PROTECTED]] >> Have you checked the mod_perl list archive on this one? > Whops, looked in the Guide, but forgot about the archives. I've found the answer in: http://mathforum.org/epigone/modperl/sehpholzhex/3B82C845.CA1C5818@spamless. genwax.com or using: export PERL_HTTP_URI_CLASS=URI::URL Thanks for the pointer Ged - I shall brush up on my archive searching skills. Appologies for wasted bandwidth / time. Greg > 73, > Ged. > PFIZER GLOBAL RESEARCH AND DEVELOPMENT This message and any attachment has been virus checked by the PGRD Sandwich Data Centre.
Re: [modperl-site design challenge] Thomas Klausner (domm)
> On Mon, Nov 26, 2001 at 01:36:07AM +0100, Robin Berjon wrote:
> > > * The first page ("Home") successfully validates at w3.org (HTML and CSS).
> > That's very good. Do the others validate as well (or at least, do you see any
> > reason why they wouldn't ?) ?
> On some of the deeper pages, Pod::POM generates HTML like this:
>
> text
>
>
> This isn't valid HTML (according to W3C), so those pages won't validate
> successfully.
> e.g:
> http://domm.zsi.at/modperl-site-domm/download/binaries.html
Maybe you should use HTML tidy to automagically fix broken HTML?
Another thing is that accessibility guidelines recommend using XHTML
1.1, since your HTML looks pretty clean and simple you might want to do
that instead of using old HTML 3.2.
Cheers,
--
== \__ =
/\/\ IT'S TIME FOR A DIFFERENT KIND OF WEB
/ /\__/\ \
_/_/_/\/\_\_ Jean-Michel Hiver - Software Director
\ \ \/*/ / [EMAIL PROTECTED]+44 (0)114 221 4968
\ \/__\/
\/\ VISIT HTTP://WWW.MKDOC.COM
== / ===
Re: Repost: usage of die inside a mod_perl Apache handler shows notthe expected behavior
Matt Sergeant wrote:
>
> On Mon, 26 Nov 2001, Silvio Wanka wrote:
>
> > Hi,
> >
> > I repost this, because I got no respond:
> >
> > I use the following configuration:
> >
> >
> >PerlHandlerApache::MyPkg
> >SetHandler perl-script
> >
> >
> > and the handler is defined in this way:
> >
> > package Apache::MyPkg
> >
> > require 5.005;
> >
> > require Apache::Request;
> >
> > use constant TmpDir => '/var/tmp';
> > use strict;
> >
> > sub handler ($)
> > {
> > my $apr = Apache::Request->instance(shift, TEMP_DIR => TmpDir);
> >
> > ...
> > }
> >
> > But the first which I have not expected is that $^S is always true
> > inside this handler. The other problem is that
> >
> > die "text which does not end in a newline"
> >
> > shows
> >
> > text which does not end in a newline during global destruction.\n
> >
> > instead the expected
> >
> > text which does not end in a newline at __FILE__ line __LINE__.\n
> >
> > Is this a bug in mod_perl? I use mod_perl 1.25 and Perl 5.00503. 5.6 is no
> > choice, because there is a known incompatibility of mod_perl, Perl 5.6 and
> > the platform I must use.
>
> You probably have a $SIG{__DIE__} handler somewhere installed. Try adding
> local $SIG{__DIE__}; to the top of your sub. If that doesn't work, I'm
> lost.
>
> --
>
I have already tried this, because CGI::Carp sets an own $SIG{__DIE__} handler,
but it is the same. Old versions of CGI::Carp does not use $^S to determine if
the die() was called inside an eval, and so the problem was not visible, but
the current version uses $^S and this is set.
--
Silvio
Re: Repost: usage of die inside a mod_perl Apache handler shows notthe expected behavior
On Mon, 26 Nov 2001, Silvio Wanka wrote:
> Hi,
>
> I repost this, because I got no respond:
>
> I use the following configuration:
>
>
>PerlHandlerApache::MyPkg
>SetHandler perl-script
>
>
> and the handler is defined in this way:
>
> package Apache::MyPkg
>
> require 5.005;
>
> require Apache::Request;
>
> use constant TmpDir => '/var/tmp';
> use strict;
>
> sub handler ($)
> {
> my $apr = Apache::Request->instance(shift, TEMP_DIR => TmpDir);
>
> ...
> }
>
> But the first which I have not expected is that $^S is always true
> inside this handler. The other problem is that
>
> die "text which does not end in a newline"
>
> shows
>
> text which does not end in a newline during global destruction.\n
>
> instead the expected
>
> text which does not end in a newline at __FILE__ line __LINE__.\n
>
> Is this a bug in mod_perl? I use mod_perl 1.25 and Perl 5.00503. 5.6 is no
> choice, because there is a known incompatibility of mod_perl, Perl 5.6 and
> the platform I must use.
You probably have a $SIG{__DIE__} handler somewhere installed. Try adding
local $SIG{__DIE__}; to the top of your sub. If that doesn't work, I'm
lost.
--
/||** Founder and CTO ** ** http://axkit.com/ **
//||** AxKit.com Ltd ** ** XML Application Serving **
// ||** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** mod_perl news and resources: http://take23.org **
\\//
//\\
// \\
Repost: usage of die inside a mod_perl Apache handler shows not the expected behavior
Hi,
I repost this, because I got no respond:
I use the following configuration:
PerlHandlerApache::MyPkg
SetHandler perl-script
and the handler is defined in this way:
package Apache::MyPkg
require 5.005;
require Apache::Request;
use constant TmpDir => '/var/tmp';
use strict;
sub handler ($)
{
my $apr = Apache::Request->instance(shift, TEMP_DIR => TmpDir);
...
}
But the first which I have not expected is that $^S is always true
inside this handler. The other problem is that
die "text which does not end in a newline"
shows
text which does not end in a newline during global destruction.\n
instead the expected
text which does not end in a newline at __FILE__ line __LINE__.\n
Is this a bug in mod_perl? I use mod_perl 1.25 and Perl 5.00503. 5.6 is no
choice, because there is a known incompatibility of mod_perl, Perl 5.6 and
the platform I must use.
My current work around is:
require Error;
...
sub handler ($)
{
my $apr = Apache::Request->instance(shift, TEMP_DIR => TmpDir);
local $SIG{__DIE__} = sub
{
my $txt = join '', @_;
local $Error::Depth = $Error::Depth + 1;
$txt =~ s/\s+during\s+global\s+destruction.\s*\z//;
die(Error::Simple->new($txt)->stringify);
};
...
}
TIA, Silvio
