Re: Apache::DBI disconnect?
"John S. Evans" wrote: Weird. The whole point of Apache::DBI (or so I understand it) is so that your $dbh stays valid across CGI or Handler calls. That's right. The disconnect call is a no-op when using Apache::DBI. I can only think of two reasons why I get the error message: 1) My child process is dying, and the DBI code is telling me that I never called disconnect() on that $dbh. I don't think this is the case, since the line (#119) in Apache::DBI that is referenced in the error is in the connect() call. 2) My $dbh has timed out, and Apache::DBI is attempting to reconnect. The code author decided not to perform a disconnect() because they knew the connection was already timed out. Those are both good guesses. I'd say the latter as well. One of your db handles probably failed to ping and got removed. I wouldn't worry about it. - Perrin
RE: ANNOUNCE: Apache::AuthCookie 2.007
Hi Ken, the patch I send you for overwriting the login_form seems not to be in 2.007. Are there any reason for this or did you just forget it? Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 -
mod_proxy problem
I have the following directives in my httpd.conf: ... VirtualHost _default_:8082 DocumentRoot "/app/env_control/httpd/DocumentRoot" Location "/Test" # disable mason for this location SetHandler default-handler /Location ProxyPass/Test/ http://myhost:8084/Test/ ProxyPassReverse /Test/ http://myhost:8084/Test/ ... /VirtualHost When I try to access location /Test/, I get the following error: [Tue Apr 25 08:59:34 2000] [error] [client ip address] File does not exist: proxy:http://myhost:8084/Test/CheckDeployment/GetUKLs Can anybody give me some insight as to what I am doing wrong? I am new to mod_proxy and I don't even know where to start looking. Kees Vonk
Re: [RFC] XML/Apache Templating with mod_perl
Yeah that will be really cool... can you inform me about the progress on this, if you made something ... I thought about something similar not exact but some sort of processor to handle XML(XSLT) - HTML conversations + some sort of caching tehnique, but I also like this approachsomething like this will help easy integrate XML stuff in the current scheme of producing final HTML see ya = iVAN [EMAIL PROTECTED] =
Mailing list for AXDTK
I'm thinking of starting a separate mailing list for the Apache XML Delivery Toolkit. For those who don't know, the Apache XML Delivery Toolkit now offers the core functionality of Cocoon (http://xml.apache.org/cocoon/) in mod_perl, without the proprietary extension that cocoon has implemented (because everything they've done can be achieved without any ?cocoon? processing instructions). In the near future I hope to add the following: - XSLT parsing using Xalan (once it's ported to Linux and stable) - SQL Pre-processing - Embedded Perl (already available to some extent) If there's interest in this mail me direct and I'll set something up. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
AXDTK Mailing List open!
I had a pretty good response to the offer of a mailing list for the Apache XML Delivery Toolkit - and very fast too! So before more people say yes go ahead... send a blank mail to mailto:[EMAIL PROTECTED] and join the list! -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: [OT] Lotus Domino as Web server ?
Jean-Denis Girard wrote: Hi dear modperlers, We have a client here willing to use Domino to serve his Web site. I started considering Domino a while ago. My conclusion was to flee from it. I haven't used it and these were the opinions of real programmers that used it. I'll try to recall things they told me ; - It uses a lot of CPU and RAM, if you think mod_perl eats RAM, you've never used domino. I've seen this happening in intranet with around 1000 users. They had to install alphas with NT. - It does not farming. If you install domino you'll end up having a lot of domains, one for every section of your web, each one in a server. Your users will go crazy searching dead links and asking you what server holds now the pages they were using. Because you'll start moving databases to a new server as soon as the older started die of resources. - Amazing lack of features, the API to the web server maybe exists but no developer I talked to knew nothing about sending headers, internal redirects and so. I was comparing to mod_perl, and HTML::Mason, the dhandler and autohander stuff was very important for me and I wanted something like this. I didn't find it. - It does not SQL, building an application for the web with domino takes a big effort of analising, programming and maintaining. A thing that would be very easy with a SQL database can be very hard or impossible to do with domino. I was told is hard to feed such a database from 3rd party data. And if you must add more data again to domino is harder again. - It's impossible to separate content from formatting. - You don't embed a language in HTML, you ask domino about inserting html inside your code. My conclusion was it's no good for web programming. I went to a super human software lotus show and it was very disapointing, a lot of vapourware. I thought it must be very bad when they admitted nested tables didn't work at all in domino 4.x, and started working at 5.0. In addition I must say mod_perl has a lot of features never dreamed by people that use Domino or IIS+ASP. I have asked to other programmers friends of mine who use these platforms, no one uses mod_perl and they think their tools are far better than mine and easier to use. I quit advocacing mod_perl. For every feature they lack, they have work arounds or don't use it. -- - frankie -
-DPERL_NO_GET_CONTEXT horks everything
Building Perl 5.6 with -DPERL_NO_GET_CONTEXT breaks just about every program that uses the Perl C API. DBI, Storable mod_include, and mod_perl 1.23 are all unable to compile with this build flag. Bummer. I skimmed perldelta and perlguts to see what was what. It was pretty easy to fix Storable by adding dTHX wherever the compiler complained about my_perl being undefined. But the way I read perlguts, couldn't we build perl without -DPERL_NO_GET_CONTEXT and just #define it in the mod_perl 2.0 sources? That way, we could have an efficient mod_perl, but not have to hack on every module in CPAN. I think. -jwb
Re: [RFC] XML/Apache Templating with mod_perl
According to Matt Sergeant: In case you missed it - I just announce the Apache XML Delivery Toolkit to both the modperl list and the Perl-XML list. With it you can develop an XSLT Apache module in 13 lines of code (no caching, but it works). I saw it, but perhaps misinterpreted the 'not' in the xslt package. Is this intended to be fairly compatible with IIS's 'TransformNode' handling of xml/xsl (i.e. can I use the same xsl files)? Les Mikesell [EMAIL PROTECTED]
Re: [RFC] XML/Apache Templating with mod_perl
On Tue, 25 Apr 2000, Leslie Mikesell wrote: According to Matt Sergeant: In case you missed it - I just announce the Apache XML Delivery Toolkit to both the modperl list and the Perl-XML list. With it you can develop an XSLT Apache module in 13 lines of code (no caching, but it works). I saw it, but perhaps misinterpreted the 'not' in the xslt package. Is this intended to be fairly compatible with IIS's 'TransformNode' handling of xml/xsl (i.e. can I use the same xsl files)? No. It's definitely Not XSLT compatible. Sorry if it wasn't clear. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: -DPERL_NO_GET_CONTEXT horks everything
i hate to see you suffer this pain, when the proper fix was posted to p5p on friday (see patches/no_get_context.pat) and modperl-2.0/00README_FIRST no longer suggests building Perl with -DPERL_NO_GET_CONTEXT "cvs up early, cvs up often"
Re: -DPERL_NO_GET_CONTEXT horks everything
On Tue, 25 Apr 2000, Doug MacEachern wrote: "cvs up early, cvs up often" word
Re: mod_proxy problem
| VirtualHost _default_:8082 |DocumentRoot "/app/env_control/httpd/DocumentRoot" |Location "/Test" | # disable mason for this location | SetHandler default-handler |/Location |ProxyPass/Test/ http://myhost:8084/Test/ |ProxyPassReverse /Test/ http://myhost:8084/Test/ | /VirtualHost | | When I try to access location /Test/, I get the following | error: | | [Tue Apr 25 08:59:34 2000] [error] [client ip address] File | does not exist: | proxy:http://myhost:8084/Test/CheckDeployment/GetUKLs | | Can anybody give me some insight as to what I am doing wrong? | I am new to mod_proxy and I don't even know where to start | looking. Show us your VirtualHost blablabla:8084 (the destination in this proxy config), a "ls -l" of /app/env_control/httpd/DocumentRoot/Test/CheckDeployment and a "host myhost". Ime I am running on HP-UX 10.20, there does not seem to be 'host' command. myhost:8084 is my development server (runs on the same box), here is a copy of the httpd.conf (myhost:8082 is SSL enabled, 8084 is not, I don't know if that makes a difference). Also attached the requested ls -l. ServerType standalone ServerRoot "/opt/perl5/apache" PidFile /var/iefadmn/apache/8084/logs/httpd.pid ScoreBoardFile /var/iefadmn/apache/8084/logs/httpd.scoreboard Timeout 300 KeepAlive On MaxKeepAliveRequests 100 KeepAliveTimeout 15 MinSpareServers 3 MaxSpareServers 5 StartServers 3 MaxClients 8 MaxRequestsPerChild 10 ClearModuleList AddModule mod_env.c AddModule mod_log_config.c AddModule mod_mime.c AddModule mod_alias.c AddModule mod_access.c AddModule mod_auth.c AddModule mod_so.c AddModule mod_setenvif.c AddModule mod_perl.c Port 8084 User intranet Group users ServerName myhost Directory / AllowOverride None PerlInitHandler Apache::StatINC Order allow,deny Deny from all /Directory PerlSetVar ServerAlias myhost PerlAccessHandler Intranet::Alias UseCanonicalName On HostnameLookups Off ServerSignature On TypesConfig /opt/perl5/apache/conf/8084/mime.types LogFormat "%h %l %u %t \"%r\" %s %b" common ErrorLog /var/iefadmn/apache/8084/logs/error_log LogLevel warn CustomLog /var/iefadmn/apache/8084/logs/access_log common SetEnv RC_FILE /app/env_control/repdata/iefit.rc PassEnv ORACLE_HOME PerlPassEnv ORACLE_HOME PerlRequire /opt/perl5/apache/conf/8084/startup.pl DocumentRoot "/app/env_control/httpd/DocumentRoot" Directory "/app/env_control/httpd" Options FollowSymLinks AllowOverride None Order allow,deny Allow from all AuthType Basic AuthName "Environment Support and Projects (testing)" PerlAuthenHandler RCM::Authenticate PerlAuthzHandler RCM::Authorise AuthAuthoritative on require role TEST01 TSTAU1 /Directory Alias /icons/ "/var/iefadmn/apache/icons/" Alias /images/ "/var/iefadmn/apache/images/" Directory /var/iefadmn/apache/icons Order allow,deny Allow from all /Directory Directory /var/iefadmn/apache/images Order allow,deny Allow from all /Directory PerlRequire /opt/perl5/apache/conf/8084/handler.pl DefaultType text/html Location / SetHandler perl-script PerlHandler HTML::Mason /Location LocationMatch mod_ssl:[^:]+: SetHandler perl-script PerlHandler Intranet::mod_ssl_error /LocationMatch Alias /Images /app/env_control/httpd/Components/Images Location /Images Order allow,deny Allow from all SetHandler perl-script PerlHandler HTML::Mason /Location AddEncoding x-compress Z AddEncoding x-gzip gz BrowserMatch "Mozilla/2" nokeepalive BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0 BrowserMatch "RealPlayer 4\.0" force-response-1.0 BrowserMatch "Java/1\.0" force-response-1.0 BrowserMatch "JDK/1\.0" force-response-1.0 Alias /Errors /app/env_control/httpd/Errors Location /Errors Order allow,deny Allow from all SetHandler perl-script PerlHandler HTML::Mason /Location ErrorDocument 403 /Errors/NotAuthorised ErrorDocument 404 /Errors/NotFound --- ls -l /app/env_control/httpd/DocumentRoot/Test/CheckDeployment total 8 -rw-r--r-- 1 iefit dba 3176 Apr 12 13:28 GetUKLs
Re: Apache::DBI disconnect?
On Mon, 24 Apr 2000, John S. Evans wrote: Weird. The whole point of Apache::DBI (or so I understand it) is so that your $dbh stays valid across CGI or Handler calls. Sure. But it does it magically. You're still supposed to call disconnect. That way, your code will also work without Apache::DBI. -- -- Tom Mornini -- InfoMania Printing and Prepress
Re: Deep recursion on subroutine Apache::Constants::AUTOLOAD
On Fri, 21 Apr 2000, Martin Lichtin wrote: Anyone understand why perl -we 'use Apache::Constants; Apache::Constants::OK();' causes this problem? what version of mod_perl are you using? from the command line you should get this error: % perl -we 'use Apache::Constants; Apache::Constants::OK();' Undefined subroutine Apache::Constants::OK called at -e line 1. you can't use Apache::Constants outside of httpd.
Re: PerlHandler stopped working???
On Sat, 22 Apr 2000, Matt Sergeant wrote: On Sat, 22 Apr 2000, Matt Sergeant wrote: The only thing I can think of, is that Apache::MimeXML is somehow stopping the PerlHandler phase from being executed. Can it do that (but still allow the PerlFixupHandler phase to execute)??? OK, it was Apache::MimeXML... Which is very odd indeed. A bug in mod_perl by the looks of things. All I'm returning from Apache::MimeXML, btw, is OK or DECLINED. It was returning OK when PerlHandler stopped working. For now I'll disable it, and set Mime types manually for .xml files - but something is seriously not right there. as i already explained to matt in another email, if a TypeHandler returns OK, then mod_mime's type handler is not called. which means that SetHandler, AddType, etc., for that require will be ignored, unless you return DECLINED or implement them yourself (see Apache::MIME in ch8 of the eagle book)
Re: httpd could not be started
On Sat, 22 Apr 2000 [EMAIL PROTECTED] wrote: I am trying to build httpd using DSO and mod_perl, mod_ssl and mod_php (but that one hasn't come up yet) I'm on an unpatched RedHat 6.1 with a newly built 5.6.0 perl (egcs 2.91.66) with mod_perl from CVS and mod_ssl-2.6.3-1.3.12 for apache_1.3.12 what version of mod_perl are you using? did 'make test' pass? the server might be core dumping, if you could follow the hints in the SUPPORT doc for getting a stacktrace, we should be able to figure out why.
Re: httpd could not be started
On Sat, 22 Apr 2000 [EMAIL PROTECTED] wrote: It's a much simpler problem than I let on to before... (thanks matt@telepath) whoops, disregard my last message then. The error log shows what went wrong, but I am at a bit of a loss on how to correct it. [info] mod_unique_id: using ip addr my.valid.ip.address getpeername: Socket operation on non-socket getsockname: Socket operation on non-socket Error getting local address hostname returns the correct answer. I put "my.ip.x.x localhost" into /etc/hosts inetd is running, but all /etc/inetd.conf programs are commented out. I'm getting my IP from DHCP, but it is constant until midnight. you should use the loopback address for localhost: 127.0.0.1 localhost
Re: End failed -- Cleanup aborted and other errors
On Sat, 22 Apr 2000, Gagan Prakash wrote: Hi, We are in the process of moving our site www.adalbadal.com from the web hosting company in India to iserver -- they do have mod_perl!!! Well during this process, some of our scripts are giving us: END failed--cleanup aborted at /dev/null line 6. Callback called exit at /dev/null line 6. and an occassional Out of memory! This server has Apache 1.3.11 Mod_perl 1.21 might want to try 1.23. do this script have END blocks? if so, what are they doing?
Re: Deep recursion on subroutine Apache::Constants::AUTOLOAD
Doug MacEachern wrote: Anyone understand why perl -we 'use Apache::Constants; Apache::Constants::OK();' causes this problem? what version of mod_perl are you using? ' mod_perl 1.21, perl 5.00503
Re: vanilla install failure 1.3.12/1.22/5.6.0
On Sun, 23 Apr 2000 [EMAIL PROTECTED] wrote: Program received signal SIGSEGV, Segmentation fault. 0x806412e in perl_handler (r=0x8727d9c) at mod_perl.c:844 844 dPPREQ; seems the common element in both of these reports is ssl. i'll build a mod_perl+mod_ssl mix, so long as i can reproduce the problem, i'll have a patch soon..
Re: PerlHandler stopped working???
On Tue, 25 Apr 2000, Doug MacEachern wrote:
On Sat, 22 Apr 2000, Matt Sergeant wrote:
On Sat, 22 Apr 2000, Matt Sergeant wrote:
The only thing I can think of, is that Apache::MimeXML is somehow stopping
the PerlHandler phase from being executed. Can it do that (but still allow
the PerlFixupHandler phase to execute)???
OK, it was Apache::MimeXML... Which is very odd indeed. A bug in mod_perl
by the looks of things. All I'm returning from Apache::MimeXML, btw, is
OK or DECLINED. It was returning OK when PerlHandler stopped working. For
now I'll disable it, and set Mime types manually for .xml files - but
something is seriously not right there.
as i already explained to matt in another email, if a TypeHandler returns
OK, then mod_mime's type handler is not called. which means that
SetHandler, AddType, etc., for that require will be ignored, unless you
return DECLINED or implement them yourself (see Apache::MIME in ch8 of
the eagle book)
OK, I'm looking at that now, and I realise you're just passing it straight
through to apache to do the right thing, but I think it's the wrong
thing... Hear me out.
Apache::MimeXML, like most non-PerlHandler handlers, is not designed as a
replacement for mod_mime, but to build on it. If I detect something as
XML, I'd like to say "OK, I'm done with this phase, let the next
continue". Likewise if I don't want to handle this phase (i.e. I want
mod_mime to do its thang) I return DECLINED. I don't want a MIME handler
that's supposed to add to mod_mime to change the fact that I have a
PerlHandler setup. In order to build Apache::MimeXML properly, I'd have to
build an entire replacement for mod_mime, in XS, parsing the configuration
for SetHandler, and I don't want to do that.
I guess the problem is that mod_mime implements SetHandler - and I'm not
convinced it should. If you were given the opportunity to do it all again
I'd suggest it be done as follows:
If a PerlTypeHandler returns OK, check if
@{$r-get_handlers('PerlHandler')} is true (i.e. there's a PerlHandler
waiting in the wings). If so, call $r-handler('perl-script').
If a PerlTypeHandler returns DECLINED, do it as you do now.
That should be backwards compatible with most code, I think. And not
interfere with things already setup in peoples httpd.conf/htaccess
files. Alternatively have the OK case remain the same, and have a new
return value (DONE?) that signfies to do the SetHandler part of mod_mime.
Convince me I'm thinking wrong, then I can get back to some real work ;-)
--
Matt/
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org
RE: Unknown Error Message
On Mon, 24 Apr 2000, Ian Mahuron wrote: I get something similar when I wrap my call to Apache::Session::DBI in an eval to try to catch it die()ing (ie. session id not found). IIRC, this is a known bug in perl. right, which is fixed in 5.6.0 panic: POPSTACK Callback called exit.
Re: segfault in DSO mod_perl 1.23 (perl 5.6.0) with apache-1.3.12
Doug MacEachern [EMAIL PROTECTED] writes: On 22 Apr 2000, Michael Poole wrote: I get a segfault on the first page access to Apache (it's just a request for / on the server). Backtrace: ... That line of mod_perl.c is "dPPDIR;" However, r-per_dir_config is NULL, so the get_module_config() call there ends up dereferencing a NULL pointer to generate the SEGV. that's stange. what options did you give mod_perl's Makefile.PL? did mod_perl's 'make test' pass? what request is the server handling when this happens? perl Makefile.PL USE_APXS=1 WITH_APXS=/usr/local/sbin/apxs EVERYTHING=1 'make test' refused to run since it was using APXS The server was handling "GET / HTTP/1.0" at the time (the first request made to the server). My "solution" to this point (suggested by Dave Mee) is to just use APACI to link mod_perl statically into Apache. It's worked perfectly so far, although it is a bit kludgy. Michael
RE: [RFC] XML/Apache Templating with mod_perl
Yeah that will be really cool... can you inform me about the progress on this, if you made something ... I thought about something similar not exact but some sort of processor to handle XML(XSLT) - HTML conversations + some sort of caching tehnique, but I also like this approachsomething like this will help easy integrate XML stuff in the current scheme of producing final HTML Embperl 2.0 will be able to do such things, but it's a long way to go and will take some time until I have implemented this... Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 -
Re: PerlHandler stopped working???
I guess the problem is that mod_mime implements SetHandler - and I'm not
convinced it should. If you were given the opportunity to do it all again
understood, but this is how apache is designed, mod_perl is just going
with the flow here.
I'd suggest it be done as follows:
If a PerlTypeHandler returns OK, check if
@{$r-get_handlers('PerlHandler')} is true (i.e. there's a PerlHandler
waiting in the wings). If so, call $r-handler('perl-script').
so why not just do that in your PerlTypeHandler? i don't think it's right
for mod_perl to have that logic hardwired in. the other solution, is to
let mod_mime do it's thang in the type phase, and do your thang in the
fixup phase to override anything mod_mime did that you don't want.
Re: segfault in DSO mod_perl 1.23 (perl 5.6.0) with apache-1.3.12
perl Makefile.PL USE_APXS=1 WITH_APXS=/usr/local/sbin/apxs EVERYTHING=1 probably a long shot, but any difference if you build with USE_DSO=1 instead of USE_APXS ?
Apache XML Delivery Toolkit
I thought I'd just post here what I sent to the axdtk list, in case there
are people here who don't know what the heck I'm talking about... If this
perks your interest, send a mail to [EMAIL PROTECTED], download
the toolkit, and start asking questions...
What is the AXDTK?
It's a system very much like Cocoon (http://xml.apache.org/cocoon/), but
based on mod_perl. The idea is to allow a few things:
- Stylesheets and XML files get associated automatically using the w3c
semantics (http://www.w3.org/TR/xml-stylesheet).
- Pre and Post processing can be performed using mod_perl stacked
handlers.
- Output is cached automatically if the underlying system uses DOM,
otherwise the stylesheet processor developer has to implement caching
himself, however the hooks are provided for this.
- Stylesheets can cascade if based on DOM trees.
For those unfamiliar with Cocoon, here's what happens:
1. A request comes in for an XML file.
2. If someone has installed a stacked handler prior to
Apache::XMLStylesheet, that handler is called. One idea for such handlers
is to extract a media type by browser sniffing (e.g. sets the media to
"handheld"). Another idea is to take a preferred style from the
querystring such as "style=no%20images".
3. Apache::XMLStylesheet checks its cache for a matching set of combined
parameters (file, style, media). If the cache says that the XML file is
older than the cache, use the list of stylesheets in the cache. If the
cache is older than the file, parse the file for the xml-stylesheet
processing instructions.
4. Check all the stylesheets exist.
5. If all the stylesheets exist, check the difference in timestamps
between the xml file and all the stylesheet files, and the output cache
file. If any are newer than the output cache file, then we re-run all the
styles against the xml file. If they're all older we stop there, set the
filename to the cached file, and return DECLINED. Apache obliges and
returns the cached file to the browser for us.
6. If we re-create, we have mark off stylesheet type mappings against
modules or functions. That is, the type="..." attribute in the stylesheet
processing instruction gives us a pointer as to what module to use to
process that stylesheet (based on some info in your httpd.conf file). We
load that module and execute the function, passing in the stylesheet and
the xml filename as parameters.
7. Modules based on the DOM can use the mod_perl API to set the
$r-pnotes('dom_tree') value when they're done, rather than printing out
the results. This is how the caching works, and how cascading
works. Modules that aren't based on the DOM can't cascade... yet.
8. The resulting DOM tree is printed out both to the cache file and to the
browser. The DOM tree is disposed of.
That, in a nutshell, is it. Currently it's a work in progress. Today I
hope to finish the version that does all the caching work and cascading
stylesheets.
If anyone wants to volunteer to help, here's what I consider needs done:
- A cool web page ;-)
- Get Xalan/Xerces working on Unix. This is pretty vital to the success,
IMHO. See http://xml.apache.org/
- Write modules that plugin to this architecture that perform the
following functionality:
- SQL plugin using DBI. Should take an XML file (or DOM tree), parse
out connection information and run the SQL. Produce another DOM tree and
put that DOM tree in $r-pnotes('dom_tree')
- Implement other stylesheet processors, like XPathScript and NotXSLT
- Get the word out! Perl must not be behind in the XML world for much
longer!
Download AXDTK at http://xml.sergeant.org/download/
It's not well organised right now. The key component is
Apache::XMLStylesheet. To use that you need XML::Parser and
Apache::MimeXML(0.05). The only plugins available are Apache::XPathScript
and Apache::XPath::NotXSLT, and an XSLT plugin that's in the list
archive.
--
Matt/
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org
Re: PerlHandler stopped working???
On Tue, 25 Apr 2000, Doug MacEachern wrote:
I guess the problem is that mod_mime implements SetHandler - and I'm not
convinced it should. If you were given the opportunity to do it all again
understood, but this is how apache is designed, mod_perl is just going
with the flow here.
I'd suggest it be done as follows:
If a PerlTypeHandler returns OK, check if
@{$r-get_handlers('PerlHandler')} is true (i.e. there's a PerlHandler
waiting in the wings). If so, call $r-handler('perl-script').
so why not just do that in your PerlTypeHandler?
I do now - just uploaded a new version. It's still not correct though - a
proper fix would have to pull SetHandler out of mod_mime altogether, I
guess. For example, say your config contains:
# PerlTypeHandler blah
SetHandler perl-script
PerlFixupHandler foo
And in foo::handler() you call $r-push_handler('perl-script'). Suddenly
it stops working when you uncomment the PerlTypeHandler there.
I guess one important question is - why do we have to call SetHandler for
PerlHandlers and not for any of the other handler phases. For all the
other phases Apache/mod_perl automatically figures out if there's a
handler installed and either runs perl code, or lets apache do its
work. Why can't PerlHandler do the same? (as you can tell - I haven't dug
into the internals of this - but I am curious).
i don't think it's right
for mod_perl to have that logic hardwired in. the other solution, is to
let mod_mime do it's thang in the type phase, and do your thang in the
fixup phase to override anything mod_mime did that you don't want.
Right. So what's the point of PerlTypeHandler again?... ;-) Seriously
though - Apache::MimeXML is the only PerlTypeHandler, as far as a quick
search reveals, apart from your examples in the book. So maybe it would be
worth investigating this further.
A fixup handler is an interesting solution... but can I stack
FixupHandlers? (I run most of my mod_perl code from a FixupHandler).
Also, you didn't pick up on something I sent to the list in another
thread... I have code that goes:
if ($r-current_callback eq 'PerlFixupHandler') {
$r-push_handlers('PerlHandler', \code);
}
else {
code($r);
}
so that I can install the module as either a fixup or a PerlHandler. The
fixup installed version is 4 times slower than calling the function
directly - is that to be expected? (we're talking 20 requests/sec vs 80
here - a huge difference).
--
Matt/
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org
Re: Deep recursion on subroutine Apache::Constants::AUTOLOAD
At 12:59 4/25/00 -0600, Martin Lichtin wrote:
Doug MacEachern wrote:
Anyone understand why
perl -we 'use Apache::Constants; Apache::Constants::OK();'
causes this problem?
what version of mod_perl are you using? '
mod_perl 1.21, perl 5.00503
This reminds me of a problem that we had under mod_perl: I'm not sure it
exists in later versions, and if this has anything to do with your problem.
Just in case it might help you, here is how this would go:
package MyPackage::SubModule;
sub new { my $self = {}; bless $self; $self }
package MyPackage;
sub new { my $self = {}; bless $self; $self }
sub SubModule { MyPackage::SubModule-new( @_ ) }
^ ^
For some reason with _some_ combinations of Perl and mod_perl, the
following code would recurse infinitely and cause the "Deep recursion"
error message:
$mypackage = new MyPackage;
$submodule = $mypackage-SubModule( @parameters );
However, if you would write SubModule like this:
sub SubModule { 'MyPackage::SubModule'-new( @_ ) }
^^
there was no problem. This would indicate to me that there is some kind of
compile-time optimization in the version of Perl/mod_perl that incorrectly
assumes that "MyPackage::SubModule" is a subroutine reference, where in
fact it is a class reference. By putting the class reference between
single quotes, the optimization is apparently by-passed and the problem
disappeared.
Hope this helps.
Elizabeth Mattijsen
Integra Netherlands
Re: PerlHandler stopped working???
"Matt" == Matt Sergeant [EMAIL PROTECTED] writes: Matt I guess one important question is - why do we have to call SetHandler for Matt PerlHandlers and not for any of the other handler phases. For all the Matt other phases Apache/mod_perl automatically figures out if there's a Matt handler installed and either runs perl code, or lets apache do its Matt work. Why can't PerlHandler do the same? (as you can tell - I haven't dug Matt into the internals of this - but I am curious). I've been pondering this for quite some time, and was considering a "magic mime type" that I'd deal with in the fixup handler... if the MIME type assigned by mod_mime or anything else in the mime phase is "text/html;PerlHandler=Apache::Registry", then the generic fixup handler would patch that to "text/html" and push a PerlHandler of Apache::Registry. That way you could do this: files *.html SetType text/html;PerlHandler=HTML::Mason /files files *.pl SetType text/plain;PerlHandler=Apache::Registry /files files static/*.html SetType text/html /files Syntax is probably off... but I think you can see where I'm going with this. Bring the MIME type to mean both the "real" mime type as well as a PerlHandler if needed. I'm sure it's a 15 line FixupHandler... just haven't had time to tear down part of my site to test. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
write a filefrom a navigator
Hello, I'm a little perl developper, in a little french enterprise, (hexaflux). I make my period of training and I use an apache server 1.3x. I've got some problem with my server. It does not allow me to execute system commands in perl : "system (chmod 755 file.pl)" and "open (MYFILE, file.pl ". I f I execute my script by executing the following command : /usr/bin/perl /home/httpd/cgi-bin/script.pl, the file, "file.pl" is created and file.pl has the good permissions and it works! But if it is executed from the navigator it doesn't works!! I think that the permisions on the server are not good. But I don't know where to change the configuration of my server, access.conf, httpd.conf, srm.conf ? Can you help me, thank you. benoit PS: sorry for my poor english speaking!
newbie help installation problems modperl/apache
I am trying to use mod_perl with apache (1.22 1.3.12, respectively). I am having a multitude of problems, and cannot get hello world even working. I have loaded down installed a bunch of cpan modules to support this (libwww-perl prerequisites. this solved some things). as per the mod_perl INSTALL.apaci, I configure mod_perl for later apache building. (Everything=1, apaci=1, etc), because of issue 1. when configuring, I get a whole bunch of apxs warnings saying that it cannot find /usr/sbin/httpd. (this module is not here, this is not where it will be). it then warns me about mod_so, which I know I have compiled in, because of other parms that I use with apache. is this a problem? (i can make make install). how do I tell mod_perl where the httpd module with be? issue 2. If I build apache, I can start it, run it, do all the other things I do with it. If I shut it down, and go back to mod_perl's make test, it blows chunks. It fails with a syntax error on line 80 of t/conf/httpd.conf. Invalid command 'Alias'. Does this tell me anything about what is wrong? The odd thing is that in my "normal" apache config, I have about 80 name virtual servers, and I specifically load mod_alias similar modules. issue 3. apache is configured with --activate-module=src/modules/perl/libperl.a (as per the INSTALL.apaci). However, there is no such file. there are number of items in this directory, includign libperl.module the configuration, make, make install steps do not have any errors however. issue 4. It doesnt work. using the writing apache modules with perl c book, I tried to use a "PerlSetEnv" command. (p.28) configtest says this is okay, but apache crashes upon starting. If i try to define a location (p.31), configtest gives me a syntax error on 'PerlHandler'. Ultimately, this tells me that something isnt right. jr john riehl ibucks, inc.
Re: 2.0 wishlist: consistent API and docs
On Tue, 25 Apr 2000, Jeffrey W. Baker wrote: I wish for a consistent API and documentation in the upcoming mod_perl 2.0 implementation. For example, right now, we have several different ways to tweak outgoing response headers. Some headers have their own method ($r-content_type), while others are aggregated ($r-header_out). Some of the ones that have their own accessor have slightly tweaked method names ($r-set_content_length). Worse, the documentation conflicts with the implementation. perldoc Apache says "You should not define any 'Content-XXX' headers by calling [header_out], because these headers use their own specific methods." However, there is no method content_length, you either have to set it using header_out, or use Apache::File and get set_content_length. The origin of these inconsistencies has, I think, been the years-long development of both mod_perl and Apache 1.x. Some headers may have their own accessors because they need to tweak something in the Apache core when they get set. Regardless, I propose a more consistent API for mod_perl 2.0. When setting an outbound header, I would prefer to use all method calls. I would also be fine with using a generic method like $r-header_out. However, I think that accessor method interface is preferrable because it lets us plug in funky logic that may be needed when a header is set. The header_out interface can have that too, but only if it switches on the hash key, in which case it is just identical to but slower than the accessor method interface. That's my two cents. Since I'm bitching about it, I volunteer to help be the interface and documentation police for 2.0 I'm with you, as long as you can do: PerlModule Apache::BackwardsCompatible -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: 2.0 wishlist: consistent API and docs
On Tue, 25 Apr 2000, Matt Sergeant wrote: On Tue, 25 Apr 2000, Jeffrey W. Baker wrote: I wish for a consistent API and documentation in the upcoming mod_perl 2.0 implementation. For example, right now, we have several different ways to tweak outgoing response headers. Some headers have their own method ($r-content_type), while others are aggregated ($r-header_out). Some of the ones that have their own accessor have slightly tweaked method names ($r-set_content_length). Worse, the documentation conflicts with the implementation. perldoc Apache says "You should not define any 'Content-XXX' headers by calling [header_out], because these headers use their own specific methods." However, there is no method content_length, you either have to set it using header_out, or use Apache::File and get set_content_length. The origin of these inconsistencies has, I think, been the years-long development of both mod_perl and Apache 1.x. Some headers may have their own accessors because they need to tweak something in the Apache core when they get set. Regardless, I propose a more consistent API for mod_perl 2.0. When setting an outbound header, I would prefer to use all method calls. I would also be fine with using a generic method like $r-header_out. However, I think that accessor method interface is preferrable because it lets us plug in funky logic that may be needed when a header is set. The header_out interface can have that too, but only if it switches on the hash key, in which case it is just identical to but slower than the accessor method interface. That's my two cents. Since I'm bitching about it, I volunteer to help be the interface and documentation police for 2.0 I'm with you, as long as you can do: PerlModule Apache::BackwardsCompatible I agree.
Re: write a filefrom a navigator
benoit bordigoni wrote: Hello, I'm a little perl developper, in a little french enterprise, (hexaflux). I make my period of training and I use an apache server 1.3x. I've got some problem with my server. It does not allow me to execute system commands in perl : "system (chmod 755 file.pl)" and "open (MYFILE, file.pl ". I f I execute my script by executing the following command : /usr/bin/perl /home/httpd/cgi-bin/script.pl, the file, "file.pl" is created and file.pl has the good permissions and it works! But if it is executed from the navigator it doesn't works!! I think that the permisions on the server are not good. Based on the snippet you posted, you would want to make sure that /home/httpd/cgi-bin/script.pl is writable by whatever user the seb server runs as (usually nobody). Be warned that you have to be careful with world writable directories! Hope this helps. On a unix box you would type the following (based on your example): chmod o+w /home/httpd/cgi-bin -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: PerlHandler stopped working???
I do now - just uploaded a new version. It's still not correct though - a
proper fix would have to pull SetHandler out of mod_mime altogether, I
you'd still have the same problem, Apache stops calling type handlers
after the first one returns OK. besides, you can apply the SetHandler
config in your TypeHandler by using a subrequest, no need to pull it out
of mod_mime.
I guess one important question is - why do we have to call SetHandler for
PerlHandlers and not for any of the other handler phases. For all the
other phases Apache/mod_perl automatically figures out if there's a
handler installed and either runs perl code, or lets apache do its
work. Why can't PerlHandler do the same? (as you can tell - I haven't dug
into the internals of this - but I am curious).
because Apache dispatches response handlers based on the modules'
handler_rec (part of the module structure). the key Apache uses to do
that lookup is r-handler, which if NULL, falls back to r-content_type.
Right. So what's the point of PerlTypeHandler again?... ;-) Seriously
though - Apache::MimeXML is the only PerlTypeHandler, as far as a quick
search reveals, apart from your examples in the book. So maybe it would be
worth investigating this further.
there's nothing to investigate, Apache is working as it is designed.
if you feel this is a design flaw, the the issue should be raise on
[EMAIL PROTECTED] list.
as i mentioned above, alternative to the FixupHandler workaround, if your
TypeHandler wants to let mod_mime contribute, it can run a subrequest and
copy the $subr-{handler,content_type} as you see fit.
A fixup handler is an interesting solution... but can I stack
FixupHandlers? (I run most of my mod_perl code from a FixupHandler).
yes.
Also, you didn't pick up on something I sent to the list in another
thread... I have code that goes:
if ($r-current_callback eq 'PerlFixupHandler') {
$r-push_handlers('PerlHandler', \code);
}
else {
code($r);
}
so that I can install the module as either a fixup or a PerlHandler. The
fixup installed version is 4 times slower than calling the function
directly - is that to be expected? (we're talking 20 requests/sec vs 80
here - a huge difference).
i wouldn't expect that much of a difference. i'll look into it.
Re: $r-get_handlers bug/oversight?
On Tue, 25 Apr 2000, Geoffrey Young wrote:
Hi all...
I've noticed that get_handlers() will return the enabled handlers
for a PerlPostReadRequestHandler, but not when it is specified as a
PerlInitHandler (either by calling
$r-get_handlers('PerlPostReadRequestHandler') or
$r-get_handlers('PerlInitHandler'). It is the same with
PerlHeaderParserHandler. An oversight?
Also, I can't get anything for PerlCleanupHandlers, which kinda
makes sense, since Cleanup isn't really a phase, per se (at least according
to the book). Does it make sense to add this to get_handlers() as well?
oversight. neither CleanupHandler nor InitHandlers is in the
handler_table in Apache.xs. probably because those directives were added
after get/set handlers was implemented, and the table was never updated.
i'll see about fixing that.
Re: Passing POST Data to a SubRequest
On Thu, 20 Apr 2000, Chris D'Annunzio wrote: Is there a way to pass data into a SubRequest using the post method? no, you'll need to use GET and $r-args which can be made transparent with the module below, provided your code can deal with post POST and GET requests. That works great if the Content-Type of the POST is application/x-www-form-urlencoded. Is there a way to deal with other Content-Types like multipart/form-data? for something like that, you'd be better off using the $r-pnotes table to pass a CGI.pm or Apache::Request object to the subrequest. Apache::RequestNotes on cpan might be useful to you.
Re: [RFC] Transitioning from Apache::Registry to Apache handlers
On 20 Apr 2000, Randal L. Schwartz wrote: "Doug" == Doug MacEachern [EMAIL PROTECTED] writes: Doug why all the globals?? symbol table lookups are much slower than Doug lexicals. If I recall, the word lately is that they're much closer than they were. i take it back, the symbol table lookups for globals are done at compile time, 5.x has always done that, i think. by the looks of: perl -MO=Terse -e 'my $lex = 1; our $ogv = 1; $gv = 1' they still behave the same at runtime, though what happens during compile time might be different. But lexicals are still "cleaner", if I recall. indeed.
Re: mod_perl-1.99_01-dev
On Fri, 21 Apr 2000, Greg Cope wrote:
Does this mean that we {will|may} be able to use the interpreter pool to
set up X Perl interpreters (say 20 to service dynamic handlers) with Z
apache (say 60 to handle static + dynamic content - assuming the dynamic
content is passed to the Perl interpreters) children, and hence have
significant memory savings as we can avoid (in some cases) the light / heavy
httpd model ?
yes, exactly.
Re: mod_perl 2.x/perl 5.6.x ?
On Sat, 22 Apr 2000, Leslie Mikesell wrote: So, does that still leave mod_perl serializing access until everything is rewritten to be thread-safe? no, -Dusethreads with 5.6.0 makes the Perl runtime (aka PerlInterpreter), re-entrant. all of Perl's internal globals (symbol table, stacks, etc.) become part of the PerlInterpreter structure, each interpreter clone has it's own copy of any writeable data (symbol table, stacks, etc.) the syntax tree is shared. this makes it possible to concurrently call subroutines in different threads, which was not possible with 5.005_03. this doesn't solve the problem of xs modules or c libraries that are not thread-safe, we'll have to fix any trouble makers as they pop up.
RE: mod_perl 2.x/perl 5.6.x ?
On Sun, 23 Apr 2000, Gunther Birznieks wrote: I agree... but to some degree I hope this has been done for many of the major modules and the major DBI modules (eg DBD sybase)... as they ended up having to work on ActiveState's PerlEx which uses a similar model. In a way, PerlEx's model has been a test for mod_perl 2.0. indeed. PerlEx uses PERL_OBJECT, which is similar in concept to USE_ITHREADS. we all owe a great deal of thanks to ActiveState for sponsoring Gurusamy Sarathy's work on 5.6.0. without the USE_ITHREADS implementation, mod_perl would be next to useless with threaded apache-2.0
RE: mod_perl 2.x/perl 5.6.x ?
On Sat, 22 Apr 2000, Eric Cholet wrote:
mod_perl-2.0 requires perl 5.6 to be build with -Dusethreads, which turns
on threading and multiplicity.
just to be clear, as you mention below, -Dusetheads isn't required for
mod_perl-2.0, but strongly suggested if you use an mpm other than prefork :)
and i wouldn't say -Dusethreads "turns on threading", it simply makes the
Perl runtime re-entrant (as explained in an earlier message)
The biggest hurdle I've faced until now is
that DBI won't build with this threaded perl. Hopefully DBI will be updated
since the latest version is from july 99.
it compiles with the patch below, not sure if it actually works though :)
This is for using Apache 2.0's pthread MPM, of course you can build perl
5.6 non threaded and use apache 2.0's prefork model but then it's not
as exciting :-)
maybe not as exciting, but still very important, the 1.3.x model works
quite well for many people, so mod_perl-2.0 will continue to support it.
--- DBI.xs~ Sun Jul 11 19:04:27 1999
+++ DBI.xs Tue Apr 25 19:05:40 2000
@@ -9,6 +9,13 @@
#include "DBIXS.h" /* DBI public interface for DBD's written in C */
+#ifndef pTHX_
+#define aTHXo_
+#define CopFILEGV(cop) cop-cop_filegv
+#define CopLINE(cop) cop-cop_line
+#define get_sv perl_get_sv
+#endif
+
#define MY_VERSION "DBI(" XS_VERSION ")"
#if (defined USE_THREADS || defined PERL_CAPI || defined PERL_OBJECT)
@@ -112,7 +119,7 @@
# if (PATCHLEVEL == 4) (SUBVERSION 68)
# define dPERINTERP_SV \
-SV *perinterp_sv = perl_get_sv(MY_VERSION, FALSE)
+SV *perinterp_sv = get_sv(MY_VERSION, FALSE)
# else
# define dPERINTERP_SV \
SV *perinterp_sv = *hv_fetch(PL_modglobal, MY_VERSION, \
@@ -121,7 +128,7 @@
# define dPERINTERP_PTR(T,name)\
T name = (T)(perinterp_sv SvIOK(perinterp_sv) \
- ? SvIVX(perinterp_sv) : NULL)
+ ? (T)SvIVX(perinterp_sv) : NULL)
# define dPERINTERP\
dPERINTERP_SV; dPERINTERP_PTR(PERINTERP_t *, PERINTERP)
# define INIT_PERINTERP \
@@ -189,13 +196,13 @@
DBIS-size= sizeof(*DBIS);
DBIS-xs_version = DBIXS_VERSION;
/* publish address of dbistate so dynaloaded DBD's can find it */
-sv_setiv(perl_get_sv(DBISTATE_PERLNAME,1), (IV)DBIS);
+sv_setiv(get_sv(DBISTATE_PERLNAME,1), (IV)DBIS);
DBISTATE_INIT; /* check DBD code to set DBIS from DBISTATE_PERLNAME*/
DBIS-logfp= stderr;
DBIS-debug= 0;
-DBIS-neatsvpvlen = perl_get_sv("DBI::neat_maxlen", GV_ADDMULTI);
+DBIS-neatsvpvlen = get_sv("DBI::neat_maxlen", GV_ADDMULTI);
sv_setiv(DBIS-neatsvpvlen, 400);
/* store some function pointers so DBD's can call our functions*/
DBIS-getcom= dbih_getcom;
@@ -613,7 +620,7 @@
if (imp_size == 0) {
/* get size of structure to allocate for common and imp specific data */
char *imp_size_name = mkvname(imp_stash, "imp_data_size", 0);
- imp_size = SvIV(perl_get_sv(imp_size_name, 0x05));
+ imp_size = SvIV(get_sv(imp_size_name, 0x05));
if (imp_size == 0)
imp_size = g_imp_maxsize + 64;
}
@@ -1450,16 +1457,16 @@
fprintf(logfp," during global destruction.");
return;
}
-if (!curcop-cop_line) {
+if (!CopLINE(curcop)) {
fprintf(logfp," at unknown location!");
return;
}
-file = SvPV(GvSV(curcop-cop_filegv), len);
+file = SvPV(GvSV(CopFILEGV(curcop)), len);
if (trace_level=4) {
if ( (sep=strrchr(file,'/')) || (sep=strrchr(file,'\\')))
file = sep+1;
}
-fprintf(logfp," at %s line %ld.", file, (long)curcop-cop_line);
+fprintf(logfp," at %s line %ld.", file, (long)CopLINE(curcop));
}
@@ -1751,7 +1758,7 @@
*/
I32 markix = TOPMARK;
CV *xscv = GvCV(imp_msv);
- (void)(*CvXSUB(xscv))(xscv);/* Call the C code directly */
+ (void)(*CvXSUB(xscv))(aTHXo_ xscv); /* Call the C code directly */
if (gimme == G_SCALAR) {/* Enforce sanity in scalar context */
if (++markix != stack_sp - stack_base ) {
@@ -2130,7 +2137,7 @@
Fflush(DBILOGFP);
}
DBIS-debug = level;
- sv_setiv(perl_get_sv("DBI::dbi_debug",0x5), level);
+ sv_setiv(get_sv("DBI::dbi_debug",0x5), level);
}
}
OUTPUT:
@@ -2226,7 +2233,7 @@
}
if (type == '$') { /* lookup scalar variable in implementors stash */
char *vname = mkvname(DBIc_IMP_STASH(imp_xxh), meth, 0);
- SV *vsv = perl_get_sv(vname, 1);
+ SV *vsv = get_sv(vname, 1);
if (trace)
fprintf(DBILOGFP,"- %s = %s\n", vname, neatsvpv(vsv,0));
ST(0) = sv_mortalcopy(vsv);
Re: Deep Recursion with File::Copy
On Tue, 25 Apr 2000, Jeremy Blumenfeld wrote: Hi. We are running Server Version: Apache/1.3.9 (Unix) mod_perl/1.21 on a Linux system. Having problems with a "Deep Recursion" when using the copy method of File::Copy. my guess is that you're using Perl 5.005_03 and have PerlFreshRestart On perl 5.6.0 fixes File::Copy so it can be reloaded (see Changes entry below). either turn FreshRestart Off or update File::Copy to 5.6.0's version [ 4753] By: gsar on 2000/01/05 06:48:22 Log: From: [EMAIL PROTECTED] (Andreas J. Koenig) Date: 03 Jan 2000 21:56:02 +0100 Message-ID: [EMAIL PROTECTED] Subject: Reloading File::Copy Branch: perl ! Changes lib/File/Copy.pm t/lib/filecopy.t
Re: Deep recursion on subroutine Apache::Constants::AUTOLOAD
On Tue, 25 Apr 2000, Martin Lichtin wrote: Doug MacEachern wrote: Anyone understand why perl -we 'use Apache::Constants; Apache::Constants::OK();' causes this problem? what version of mod_perl are you using? ' mod_perl 1.21, perl 5.00503 ok, well, i don't understand why you're getting this error on the command line, but Apache::Constants only works inside httpd anyhow. are you having a problem using it inside httpd?
Re: Modperl/Apache deficiencies... Memory usage.
On Sat, 15 Apr 2000 [EMAIL PROTECTED] wrote: Modperlers..., I'd like to start a discussion about the deficiences in Apache/modperl and get you feedback with regard to this issue. The problem as I see it is that the process model that Apache uses is very hard on modperl. mod_perl-2.0/apache-2.0 should solve this (fingers crossed :) It is very memory inneffecient basically. Each process of apache has it's registry which holds the compiled perl scripts in..., a copy of each for each process. This has become an issue for one of the companies that I work for, and I noted from monitoring the list that some people have apache processes that are upwards of 25Megs, which is frankly ridiculous. with 2.0, the syntax tree is shared (at the Perl level) however, padlists are not shared. as i mentioned, i'd like to look at using your "garbage collector" for 2.0. if it could run in it's own thread and examine the padlists of idle interpreters, it could be big win. i wouldn't want it to release all allocations in the padlist by default. maybe be configurable to only release things of a certain size. what i would personally like to see is one that just reports anything that's larger than X size, so i can fix the Perl code not copy large chunks of data, and/or figure out how to make large chunks of data shared between interpreters. i kinda started this with the B::Size hooks in Apache::Status, but you have to dig around the symbol table to find how big things are, there's no overall reporting mechanism. One of my concerns is that maybe the apache module API is simply too complex to pull something like this off. I don't know, but it seems like it should be able to handle something like this. if you need a model where the Perl engine is in a different process than Apache, that should be implemented with FastCGI or something else. the overhead of passing the request_rec (and everything it points to) between processes for all of the various phases (so mod_perl could still everything it can today) would be a nightmare.
RE: ANNOUNCE: Apache::AuthCookie 2.007
[EMAIL PROTECTED] (Gerald Richter) wrote: Hi Ken, the patch I send you for overwriting the login_form seems not to be in 2.007. Are there any reason for this or did you just forget it? Hi Gerald, Actually, neither - it's just that I haven't gotten to it yet. The changes I put in 2.007 come from requests/patches people submitted before you. =) Your patch looks good, but I haven't had a chance to look closely. I hope to get it in there soon in some form.
Re: Modperl/Apache deficiencies... Memory usage.
On Sat, 15 Apr 2000 [EMAIL PROTECTED] wrote: It is very memory inneffecient basically. Each process of apache has it's registry which holds the compiled perl scripts in..., a copy of each for each process. This has become an issue for one of the companies that I work for, and I noted from monitoring the list that some people have apache processes that are upwards of 25Megs, which is frankly ridiculous. Originally I thought this as well.. but, using mod_rewrite, the ratio of heavy to light processes can be very high.. some solid figures here: our site (dslreports) now handles 200,000 pages a day, every single one of them is dynamically generated.. at peak this is 10-20 modperl pages a second.. to handle this, we have httpd modperl with MIN, MAX and LIMIT of just 8(!) modperl processes, 2 php httpds (just for true type font rendering ;-) and as many front-end httpds (mod_rewrite and mod_proxy) as required (usually about 100 but can be 200-300 at times). There is almost never all 8 modperls running at one time.. even long pages fit in the buffers between back end, mod_proxy, and front end meaning its hard to catch mod perl in the act of actually servicing requests. On the same box is mysql (40-60 daemons), constant mail handling, various other custom perl daemons and utilities, MRTG monitoring of 100s of IP addresses, a busy ultimate bulletin board (plain cgi - ugh), development and testing as well sometimes. This is all handled by two 450mhz processors and 1gig of memory, no swapping, half of the memory ends up being used by linux for disk caching.. modperl uses up about 256mb I suppose. With that much traffic, memory leaks, and the odd SQL query that reads too much, the modperl processes grow slowly to about 40mb each, but get reborn, every 1000 requests, at 28mb again. The load average hovers around 5.0 I read today drkoop (while going broke) now does 600k pages per day.. I bet they have a couple of million bucks worth of solaris, oracle and IIS, serving out mainly static content? whats the price/performance problem with modperl again? So I find this setup very stable and very flexible .. and would not swap it for a pool of interpreters, or a multi-threaded server for all the tea in china .. because I dont think either of those models (elegant though they may sound, and absolutely the right direction) will be as stable for some considerable time. -Justin
design question
I am trying to implement a cross platform auth scheme whereby users log into a system running in a microsoft environment. Then, when they want to check their e-mail, they click a link in the form of: mail.isoftcorp.com/auth?k=sequence the key sequence is determined when they log into the main site and it is databased. then, they hit my server and I will take the key sequence and query the databse: 1) The database returns foo, I deny the request (this I can eaily do) 2) The database returns bar, I rewirte the request into a post. The handler would rerite the request and then turn it back over to apache for further processing: my new request would be in thr form of: $request=HTTP::Request-new(POST='http://mail.isoftcotp.com/index.pl', [var1='hojo',var2='val2']); #where val1 and val2 are from the DB However, I do not know how to rewirte the request in this way and use it in a handler. What would be the proper way to rewrite the request? Which handler should I use? If I need to provide any more info, fell free to ask.
ANNOUNCE: HTML::Embperl 1.3b3
The URL
ftp://ftp.dev.ecos.de/pub/perl/embperl/HTML-Embperl-1.3b3.tar.gz
has entered CPAN as
file: $CPAN/authors/id/GRICHTER/HTML-Embperl-1.3b3.tar.gz
size: 272444 bytes
md5: a0a28868e85094f7d52f00fa8d046298
Changes since 1.3b2:
- Fixed SIGSEGV which occurs in cleanup with Perl 5.6. Spotted by
Aaron Johnson.
- Changed make test so it works correctly with new error messages of
Perl 5.6.
- Fixed a bug that Execute will always fail when $@ was set before.
Patch from Francis J. Lacoste.
- Changed test so it accpects charset in Content-Type header from
Apache 1.3.12
- The outputfile parameter now also works when running under
mod_perl. Spotted by Ilia Lobsanov.
- Makefile.PL warns if you build with a DSO mod_perl 1.22
- make test checks that test files are readable by Apache.
- Applied a patch from Jens-Uwe Magner to make Embperl work
with mod_perl 1.22 on AIX. We now require mod_perl 1.22,
but I should now work as DSO and staticly linked.
- Applied a patch from Francis J. Lacoste that makes sure
that when a package name is given the file is always compiled
into this package. Note: This means that if you specify a
packagename and the packagename differs from request to
request, the page is compiled for every package and therfore
consuming memory on every request.
- Added EMBPERL_SESSION_HANDLER_CLASS which allows you to overwrite
Embperl defaults session handling. Idea form Barrie Slaymaker.
- Added EmbperlLogo.gif to the distribution, which contains
"Powered by Embperl".
- Added Patch from Randy Kobes that makes Embperl compile with
Apache 1.3.12 and Perl 5.6 on Win32.
- Removed some -w warnings form EmbperlObject
- Added tests for EmbperlObject
- Fixed a SIGSEGV that occured when Embperl found [*] inside
a page. Spotted by Barrie Slaymaker.
- Added epchar.c.min which contains translation tables which
let's all chars above 128 untouched. This is usefull for
processing two byte charsets. Patch from Sangmook Yi.
- The searchpath (EMBPERL_PATH) now uses semikolons (';') instead
of colons (':') to avoid problems with Windows drive letters.
Colons still work on Unix.
-
Gerald Richterecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151
WWW:http://www.ecos.de Fax: +49 6133 925152
-
Re: mod_proxy problem
| VirtualHost _default_:8082 |DocumentRoot "/app/env_control/httpd/DocumentRoot" |Location "/Test" | # disable mason for this location | SetHandler default-handler |/Location |ProxyPass/Test/ http://myhost:8084/Test/ |ProxyPassReverse /Test/ http://myhost:8084/Test/ | /VirtualHost | | When I try to access location /Test/, I get the following | error: | | [Tue Apr 25 08:59:34 2000] [error] [client ip address] File | does not exist: | proxy:http://myhost:8084/Test/CheckDeployment/GetUKLs | | Can anybody give me some insight as to what I am doing wrong? | I am new to mod_proxy and I don't even know where to start | looking. Show us your VirtualHost blablabla:8084 (the destination in this proxy config), a "ls -l" of /app/env_control/httpd/DocumentRoot/Test/CheckDeployment and a "host myhost". Ime
cvs commit: modperl-site/embperl index.html
richter 00/04/25 21:07:55 Modified:embperl index.html Log: Embperl Webpages - Changes Revision ChangesPath 1.100 +5 -0 modperl-site/embperl/index.html Index: index.html === RCS file: /home/cvs/modperl-site/embperl/index.html,v retrieving revision 1.99 retrieving revision 1.100 diff -u -r1.99 -r1.100 --- index.html2000/04/25 04:57:48 1.99 +++ index.html2000/04/26 04:07:54 1.100 @@ -140,6 +140,11 @@ /tr tr bgcolor="#bFcDdA" td vAlign="top"img height="13" src="bullet.gif" width="13"/td +td vAlign="top"26. Apr 2000/td +tdfont face="Helvetica,Arial" size="2"Embperl 1.3b3 released/font/td + /tr + tr bgcolor="#bFcDdA" +td vAlign="top"img height="13" src="bullet.gif" width="13"/td td vAlign="top"25. Apr 2000/td tdfont face="Helvetica,Arial" size="2"a href="http://www.perlmonth.com/index.html?issue=11"Perlmontha starts a new article series about Embperl/font/td /tr @@ -277,7 +282,7 @@ blockquote pfont color="#808080" size=1hr HTML::Embperl - Copyright (c) 1997-2000 Gerald Richter / ECOS lt;[EMAIL PROTECTED]gt; - Last Update $Id: index.html,v 1.99 2000/04/25 04:57:48 richter Exp $/font/p + Last Update $Id: index.html,v 1.100 2000/04/26 04:07:54 richter Exp $/font/p /blockquote /td/tr!--msnavigation--/table/body /html
