RE: Header Sending Bug?
-Original Message- From: Jeff Beard [mailto:[EMAIL PROTECTED]] Sent: Sunday, May 14, 2000 11:42 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Header Sending Bug? I don't see a problem with this but maybe I'm missing your point. :) well, if his point was that printing to STDERR (not STDOUT) caused $r-send_http_headers to be called prematurely, I guess that would be a problem... unfortunately, I can't reproduce the results David reported using 1.23_01 (current cvs) here was my test script, run under Regustry with PerlSendHeaders On #!/usr/bin/perl print STDERR "testing\n"; print "Content-type: text/html\n\n"; print "hi"; no headers, just "hi" in the browser and "testing" in the error_log... of course, with PerlSendHeaders Off, Netscape gets a download screen (expected) is this what you meant? --Geoff If PerlSendHeader is set to "On", you don't have to send a header in your program. If you want to retain control of when the header is sent, set PerlSendHeader to "Off" and do it yourself. --Jeff At 12:53 AM 5/14/00, David E. Weekly wrote: Hello all. I've looked in various mod_perl FAQs but haven't seen the answer to what seems to be a (minor) bug in Apache::Registry. It seems that when PerlSendHeader is On if I haven't yet done a print "Content-type: text/html\n\n" but I want to print a comment into the weblog by doing a print STDERR "I got value $value.\n" It seem Apache::Registry will go ahead and print out the default headers, causing my "Content-type: text/html" to show up ad verbatim on the rendered page: not the desired effect! While I understand that it would make sense for Apache::Registry to print out the headers if I start spewing out text to STDOUT, it is, IMHO, not a good behavior for it to do the same when I write to STDERR. Has this been reported like a kajillion times (in which case someone will politely reach their virtual hand out and smack me upside the head) or is this a sufficiently out-of-the-way sort of error that people haven't reported it yet? At any rate, I'd just be tickled pink if someone fixed it. Yours, David Weekly Jeff Beard _ Web: www.cyberxape.com Email:jeff at cyberxape.com Location: Boulder, CO, USA
Re: mod_perl and ssi
When I try the RegistryFilter+SSI approach, the headers generated by my scripts _occasionally_ show up in the output (but as I see in SSI.pm, there's really no header output when Filter is On). Provided that PerlSendHeader is On, if I set it to Off, the headers always show up in the output. I then try OutputChain+SSI, it almost works, but the #include's didn't come up in the right place. Suppose the template looks like, (hello.txt contains the text "hello!") !--before-- !--#include virtual="/hello.txt"-- !--after-- Here's what I got, hello! !--before-- !--after-- What's wrong with me? Ken Williams wrote: Yes - you'll probably want to use Apache::Filter (implements the filtering framework, so one handler can filter another) with Apache::SSI and Apache::RegistryFilter (which ships with new Apache::Filter). If you use this approach, you'll have a config directive like "PerlHandler Apache::RegistryFilter Apache::SSI" in your httpd.conf file. You can also call the methods of Apache::SSI yourself if you don't want to chain PerlHandlers. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
KHTTPD for static and Apache/mod_perl for dynamic??
hi, My question is instead of using two Apache servers OR Apache+proxy scenario (static vs dynamic pages) will it be possible to leave static pages to kHTTPD and run only one APACHE server. Did someone tried it... Thanx = iVAN [EMAIL PROTECTED] =
Re: Oops Re: ANNOUNCE: mod_perl guide version 1.23
Stas Bekman wrote:
On Sun, 14 May 2000, w trillich wrote:
i noticed this in the html source of the new guide
(this was on porting cgi to mod_perl):
LINK REL=STYLESHEET TYPE="text/css"
HREF="style.css" TITLE="refstyle"
style type="text/css"
!--
@import url(style.css);
--
/style
doubt this is what was supposed to show up in our browsers...
looks like asp, or similar, isn't turned on.
Why, this is all fine, the !-- -- are exectly in the JS, for old
browsers.
right, i grok that !-- -- hides it from older browsers;
but i thought the CONTENTS of file "style.css" should be showing
up there, instead of '@import...', until i (just now) learned
of the '@rules' of css.
but now, i'm thinking that you've got a redundancy there
(maybe for good reason--i dunno). here's a sample i ran across
at www.hwg.org/resources/faqs/cssFAQ.html:
LINK REL=STYLESHEET HREF="main.css" TYPE="text/css"
STYLE TYPE="text=css"
!--
@import url(http://www.and.so.on.partial1.css);
@import url(http://www.and.so.on.partial2.css);
other statements
--
/STYLE
they link to 'main.css' and then import some others;
you've linked to 'style.css' and then imported it again.
and do you need to include the 'url()' gadget?
maybe there's a way to put a hilite bar in the left margin
this way...? tables may still be easier. hmm...
Hmm, interesting. Do you have a code sample?
testing this on netscape 4.7 gave me fits with 'font-family'
in the 'pre' tag: it just wouldn't take (everything was
always times-roman). so here's what i came up with:
style type="text/css"
!--
.box {
background-color: #cc;
/* border: 1pt;
*/ border-left-width: 12pt;
border-style: solid;
border-color: #99;
margin: 1pt;
padding: 9pt;
}
/*
pre { == that'd be awful nice to keep frum munging the html
background-color: #cc;
border-color: #99;
border-left-width: 5pt;
margin: 1pt;
padding: 9pt;
font-family: courier,monospace,arial,sans-serif; == no-go!
white-space: pre;
}
*/
--
/style
then, wrap your pre/pre tags into div class="box".../div tags:
div class="box"pre#!perlbr
exit 0;/pre/div
maybe you can decode what i was doing wrong on the 'font-family'
thing (or, maybe for code a monospace font isn't that crucial--only
when lots-o-spaces are used to visually align clusters of assignments)...
HTH :)
RE: CGI::Delete for Apache::Request
-Original Message-
From: Doug MacEachern [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 12, 2000 2:02 PM
To: Michael Blakeley
Cc: [EMAIL PROTECTED]
Subject: Re: CGI::Delete for Apache::Request
On Sat, 6 May 2000, Michael Blakeley wrote:
I've been migrating some code off of the ENV-dependent methods in
CGI.pm, so I can turn of PerlSetupEnv. Anyway, I couldn't find an
Apache::Request method that had the functionality of CGI::Delete.
Since I use Delete extensively, I coded a replacement based on the
param() prototype in Apache::Request. This may be useful to other
programmer porting CGI.pm code.
# for compatibility with CGI::Delete - call with $apr-Delete("foo")
sub Delete {
my $self = shift;
my $tab = $self-parms;
for (@_) {
$tab-unset($_);
}
} # end sub Delete
Trivial, once you know how. But maybe worth including in a
future rev
of Apache::Request? Or at least documenting? I spent some time just
finding "unset".
i would like to document the $self-parms table, and point to the
Apache::Table docs.
It'd be even better if unset() would take a list argument,
of course
that can be arranged :) i would prefer this, rather than adding the
Delete method to Apache::Request.
just picking up some of the scut work, if it helps :)
--- Request.pm.old Mon May 15 10:55:47 2000
+++ Request.pm Mon May 15 11:22:07 2000
@@ -116,6 +116,14 @@
my @params = $apr-param;
$apr-param('foo' = [qw(one two three)]);
+=item parms
+
+Returns a hash reference tied to the IApache::Table class.
+Provides an alternative interface to the same fields as param().
+
+my $table = $apr-parms;
+my $value = $table-get('foo');
+
=item upload
Returns a single IApache::Upload object in a scalar context or
--Geoff
RE: newbie question - require
Check the mod_perl guide for the usage of require() and do(). You probably
want to use do() instead of require().
Chris
-Original Message-
From: Brett Lee [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 15, 2000 7:56 AM
To: [EMAIL PROTECTED]
Subject: newbie question - require
In moving from CGI.pm to mod_perl, I ran across the common error with
functions that exist in scripts pulled in with 'require'.
Mod_perl_traps.html had the solution. Similarly, am using ('require')
another file which holds all the hash tables (countries, states, etc.)
that my scripts need to reference. It appeared to work fine in CGI.pm,
but with mod_perl, the info in the hash tables seems to be found "every
other refresh" (which has me stumped).
Would anyone be able to suggest a solution or reading material on this?
Thanks in advance.
-Brett
make test of Apache::SSI
Hi, I am installing Apache::SSI under Mod_perl.. When I ran make test I have permission denied when it trying to start httpd , therefore the test failed. My httpd was running under (root, other) as the (user, group). At perl Makefile.PL I specified the user as root and group as other, but still can't get permission to run the test, May be this test is not important, but Is there any body knows how to successfully test the build? Thanks, PC Wang
systems, examples, samples
Hello, please, I would like to know some systems/scripts using mod_perl+mysql. like news, forum, poll... I would like to test, and learn how people are using mod_perl. thanks marcus _ Quer linha desocupada nas Internets gratis? Multidiscador BOL. Totalmente gratis! http://www.bol.com.br/multi/
Re: database efficiency
On Mon, 15 May 2000, Jay Jacobs wrote: I've been reading over the guide on "Efficient Work with Databases under mod_perl" and there's one thing I don't quite grok about it. Let's say I have a site that goes through select statements like water. If I were to cache the statement handler (as described in the guide), how does the database (database dependant) handle a bunch of dangling statement handlers? Will the database process size grow a ton? I'm not sure if I'm hitting what I wanted to ask, but hopefully I'm close enough. Every statement handle that you leave open will consume resources on the database server, and also on the client side. These resources are presumed to be more plentiful than the resources (CPU time and network packets) needed to frequently setup and teardown statement handles. -jwb
Re: database efficiency
On Mon, 15 May 2000, Jay Jacobs wrote:
mod_perl" and there's one thing I don't quite grok about it. Let's say I
have a site that goes through select statements like water. If I were to
cache the statement handler (as described in the guide), how does the
database (database dependant) handle a bunch of dangling statement
handlers? Will the database process size grow a ton? I'm not sure if I'm
hitting what I wanted to ask, but hopefully I'm close enough.
Are you talking about the part that says you should use prepare_cached
vs. prepare?
If so, this doesn't do anything under most DBD modules, AFAIK. Under
Oracle, it causes Oracle to hold the statement handle (an Oracle
cursor)in cache after it generates the execution plan. If you open too
many of these eventually Oracle complains (I think you can close them by
wiping out $dbh-{CachedKids} which deletes the statement handles which
causes them to go through their DESTROY). The oracle error you get is
something like 'Too many open cursors' I think.
-dave
/*==
www.urth.org
We await the New Sun
==*/
Re: database efficiency
On Mon, 15 May 2000, Jeffrey W. Baker wrote: On Mon, 15 May 2000, Jay Jacobs wrote: I've been reading over the guide on "Efficient Work with Databases under mod_perl" and there's one thing I don't quite grok about it. Let's say I have a site that goes through select statements like water. If I were to cache the statement handler (as described in the guide), how does the database (database dependant) handle a bunch of dangling statement handlers? Will the database process size grow a ton? I'm not sure if I'm hitting what I wanted to ask, but hopefully I'm close enough. Every statement handle that you leave open will consume resources on the database server, and also on the client side. These resources are presumed to be more plentiful than the resources (CPU time and network packets) needed to frequently setup and teardown statement handles. if this behavior is unacceptable, i believe you can use the finish method: finish $rc = $sth-finish; Indicates that no more data will be fetched from this statement handle before it is either executed again or destroyed. It is rarely needed but can sometimes be helpful in very specific situations in order to allow the server to free up resources currently being held (such as sort buffers). (from perldoc DBI) ky
Re: database efficiency
On Mon, 15 May 2000, Ken Y. Clark wrote: On Mon, 15 May 2000, Jeffrey W. Baker wrote: On Mon, 15 May 2000, Jay Jacobs wrote: I've been reading over the guide on "Efficient Work with Databases under mod_perl" and there's one thing I don't quite grok about it. Let's say I have a site that goes through select statements like water. If I were to cache the statement handler (as described in the guide), how does the database (database dependant) handle a bunch of dangling statement handlers? Will the database process size grow a ton? I'm not sure if I'm hitting what I wanted to ask, but hopefully I'm close enough. Every statement handle that you leave open will consume resources on the database server, and also on the client side. These resources are presumed to be more plentiful than the resources (CPU time and network packets) needed to frequently setup and teardown statement handles. if this behavior is unacceptable, i believe you can use the finish method: finish $rc = $sth-finish; Indicates that no more data will be fetched from this statement handle before it is either executed again or destroyed. It is rarely needed but can sometimes be helpful in very specific situations in order to allow the server to free up resources currently being held (such as sort buffers). (from perldoc DBI) That's true, and the RDBMS would be free to release any buffers associated with unfetched rows in that case. However, you are still consuming server-side resources with every handle that remains open. At the very least, you are consuming memory on the order of sizeof(struct statement) or whatever. -jwb
Re: database efficiency
On Mon, 15 May 2000, Autarch wrote:
On Mon, 15 May 2000, Jay Jacobs wrote:
mod_perl" and there's one thing I don't quite grok about it. Let's say I
have a site that goes through select statements like water. If I were to
cache the statement handler (as described in the guide), how does the
database (database dependant) handle a bunch of dangling statement
handlers? Will the database process size grow a ton? I'm not sure if I'm
hitting what I wanted to ask, but hopefully I'm close enough.
Are you talking about the part that says you should use prepare_cached
vs. prepare?
If so, this doesn't do anything under most DBD modules, AFAIK. Under
Oracle, it causes Oracle to hold the statement handle (an Oracle
cursor)in cache after it generates the execution plan. If you open too
many of these eventually Oracle complains (I think you can close them by
wiping out $dbh-{CachedKids} which deletes the statement handles which
causes them to go through their DESTROY). The oracle error you get is
something like 'Too many open cursors' I think.
Actually, the two things you mention are different concepts. Yes, Oracle
does have a cache where it keeps most-recently-used execution plans. If
you make proper use of bound parameters in your SQL, you can exploit this
execution plan cache.
A statement handle is a handle that is associated with one of those
execution plans. Many handles may be associated with the same SQL
statement. You can bind parameters to the handle, execute it, and fetch
rows from it. There are resources associated with the handle, such as the
bound parameters and some state information. These are the resources that
are consumed if you agressively accumulate open statement handles on the
client side.
-jwb
Re: KHTTPD for static and Apache/mod_perl for dynamic??
On Mon, May 15, 2000 at 09:48:07AM -0700, Jeffrey W. Baker wrote: On Mon, 15 May 2000 [EMAIL PROTECTED] wrote: On Mon, May 15, 2000 at 04:37:06PM -0400, raptor wrote: hi, My question is instead of using two Apache servers OR Apache+proxy scenario (static vs dynamic pages) will it be possible to leave static pages to kHTTPD and run only one APACHE server. Did someone tried it... Well, I'm not sure specifically about khttpd..., I'm generally against in kernel httpd serving outside of an embedded device. However, you might want to look at phhttpd (people.redhat.com/zab/). It's faster than khttpd, and it runs in userland. Thanks, Shane. Shane, I noticed that all the phhttpd pages have disappeared. What's up? Hmm.., you are right. Well..., Zach doesn't work for redhat anymore. I don't have a copy of the latest source..., well, I do, but it's riddled with my own changes. I was wondering when they were going to take down his page..., damn redhat! Hrm.., well, I'll send an email off to Zach today, and try to get a mirror of the last version. (a clean one with out all my patches) Zachs website is www.zabbo.net, I'm sure he'll be posting a local copy soon. If not I'll mirror it, and let anyone know that's interested. So if you are, drop me a note. Thanks, Shane. -jwb
Re: KHTTPD for static and Apache/mod_perl for dynamic??
I noticed that all the phhttpd pages have disappeared. What's up? Hmm.., you are right. Well..., Zach doesn't work for redhat anymore. I don't have a copy of the latest source..., well, I do, but it's riddled with my own changes. I was wondering when they were going to take down his page..., damn redhat! Hrm.., well, I'll send an email off to Zach today, and try to get a mirror of the last version. (a clean one with out all my patches) Zachs website is www.zabbo.net, I'm sure he'll be posting a local copy soon. If not I'll mirror it, and let anyone know that's interested. So if you are, drop me a note. Thanks, Shane. *Update* I just got an email reply to Zach (man that was like 5 minutes..., very cool), anyhow. He said that they pulled a bunch of his stuff, but he's getting together backup stuff. It will likely be on zabbo.net in a couple days. If anyone has a tarball handy toss it my way, and I'll put it on an anonymous ftp. Thanks, Shane.
Re: KHTTPD for static and Apache/mod_perl for dynamic??
On Mon, 15 May 2000, raptor wrote: My question is instead of using two Apache servers OR Apache+proxy scenario (static vs dynamic pages) will it be possible to leave static pages to kHTTPD and run only one APACHE server. It will, but you're missing part of the benefit from the proxy scenario. As the guide explains, running a proxy in front of your dynamic page server will help keep the number of processes down by dealing with slow clients for you. A super fast server for images and truly static pages is a good idea, although a simple stripped-down apache will probably handle more static page traffic than you can afford the bandwidth for anyway. - Perrin
Re: make test of Apache::SSI
On Mon, 15 May 2000, Wang, Pin-Chieh wrote: I am installing Apache::SSI under Mod_perl.. When I ran make test I have permission denied when it trying to start httpd , therefore the test failed. It doesn't work for me either. I think Ken was going to make this test optional. Anyway, if you're using CPAN to install (which I assume you are, because this wouldn't be a problem for you otherwise) you can just do a "force install". - Perrin
Re: KHTTPD for static and Apache/mod_perl for dynamic??
On Mon, May 15, 2000 at 12:20:19PM -0700, Perrin Harkins wrote: On Mon, 15 May 2000, raptor wrote: My question is instead of using two Apache servers OR Apache+proxy scenario (static vs dynamic pages) will it be possible to leave static pages to kHTTPD and run only one APACHE server. It will, but you're missing part of the benefit from the proxy scenario. As the guide explains, running a proxy in front of your dynamic page server will help keep the number of processes down by dealing with slow clients for you. A super fast server for images and truly static pages is a good idea, although a simple stripped-down apache will probably handle more static page traffic than you can afford the bandwidth for anyway. - Perrin Perrin, These httpd static accelerators do 100 times better than apache does. They only have ONE process per CPU :-). No matter how many clients their dishing out to simultaneoulsy. Thanks, Shane.
Re: KHTTPD for static and Apache/mod_perl for dynamic??
On Mon, 15 May 2000 [EMAIL PROTECTED] wrote: [...] These httpd static accelerators do 100 times better than apache does. I don't believe that's true. And it doesn't change Perrin's point (that apache is sufficient for most pipes anyway). - ask -- ask bjoern hansen - http://www.netcetera.dk/~ask/ more than 70M impressions per day, http://valueclick.com
Re: KHTTPD for static and Apache/mod_perl for dynamic??
It was an overstatement in my Zeal :-). Clearly not. Up to maybe 10x. That's the best improvement I've ever seen. But..., realistically with a well tuned apache vs. a well tuned static accelerator, probably 4x is tops. (Sorry :-) Static accels handle the thundering herd problem better as well, and can dish out to more clients simultaneously. However, I think that apache will incorporate a lot of the stuff used in Static accel's soon..., so the gap will be small. But this is very OT..., we're dynamic remember! :-) Thanks, Shane. On Mon, May 15, 2000 at 12:49:12PM -0700, Ask Bjoern Hansen wrote: On Mon, 15 May 2000 [EMAIL PROTECTED] wrote: [...] These httpd static accelerators do 100 times better than apache does. 100 times is not limited to performance by the way. If you take into account simultaneous clients the memory overhead is drastically different. In terms of performance, 4x would be a slightly likely number. As the number of concurrent clients went up it would favor on the side of the static accel. With just a single client hitting the box, I would imagine the difference would be nominal. That's really were static accelorators pay off..., LOTS of simultaneous clients. I don't believe that's true. And it doesn't change Perrin's point (that apache is sufficient for most pipes anyway). - ask -- ask bjoern hansen - http://www.netcetera.dk/~ask/ more than 70M impressions per day, http://valueclick.com
Re: newbie question - require
Brett Lee wrote: but with mod_perl, the info in the hash tables seems to be found "every other refresh" (which has me stumped). Would anyone be able to suggest a solution or reading material on this? don't forget to check your stuff out with single-process mode, via 'apachectl stop; apache -X'; if it's acting sporadically in your browser, it may be because you're talking to different child apache servers, each in its own state of affairs... http://perl.apache.org/guide/porting.html#Sometimes_it_Works_Sometimes_it
Re: mod_perl-perl5.6.0
I did it and still I get the same error.
Thanks,
-Asghar
X-UIDL: 9e7ed088da7c074d11e1654b1ba4fb0c
X-Authentication-Warning: mojo.covalent.net: dougm owned process doing -bs
Date: Fri, 12 May 2000 18:00:31 -0700 (PDT)
From: Doug MacEachern [EMAIL PROTECTED]
To: Asghar Nafarieh [EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject: Re: mod_perl-perl5.6.0
MIME-Version: 1.0
On Fri, 12 May 2000, Asghar Nafarieh wrote:
Hi,
I just upgrated my perl5.6.0 from 5.005 and I cannot get mod_perl to work
for
me. I recompiled and installed mod_perl_1.23, but I get error "document
contains no data" prompt from the browser when I activate the mod_perl
module.
Has anyone have this problem?
yes, it's been explained several times in the past few weeks, here's one
from today...
Date: Fri, 12 May 2000 11:28:08 -0700 (PDT)
From: Doug MacEachern [EMAIL PROTECTED]
To: Brian P Millett [EMAIL PROTECTED]
cc: modperl [EMAIL PROTECTED]
Subject: Re: [Fwd: [apache-users] Core with x86 solaris modperl]
i'm going to release 1.24 asap to stop this madness. looks like another
case of the 5.6.0 largefile support bug, which the patch below will fix.
for apxs, you'll need to build apache like so:
CFLAGS="-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" \
./configure \
...
--- Makefile.PL 2000/04/21 19:37:45 1.159
+++ Makefile.PL 2000/04/27 22:45:30 1.160
@@ -186,7 +186,7 @@
$PERL_DEBUG = "";
$PERL_DESTRUCT_LEVEL = "";
$PERL_STATIC_EXTS = "";
-$PERL_EXTRA_CFLAGS = "";
+$PERL_EXTRA_CFLAGS = $] = 5.006 ? $Config{ccflags} : "";
$SSLCacheServerPort = 8539;
$SSL_BASE = "";
$Port = $ENV{HTTP_PORT} || 8529;
Access to userland objects in different phases
In the content serving phase I have a Database services object which
manages all access to/from the database. The DB::Services object is
created the first time the handler is hit; the $dbs is made available by
creating a symtab entry, so all my Mason components can get at the database
easily.
I also have a couple of Authen and Authz handlers (ala Apache::AuthCookie),
and I would like to have access to the services object there as well. I
could just create another DB::Services object, but there is quite a bit of
overhead associated with having a Services object in memory, hence I would
like to have a single Services object per Apache process.
Since the auth phases occur before content serving, I would have to create
the DB::Services object in the Auth/Authz handler, and then obtain access
to it in the Mason handler.
So, I think I would do something like this:
Create the DB::Services object in the authentication phase if it hasn't
already been created. (the Services object has to be created in the
auth/authz phase, since that's before the phase in which Mason runs) Once
it's been created, then do something like:
local *HTML::Mason::Commands::dbs = \$dbs;
thus making the DBS available to Mason. By the time the Mason handler
get's invoked, a $dbs is already in the right namespace, and is therefore
ready to use. Any access to $dbs from the actual handler could be obtained
by explicitly referencing the $dbs object via the package global name.
I guess another way of doing it would be to turn the $dbs class into a
Singleton, and provide a class method to get at the instance:
DB::Services-set_uri( 'dbi:Oracle:' );
DB::Services-set_userid( 'foo' );
DB::Services-set_password( 'bar' );
DB::Services-set_options( { ... } );
my $dbs = DB::Services-get_instance;
get_instance() would create the backing object the first time, then
returned the cached object on subsequent calls.
Thoughts?
Cheers!
-klm.
---
Ken Miller, Consultant
Shetland Software Services Inc.
Re: Access to userland objects in different phases
* Ken Miller ([EMAIL PROTECTED]) [000515 17:16]:
In the content serving phase I have a Database services object which
manages all access to/from the database. The DB::Services object is
created the first time the handler is hit; the $dbs is made available by
creating a symtab entry, so all my Mason components can get at the database
easily.
...snip...
I guess another way of doing it would be to turn the $dbs class into a
Singleton, and provide a class method to get at the instance:
DB::Services-set_uri( 'dbi:Oracle:' );
DB::Services-set_userid( 'foo' );
DB::Services-set_password( 'bar' );
DB::Services-set_options( { ... } );
my $dbs = DB::Services-get_instance;
get_instance() would create the backing object the first time, then
returned the cached object on subsequent calls.
I use Class::Singleton in mod_perl apps with *no* problem
whatsoever. In fact, it's pretty nifty to simply say:
my $obj = $class-instance;
anywhere in my application and have the object (whatever it is) simply
pop up.
Good luck!
Chris
--
Chris Winters
Internet DeveloperINTES Networking
[EMAIL PROTECTED]http://www.intes.net/
Integrated hardware/software solutions to make the Internet work for you.
Re: make test of Apache::SSI
On Mon, 15 May 2000, Ken Williams wrote: I'd prefer to figure out why the test is failing, because most of the real testing is done using that test. But it's difficult because I've never seen the test fail. Looks like the problem lies in this line in t/real.t: my $HTTPD = "/home/ken/http/httpd"; This results in the following message, even if I supply a path to my httpd: t/real..Starting http server... /home/ken/http/httpd doesn't exist or isn't executable. Edit real.t if you want to test with a real apache server. Aborting real.t at real.t line 79. Shouldn't the path I give to the Makefile.PL override this one? By the way, this one does let me skip the test if I want to. Maybe it was Filter's test that didn't have an opt-out. - Perrin
Re: make test of Apache::SSI
[EMAIL PROTECTED] (Perrin Harkins) wrote: On Mon, 15 May 2000, Ken Williams wrote: I'd prefer to figure out why the test is failing, because most of the real testing is done using that test. But it's difficult because I've never seen the test fail. Looks like the problem lies in this line in t/real.t: my $HTTPD = "/home/ken/http/httpd"; Oh my goodness! I thought I fixed that long ago. The path isn't being set by the user anywhere. I'll release a new version with the fixes now. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
ANNOUNCE: Apache::SSI v2.12
The URL http://mathforum.com/~ken/modules/archive/Apache-SSI-2.12.tar.gz has entered CPAN as file: $CPAN/authors/id/KWILLIAMS/Apache-SSI-2.12.tar.gz size: 16154 bytes md5: 9d999ef37a1815f1767918336c15df49 Changes since 2.11: 2.12 Mon May 15 18:50:37 EDT 2000 Don't force content_type to be 'text/html'. Let the server admin decide that in the httpd.conf file. [[EMAIL PROTECTED] (Dan McCormick)] Get the port, user, group, and path to httpd from the user at 'perl Makefile.PL' time. This stuff is used during the 'make test' step. This module should now behave like Apache::Filter and Apache::AuthCookie with respect to those 4 parameters at test time. [[EMAIL PROTECTED] (Perrin Harkins) and [EMAIL PROTECTED] (Wang, Pin-Chieh)] ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: without Apache::Registry, redefined subs still?
On Tue, 9 May 2000, w trillich wrote: redefined subs with perlrun? it's just a warning. but, that warning should go away if you use the cvs version of Apache::PerlRun
Re: Segmentation fault (11) with mod_perl 1.23...
On Fri, 12 May 2000, Mark Haviland wrote: Hey all... I just upgraded my box to redhat 6.2.2 and compiled Apache 1.3.12 with mod_perl (1.23) as a DSO (outside the Apache tree using apxs). Now, modules that use to work are suddenly causing seg faults. The one in particular that doens't seem to jive with mod_perl is Sybase::CTlib. Has anybody else seen this problem ? what versions of things did you upgrade from? where you using dso with the older versions? unload_xs_so: 0x8396fc0 hmm, i wonder if the dso "fix" broke things for you, what happens if you comment out this line of mod_perl.c: unload_xs_so(librefs);
Re: works on linux, doesn't work on sun.
Location / SetHandler perl-script PerlSendHeader on PerlHandler Mf7 Options +ExecCGI strange that would fix things, unless your Mf7 module is testing for $r-allow_options OPT_EXECCGI mod_perl never checks that bit, it's up to modules, e.g. Apache::Registry make that check.
Re: Problem with @INC
On Sat, 13 May 2000, Robert Nice wrote: use lib '../site_perl'; it's been explained, 'use lib' happens at compile time (once per-script) and @INC is reset to whatever it was startup time after each request. the simple solution for you, which i didn't see mentioned, is to modify @INC at runtime, e.g. unshift @INC, '../site_perl';
Re: Undefined DESTROY() in error_log
On Sat, 13 May 2000, Kenneth Lee wrote: I see this error message in my error_log, [Sat May 13 13:06:38 2000] [error](in cleanup) Undefined method HTML::FastTemplate::DESTROY at /usr/lib/perl5/site_perl/5.6.0/i686-linux/Apache/Registry.pm line 144 Does it mean that I have to add a dummy DESTORY() in my package? Is there any docs discussing this already? sounds like a broken AUTOLOAD function. "Undefined method" is not an error message from Perl, where is that coming from? in any case, a dummy DESTROY should bandaid just fine.
Re: Virtual servers mixing up required scripts
give me some insight into this problem: - Is this a known bug, or an unavoidable by-product of the way mod_perl works? - Is it related to the fact I'm using Apache::Registry? Would switching to the native Apache API fix it? - Is it related to the fact I'm using "require", with ".pl" files? Would switching to "use" (with .pm modules) fix it? no. search the archives and/or guide for Apache::PerlVINC
[ANNOUNCE] AxKit 0.62
Just to keep things ticking over, I've released 0.62 hot on the heels of 0.61. This is a minor update with a fix for the external parsed entities cache invalidation code (which now works!) and the addition of support for !--#include...-- for XPathScript (which allowed me to modularise the docbook stylesheets). AxKit: http://xml.sergeant.org/axkit/ Download: http://xml.sergeant.org/download/ -- 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: mod_perl and ssi
Regarding the Filter approach, are you sending the headers yourself? You shouldn't. Filter will do that for you. Don't know much about the OutputChain approach. [EMAIL PROTECTED] (Kenneth Lee) wrote: When I try the RegistryFilter+SSI approach, the headers generated by my scripts _occasionally_ show up in the output (but as I see in SSI.pm, there's really no header output when Filter is On). Provided that PerlSendHeader is On, if I set it to Off, the headers always show up in the output. I then try OutputChain+SSI, it almost works, but the #include's didn't come up in the right place. Suppose the template looks like, (hello.txt contains the text "hello!") !--before-- !--#include virtual="/hello.txt"-- !--after-- Here's what I got, hello! !--before-- !--after-- What's wrong with me? Ken Williams wrote: Yes - you'll probably want to use Apache::Filter (implements the filtering framework, so one handler can filter another) with Apache::SSI and Apache::RegistryFilter (which ships with new Apache::Filter). If you use this approach, you'll have a config directive like "PerlHandler Apache::RegistryFilter Apache::SSI" in your httpd.conf file. You can also call the methods of Apache::SSI yourself if you don't want to chain PerlHandlers. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: mod_perl and ssi
I'm sending them because some of my scripts have to do redirection. But why the problem only happens _occasionally_? Anyway, in the meantime I'm passing the outputs directly to Apache::SSI, Apache::SSI-new( $output, Apache-request)-output; Ridiculous enough, but it seems to work fine. Thanks, Kenneth Ken Williams wrote: Regarding the Filter approach, are you sending the headers yourself? You shouldn't. Filter will do that for you. Don't know much about the OutputChain approach. [EMAIL PROTECTED] (Kenneth Lee) wrote: When I try the RegistryFilter+SSI approach, the headers generated by my scripts _occasionally_ show up in the output (but as I see in SSI.pm, there's really no header output when Filter is On). Provided that PerlSendHeader is On, if I set it to Off, the headers always show up in the output. I then try OutputChain+SSI, it almost works, but the #include's didn't come up in the right place. Suppose the template looks like, (hello.txt contains the text "hello!") !--before-- !--#include virtual="/hello.txt"-- !--after-- Here's what I got, hello! !--before-- !--after-- What's wrong with me?
Re: KHTTPD for static and Apache/mod_perl for dynamic??
"r" == raptor [EMAIL PROTECTED] writes: r My question is instead of using two Apache servers OR Apache+proxy r scenario (static vs dynamic pages) will it be possible to leave r static pages to kHTTPD and run only one APACHE server. Did r someone tried it... Even without knowing what kHTTPD is, I can say yes. Just change all of your images and href links to point to the proper places. That is, make anything that needs mod_perl point to the web server running Apache+mod_perl, and anything that is static to kHTTPD. This is covered in the mod_perl_tuning docs that come with your mod_perl and also in the Guide, I'm sure. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-301-545-6996 GPG MIME spoken herehttp://www.khera.org/~vivek/
newbie question - require
In moving from CGI.pm to mod_perl, I ran across the common error with
functions that exist in scripts pulled in with 'require'.
Mod_perl_traps.html had the solution. Similarly, am using ('require')
another file which holds all the hash tables (countries, states, etc.)
that my scripts need to reference. It appeared to work fine in CGI.pm,
but with mod_perl, the info in the hash tables seems to be found "every
other refresh" (which has me stumped).
Would anyone be able to suggest a solution or reading material on this?
Thanks in advance.
-Brett
RE: make test of Apache::SSI
The message is T/fake ..ok T/real ..Starting http server...cat: cannot open t/httpd.pid Sh: usage: kill [ [ -sig ] id...| -l ] I looked t/real.t file where user, group are pwang,user respectively, port is 80. Thanks, PC Wang -Original Message- From: Ken Williams [mailto:[EMAIL PROTECTED]] Sent: Monday, May 15, 2000 4:29 PM To: Perrin Harkins Cc: '[EMAIL PROTECTED]'; Wang, Pin-Chieh Subject:Re: make test of Apache::SSI [EMAIL PROTECTED] (Perrin Harkins) wrote: On Mon, 15 May 2000, Wang, Pin-Chieh wrote: I am installing Apache::SSI under Mod_perl.. When I ran make test I have permission denied when it trying to start httpd , therefore the test failed. It doesn't work for me either. I think Ken was going to make this test optional. Anyway, if you're using CPAN to install (which I assume you are, because this wouldn't be a problem for you otherwise) you can just do a "force install". I'd prefer to figure out why the test is failing, because most of the real testing is done using that test. But it's difficult because I've never seen the test fail. What permission is denied? Permission to start httpd? Perhaps you could capture the httpd.conf file that's generated and try starting the server by hand using that file. It shouldn't be too tough to figure out why it's failing if you try that (though Apache's error messages often leave a lot to the imagination). Let me know. --- --- Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
