RE: incompat. with apache/mod_perl upgrade
On Tue, 13 Mar 2001, Khachaturov, Vassilii wrote: > And, of course, I am using Stas' patent with 'use constant' now... Don't get Vassilii wrong, this module is not patented by me :) NAME constant - Perl pragma to declare constants [snip] AUTHOR Tom Phoenix, <[EMAIL PROTECTED]>, with help from many other folks. COPYRIGHT Copyright (C) 1997, 1999 Tom Phoenix This module is free software; you can redistribute it or modify it under the same terms as Perl itself. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
RE: incompat. with apache/mod_perl upgrade
And, of course, I am using Stas' patent with 'use constant' now... -Original Message- From: Khachaturov, Vassilii Sent: Tuesday, March 13, 2001 2:19 AM To: 'Steve Leibel' Cc: [EMAIL PROTECTED] Subject: RE: incompat. with apache/mod_perl upgrade I've been planning on doing this tomorrow anyhow (w/o any hope), just have to get past some presentation on the existing server with minimal breathing around it. Now, you are the one who gives me a real basis for that hope! Thanks for the tip. Vassilii
RE: incompat. with apache/mod_perl upgrade
I've been planning on doing this tomorrow anyhow (w/o any hope), just have
to get past some presentation on the existing server with minimal breathing
around it. Now, you are the one who gives me a real basis for that hope!
Thanks for the tip.
Vassilii
-Original Message-
From: Steve Leibel [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 13, 2001 2:18 AM
To: [EMAIL PROTECTED]
Subject: Re: incompat. with apache/mod_perl upgrade
At 12:26 PM -0500 3/12/01, Khachaturov, Vassilii wrote:
>When I upgraded from
>Solaris Apache/1.3.14 (Unix) mod_perl/1.24_01
>to
>Solaris Apache/1.3.17 (Unix) mod_perl/1.25
>
>the following code in my debugging httpd.conf broke:
>
>
>sub WWW_DIR () { $ENV{'HOME'} . '/www' ; } # this sub will persist to next
>
>... more code, using WWW_DIR sometimes
>
When I built Apache 1.3.17 with mod_perl 1.2.5 and numerous other
mods, the resulting httpd was unable to read its usual configuration
file. When I upgraded to Apache 1.3.19 the problem went away.
I'd try 1.3.19.
Re: incompat. with apache/mod_perl upgrade
At 12:26 PM -0500 3/12/01, Khachaturov, Vassilii wrote:
>When I upgraded from
>Solaris Apache/1.3.14 (Unix) mod_perl/1.24_01
>to
>Solaris Apache/1.3.17 (Unix) mod_perl/1.25
>
>the following code in my debugging httpd.conf broke:
>
>
>sub WWW_DIR () { $ENV{'HOME'} . '/www' ; } # this sub will persist to next
>
>... more code, using WWW_DIR sometimes
>
When I built Apache 1.3.17 with mod_perl 1.2.5 and numerous other
mods, the resulting httpd was unable to read its usual configuration
file. When I upgraded to Apache 1.3.19 the problem went away.
I'd try 1.3.19.
Re: mod_perl shared memory with MM
On Mon, Mar 12, 2001 at 12:14:26PM -0800, Sean Chittenden wrote:
> Sorry for taking a while to get back to this, road trips
> can be good at interrupting the flow of life.
>
> It depends on the application. I typically use a few
> instances of open() for the sake of simplicity, but I have also had
> decent luck with IPC::Open(2|3). The only problems I've had with
> either was an OS specific bug with Linux (the pipe was newline
> buffering and dropping all characters over 1023, moved to FreeBSD and
> the problem went away).
>
> Words of wisdom: start slow because debugging over a pipe can
> be a headache (understatement). Simple additions + simple debugging =
> good thing(tm). I've spent too many afternoons/nights ripping apart
> these kinds of programs only to find a small type-o and then
> reconstructing a much larger query/response set of programs. -sc
If you're working with Open{2,3}, you might want to take a gander at
IPC::Run, it's like Open{2,3,...}+select loop+expect, but with a
shell-like API and the ability to trace events in both the parent and
child processes (via a separate debugging pipe). Just turn debugging on
and you can see what's sent and received on each pipe. It avoids the
deadlocks warned about in the perlipc manpages (as you mention), which
can be quite tricky in the face of different failure modes. IPC::Run
establishes or manages pipes, PTYs, plain ol' filehandles and timers in
such a wayavoid deadlocks (though if you try hard engugh...).
It's a bit bloated to do all that, but the debugging feature can make it
worth the bloat in many cases, and you can certainly rename it and carve
off great hunks of unneeded features (like param parsing or say ptys)
pretty easily if you want to whittle it down after debugging.
That being said, open2 and open3 are for forking around, not for
communicating over named pipes to server processes.
> PS You also want to attach the program listening to the named
> pipe to something like DJB's daemon tools
> (http://cr.yp.to/daemontools.html) to prevent new requests from
> blocking if the listener dies: bad thing(tm).
Neat, thanks for that link.
- Barrie
RE: incompat. with apache/mod_perl upgrade
On Mon, 12 Mar 2001, Khachaturov, Vassilii wrote:
> Read it. It still doesn't address my questions
> - why this stopped working with
> the new mod_perl+apache. From the docs, rather, I'd expect a
> routine or a variable defined in one section persist to the other.
> While I can't use global vars (they try to get tied to the non-existing
> config. params), and lexicals remain scoped within the same
> section, I had to use a sub before, which I was able to access in
> the other Perl section. Now I am not. The docs say, however, I
> am eval-ed in Apache::ReadConfig - o.k., so the subs should get
> defined there and then remain there, as long as the same config
> file is read?
$Apache::Config::foo = "bar";
warn "\$foo = $Apache::Config::foo";
prints:
$foo = bar at /
since there is no strict imposed, this does as well:
$foo = "bar";
warn "\$foo = $foo";
This works too:
use constant FOO => "bar";
warn "\$foo = ".FOO;
And indeed this doesn't work:
sub FOO {"bar"};
warn "\$foo = ".FOO();
We need to look at the code to see why subs get scoped like lexicals.
> I didn't want to use too heavy stuff (PerlSetVar or the module recently
> discussed here - was it Apache::Storage?)
> because I just wanted some shortcuts for the scope of the .conf file
> only. It was better to cut-n-paste them in the worst case than carve
> them in Apache brains, stealing the precious memory
> from mod_perl :-).
> -Original Message-
> From: Stas Bekman [mailto:[EMAIL PROTECTED]]
> Sent: Monday, March 12, 2001 8:39 PM
> To: Khachaturov, Vassilii
> Cc: '[EMAIL PROTECTED]'
> Subject: Re: incompat. with apache/mod_perl upgrade
>
> ...
> >
> > sub WWW_DIR () { $ENV{'HOME'} . '/www' ; } # this sub will persist to next
> >
> > ... more code, using WWW_DIR sometimes
> >
> >
> > .. more plain apache conf stuff here
> >
> >
> > $AxCacheDir = WWW_DIR . '/htdocs/x/cache';
> >
> >
> > While this worked before, it now generates an undef sub called at the
> second
> ...
> > Was this change intentionally done (why?!), or is it a by-product of some
> > other code advances?
> > What is the correct way of passing Perl stuff from one section to
> > another?
>
> Please read
> http://perl.apache.org/guide/config.html#Apache_Configuration_in_Perl
> and you will understand how C sections work.
>
> I also don't understand why are you trying to use sub to define a
> variable, which is pretty useless, since you use it only during
> configuration. Also use the constant pragma.
>
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
RE: incompat. with apache/mod_perl upgrade
Read it. It still doesn't address my questions
- why this stopped working with
the new mod_perl+apache. From the docs, rather, I'd expect a
routine or a variable defined in one section persist to the other.
While I can't use global vars (they try to get tied to the non-existing
config. params), and lexicals remain scoped within the same
section, I had to use a sub before, which I was able to access in
the other Perl section. Now I am not. The docs say, however, I
am eval-ed in Apache::ReadConfig - o.k., so the subs should get
defined there and then remain there, as long as the same config
file is read?
I didn't want to use too heavy stuff (PerlSetVar or the module recently
discussed here - was it Apache::Storage?)
because I just wanted some shortcuts for the scope of the .conf file
only. It was better to cut-n-paste them in the worst case than carve
them in Apache brains, stealing the precious memory
from mod_perl :-).
-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 12, 2001 8:39 PM
To: Khachaturov, Vassilii
Cc: '[EMAIL PROTECTED]'
Subject: Re: incompat. with apache/mod_perl upgrade
...
>
> sub WWW_DIR () { $ENV{'HOME'} . '/www' ; } # this sub will persist to next
>
> ... more code, using WWW_DIR sometimes
>
>
> .. more plain apache conf stuff here
>
>
> $AxCacheDir = WWW_DIR . '/htdocs/x/cache';
>
>
> While this worked before, it now generates an undef sub called at the
second
...
> Was this change intentionally done (why?!), or is it a by-product of some
> other code advances?
> What is the correct way of passing Perl stuff from one section to
> another?
Please read
http://perl.apache.org/guide/config.html#Apache_Configuration_in_Perl
and you will understand how C sections work.
I also don't understand why are you trying to use sub to define a
variable, which is pretty useless, since you use it only during
configuration. Also use the constant pragma.
Re: incompat. with apache/mod_perl upgrade
On Mon, 12 Mar 2001, Khachaturov, Vassilii wrote:
> When I upgraded from
> Solaris Apache/1.3.14 (Unix) mod_perl/1.24_01
> to
> Solaris Apache/1.3.17 (Unix) mod_perl/1.25
>
> the following code in my debugging httpd.conf broke:
>
>
> sub WWW_DIR () { $ENV{'HOME'} . '/www' ; } # this sub will persist to next
>
> ... more code, using WWW_DIR sometimes
>
>
> .. more plain apache conf stuff here
>
>
> $AxCacheDir = WWW_DIR . '/htdocs/x/cache';
>
>
> While this worked before, it now generates an undef sub called at the second
>
> section. Redefining it there again works, but emits strange prototype
> mismatch stuff
> at the 2nd calling of the routine.
> To restore the old behavior I had to define it again without the brackets
> (the args
> prototype) at the 2nd section.
>
> Was this change intentionally done (why?!), or is it a by-product of some
> other code advances?
> What is the correct way of passing Perl stuff from one section to
> another?
Please read
http://perl.apache.org/guide/config.html#Apache_Configuration_in_Perl
and you will understand how C sections work.
I also don't understand why are you trying to use sub to define a
variable, which is pretty useless, since you use it only during
configuration. Also use the constant pragma.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: $r and Registry(NG)* scripts
On Mon, 12 Mar 2001, Daniel wrote: > Just trying to get a consensus on people's usage of the apache request > object in Registry(NG)* scripts. > > I usually make the $r available as a global variable so I can use in > various subroutines without passing it around constantly. All scripts on > site start with: > > use vars qw(%input $r); > $r = Apache->request; > > This has worked fine...no complaints in log files...until I switched the > handler from Registry to RegistryNG; > > Now I see occasional: > Variable "$r" will not stay shared at /home/httpd/perl/daily-news.pl > line 9 (#1) > in log files. http://perl.apache.org/guide/troubleshooting.html#Value_of_x_will_not_stay_shared > first nine from daily-news.pl: > #!/usr/bin/perl -w > use strict; > use DBI; > use date_site; > my $dateformat = date_site::dateformat; > use Apache::Request; > > use vars qw($dbh %input %output %filebase $r %sites); #vars used on $r > $r = Apache->request; #<--here > > > Any ideas on why this would happen? > > Thanks in advance, > > -- > Daniel Bohling > NewsFactor Network > _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
incompat. with apache/mod_perl upgrade
When I upgraded from
Solaris Apache/1.3.14 (Unix) mod_perl/1.24_01
to
Solaris Apache/1.3.17 (Unix) mod_perl/1.25
the following code in my debugging httpd.conf broke:
sub WWW_DIR () { $ENV{'HOME'} . '/www' ; } # this sub will persist to next
... more code, using WWW_DIR sometimes
.. more plain apache conf stuff here
$AxCacheDir = WWW_DIR . '/htdocs/x/cache';
While this worked before, it now generates an undef sub called at the second
section. Redefining it there again works, but emits strange prototype
mismatch stuff
at the 2nd calling of the routine.
To restore the old behavior I had to define it again without the brackets
(the args
prototype) at the 2nd section.
Was this change intentionally done (why?!), or is it a by-product of some
other code advances?
What is the correct way of passing Perl stuff from one section to
another?
Vassilii
Re: mod_perl.c:517: unterminated string or character constant
actually - with recent changes to the apache core, that patch doesn't work
any more. we're working on a real fix - but in the mean time this one may
as well be removed.
sterling
_
Index: src/modules/perl/mod_perl.c
===
RCS file: /home/cvspublic/modperl/src/modules/perl/mod_perl.c,v
retrieving revision 1.135
diff -u -r1.135 mod_perl.c
--- src/modules/perl/mod_perl.c 2001/02/16 23:30:27 1.135
+++ src/modules/perl/mod_perl.c 2001/03/13 00:18:07
@@ -509,18 +509,6 @@
{
array_header *librefs;
-#ifdef WIN32
-// This is here to stop a crash when bringing down
-// a service. Apparently the dso is unloaded too early.
-// This if statement tests to see if we are running as a
-// service. apache does the same
-// see apache's isProcessService() in service.c
-if (AllocConsole()) {
-FreeConsole();
-return;
-}
-#endif
-
librefs = xs_dl_librefs((pool *)data);
perl_shutdown(NULL, NULL);
unload_xs_so(librefs);
Re: to clarify (getting what was printed in PerlHandler)
[EMAIL PROTECTED] (JR Mayberry) wrote: >Is it possible to retreive what was printed in the PerlHandler phase >(what was called w/ $r->print()), in any of the post PerlHandler phases? [EMAIL PROTECTED] (JR Mayberry) wrote: >a way to do it transparently...(ie: not changing code) > >i realize there are ways to do it otherwise.. Which code do you not want to change? Some code *somewhere* is going to have to change, or else (obviously) nothing different is going to happen. There are several ways to do this without changing any of the print statements, is that what you mean? ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
to clarify (getting what was printed in PerlHandler)
a way to do it transparently...(ie: not changing code) i realize there are ways to do it otherwise..
Re: getting content post PerlHandler phase
[EMAIL PROTECTED] (JR Mayberry) wrote: >Is it possible to retreive what was printed in the PerlHandler phase (what >was called w/ $r->print()), in >any of the post PerlHandler phases? Perhaps you want something like Apache::Filter? ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
getting content post PerlHandler phase
Is it possible to retreive what was printed in the PerlHandler phase (what was called w/ $r->print()), in any of the post PerlHandler phases? Thanks.
$r and Registry(NG)* scripts
Just trying to get a consensus on people's usage of the apache request object in Registry(NG)* scripts. I usually make the $r available as a global variable so I can use in various subroutines without passing it around constantly. All scripts on site start with: use vars qw(%input $r); $r = Apache->request; This has worked fine...no complaints in log files...until I switched the handler from Registry to RegistryNG; Now I see occasional: Variable "$r" will not stay shared at /home/httpd/perl/daily-news.pl line 9 (#1) in log files. first nine from daily-news.pl: #!/usr/bin/perl -w use strict; use DBI; use date_site; my $dateformat = date_site::dateformat; use Apache::Request; use vars qw($dbh %input %output %filebase $r %sites); #vars used on $r $r = Apache->request; #<--here Any ideas on why this would happen? Thanks in advance, -- Daniel Bohling NewsFactor Network
mod_perl.c:517: unterminated string or character constant
Hi all ...
didnt know where else to send this so subscribed just now.
When compiling Apache 1.3.19 with mod_perl 1.25 and mod_ssl 2.8.1
I get the following:
...
===> src/modules/perl
gcc -fpic -O3 -I/usr/local/lib/perl5/5.00503/alpha-dec_osf/CORE -ansi
-I/usr/local/include -DLANGUAGE_C -DMOD_PERL_VERSION=\"1.25\"
-DMOD_PERL_STRING_VERSION=\"mod_perl/1.25\" -I../../os/unix -I../../include
-DOSF1 -DMOD_SSL=208101 -DMOD_PERL -DUSE_HSREGEX -DEAPI -DUSE_EXPAT
-I../../lib/expat-lite `../../apaci` -c mod_perl.c && mv mod_perl.o mod_perl.lo
mod_perl.c:517: unterminated string or character constant
make[4]: *** [mod_perl.lo] Error 1
make[3]: *** [all] Error 1
make[2]: *** [subdirs] Error 1
make[2]: Leaving directory `/tmp/apache/build2/apache_1.3.19/src'
make[1]: *** [build-std] Error 2
make[1]: Leaving directory `/tmp/apache/build2/apache_1.3.19'
make: *** [build] Error 2
Particulars:
perl 5.00503
gcc 2.8.1
Tru64 4.0F, no patches
A quick search on the geocrawler archive didnt turn up anything so
I decided to letter'rip. I know my gcc install is kinda funky but
it has installed mod_perl 3 times before w/out problems.
Anyway, stupid little patch that made it work for me is below.
It just brackets a comment in the #ifdef with /* ... */
So ... just in case anyone else searches the archives for this ...
/b
--- Begin Patch ---
# diff -c mod_perl.c.orig mod_perl.c
*** mod_perl.c.orig Mon Mar 12 16:43:25 2001
--- mod_perl.c Mon Mar 12 16:39:04 2001
***
*** 510,520
array_header *librefs;
#ifdef WIN32
! // This is here to stop a crash when bringing down
// a service. Apparently the dso is unloaded too early.
// This if statement tests to see if we are running as a
// service. apache does the same
! // see apache's isProcessService() in service.c
if (AllocConsole()) {
FreeConsole();
return;
--- 510,520
array_header *librefs;
#ifdef WIN32
! /* This is here to stop a crash when bringing down
// a service. Apparently the dso is unloaded too early.
// This if statement tests to see if we are running as a
// service. apache does the same
! // see apache's isProcessService() in service.c */
if (AllocConsole()) {
FreeConsole();
return;
--- End Patch ---
Re: mod_perl shared memory with MM
Sorry for taking a while to get back to this, road trips can be good at interrupting the flow of life. It depends on the application. I typically use a few instances of open() for the sake of simplicity, but I have also had decent luck with IPC::Open(2|3). The only problems I've had with either was an OS specific bug with Linux (the pipe was newline buffering and dropping all characters over 1023, moved to FreeBSD and the problem went away). Words of wisdom: start slow because debugging over a pipe can be a headache (understatement). Simple additions + simple debugging = good thing(tm). I've spent too many afternoons/nights ripping apart these kinds of programs only to find a small type-o and then reconstructing a much larger query/response set of programs. -sc PS You also want to attach the program listening to the named pipe to something like DJB's daemon tools (http://cr.yp.to/daemontools.html) to prevent new requests from blocking if the listener dies: bad thing(tm). On Wed, Feb 28, 2001 at 10:23:06PM -0500, Adi Fairbank wrote: > Delivered-To: [EMAIL PROTECTED] > Date: Wed, 28 Feb 2001 22:23:06 -0500 > From: Adi Fairbank <[EMAIL PROTECTED]> > X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i586) > X-Accept-Language: en > To: Sean Chittenden <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED] > Subject: Re: mod_perl shared memory with MM > > Sean, > > Yeah, I was thinking about something like that at first, but I've never played > with named pipes, and it didn't sound too safe after reading the perlipc man > page. What do you use, Perl open() calls, IPC::Open2/3, IPC::ChildSafe, or > something else? How stable has it been for you? I just didn't like all those > warnings in the IPC::Open2 and perlipc man pages. > > -Adi > > Sean Chittenden wrote: > > > > The night of Fat Tuesday no less... that didn't help any > > either. ::sigh:: > > > > Here's one possibility that I've done in the past becuase I > > needed mod_perl sessions to be able to talk with non-mod_perl > > programs. I setup a named bi-directional pipe that let you write a > > query to it for session information, and it wrote back with whatever > > you were looking for. Given that this needed to support perl, java, > > and c, it worked _very_ well and was extremely fast. Something you > > may also want to consider because it keeps your session information > > outside of apache (incase of restart of apache, or desire to > > synchronize session information across multiple hosts). > > > > -sc > > > -- Sean Chittenden[EMAIL PROTECTED] PGP signature
RE: mod_perl and Apache::SIG "User pressed Stop button" Case
> -Original Message-
> From: Stas Bekman [SMTP:[EMAIL PROTECTED]]
> Sent: Saturday, March 10, 2001 11:17 PM
> To: Raphael Arlitt
> Cc: [EMAIL PROTECTED]
> Subject: Re: mod_perl and Apache::SIG "User pressed Stop button" Case
>
> On 11 Mar 2001, Raphael Arlitt wrote:
>
> > Hi,
> > I need to get modperl scripts get stopped by apache when
> > the user hits the Stop button in its browser.
> > There is a section at
> >
> http://www.perldoc.com/cpan/Apache/Example.html#Handling%20the%20'User%20p
> ressed%20Stop%20button'%20case
> > where exactly this is explained. Hm - they mention the
> > following script which does an infinite loop. It does not
> > stop in my environment. Where in httpd.conf does the
> > PerlFixupHandler Apache::SIG go? Does anybody has a snippet
> > from his/hers httpd.conf for me?
> >
> > httpd/cgi-bin > cat stopping_detector2.pl
> > my $r = shift;
> > $r->send_http_header('text/plain');
> >
> > print "PID = $$\n";
> > $r->rflush;
> >
> > while(1){
> > $r->print("\0");
> > $r->rflush;
> >
> > last if $r->connection->aborted;
> >
> > $i++;
> > sleep 1;
> > }
>
> I don't know what version of the guide they store on perldoc.com. I
> suppose they convert it automatically from the sources on CPAN, which
> explains broken links and incorrectly interpreted tags. You should read
> http://perl.apache.org/guide/ instead.
>
> As for your question, you don't need Apache::SIG, when you use
>
> last if $r->connection->aborted;
>
> However I don't know about Win32, may be Apache works differently there.
> It works on Unix.
>
Above script works on Win32 also.
Apache/1.3.14 (Win32) mod_perl/1.24_02-dev running...
> > Please reply also by email..
> >
> > Help is appreciated :-)
> >
> > Here is my installation data:
> >
> > Apache/1.3.14 (Unix) (SuSE/Linux)
> > mod_perl/1.24
> >
> > By the way - I read at www.perldoc.com that mod_perl is considered alpha
> at
> > win32... I am in the need of setting it up on win2000 with industrial
> > strength. Is that feasible?
> >
> > Raphael
> >
My experience w/ mod_perl on Win32 (NT 4.0) is quite recent, and
only for development purposes.
I can't make a recommendation for or against.
Re: Apache request object
On Mon, 12 Mar 2001, Gene Dascher wrote: > How can I access the Apache Request object from a Perl package that I am > calling from a Perl Authorization handler? $r is the first argument passed to your handler. my $r = shift; > I tried using the following code in TestPackage.pm: > > my $r = Apache->request(); > my $s = $r->server; > > but the error I get is: Can't call method "server" on an undefined value. That should work as well, although it's slower. Something might be wrong with your build if this is failing. - Perrin
RE: Passing Objects with PerlSetVar
> -Original Message- > From: darren chamberlain [mailto:[EMAIL PROTECTED]] > Sent: Monday, March 12, 2001 12:54 PM > To: [EMAIL PROTECTED] > Subject: Re: Passing Objects with PerlSetVar > > > Ken Williams ([EMAIL PROTECTED]) said something to > this effect on 03/12/2001: > > [EMAIL PROTECTED] (darren chamberlain) wrote: > > >I just found Apache::Storage > http://tangent.org/Apache-Storage/>, > > >which will let you store complex data structures from httpd.conf: > > I wonder why I've never heard of this module before. It > looks like it's > > never been discussed on the list, and it's not in the module list. > > It's not on CPAN, as far as I know; I came across it on > Freshmeat (http://freshmeat.net/projects/apachestorage/>). > The Freshmeat main branch is dated Feb 17, so it's pretty new. http://www.cpan.org/modules/by-module/Apache/Apache-Storage-1.1.tar.gz --Geoff > > It's the same guy who maintains mod_layout, if that means > anything to anyone. > > (darren) > > -- > A sect or party in an elegant incognito devised to save a man from the > vexation of thinking. > -- Ralph Waldo Emerson >
Re: Passing Objects with PerlSetVar
Ken Williams ([EMAIL PROTECTED]) said something to this effect on 03/12/2001: > [EMAIL PROTECTED] (darren chamberlain) wrote: > >I just found Apache::Storage http://tangent.org/Apache-Storage/>, > >which will let you store complex data structures from httpd.conf: > I wonder why I've never heard of this module before. It looks like it's > never been discussed on the list, and it's not in the module list. It's not on CPAN, as far as I know; I came across it on Freshmeat (http://freshmeat.net/projects/apachestorage/>). The Freshmeat main branch is dated Feb 17, so it's pretty new. It's the same guy who maintains mod_layout, if that means anything to anyone. (darren) -- A sect or party in an elegant incognito devised to save a man from the vexation of thinking. -- Ralph Waldo Emerson
Re: Passing Objects with PerlSetVar
[EMAIL PROTECTED] (darren chamberlain) wrote:
>I just found Apache::Storage http://tangent.org/Apache-Storage/>,
>which will let you store complex data structures from httpd.conf:
>
># httpd.conf
>ApacheStore o { "bar" => 1, "foo" => "com", "other" => 0 }
>
>In your handler, do:
>
>use Apache::Storage;
>sub handler {
>my $r = shift;
>my $o = get_storage('o');
>
>...
>
>And so on.
I wonder why I've never heard of this module before. It looks like it's
never been discussed on the list, and it's not in the module list.
------
Ken Williams Last Bastion of Euclidity
[EMAIL PROTECTED]The Math Forum
[DIGEST] mod_perl digest 03/10/01
-- mod_perl digest March 4, 2001 - March 10, 2001 -- Recent happenings in the mod_perl world... Features o mod_perl status o module announcements o mailing list highlights o links mod_perl status o mod_perl - stable: 1.25 (released January 29, 2001) [1] - development: 1.25_01-dev [2] o Apache - stable: 1.3.19 (released February 28, 2001) [3] - development: 1.3.20-dev [4] o Perl - stable: 5.6 (released March 23, 2000) [5] - development: 5.7 [6] module announcements o Apache::ProxyRewrite 0.13 - a reverse-proxy that will rewrite URLs embedded in HTML documents [7] mailing list highlights o Shared memory seemed to be the discussion of the week: Cache::Cache 0.03 was announced on the list [8], along with some discussion of possible new features This thread from late February [9] discussing most of the shared memory modules was resurrected again before going OT [10] o In case you didn't already know, September 8, 2001 represents yet another chapter in Y2K-esque date problems [11] o When using push_handlers() with method handlers, the Apache request object is not automatically passed to your handler. [12] o If you need to get really particular with your Apache layout, checkout the APACI argument --with-layout [13] links o The Apache/Perl Integration Project [14] o mod_perl documentation [15] o mod_perl modules on CPAN [16] o mod_perl homepage [17] o mod_perl news and advocacy [18] o mod_perl list archives [19] [20] happy mod_perling... --Geoff [EMAIL PROTECTED] -- [1] http://perl.apache.org/dist/ [2] http://perl.apache.org/from-cvs/modperl/ [3] http://www.apache.org/dist/ [4] http://dev.apache.org/from-cvs/apache-1.3/ [5] http://www.perl.com/pub/language/info/software.html#stable [6] http://www.perl.com/pub/language/info/software.html#devel [7] http://forum.swarthmore.edu/epigone/modperl/plimflilkhel [8] http://forum.swarthmore.edu/epigone/modperl/whoxpralskimp [9] http://forum.swarthmore.edu/epigone/modperl/twerdgraxclimp [10] http://forum.swarthmore.edu/epigone/modperl/kerdjorstand [11] http://forum.swarthmore.edu/epigone/modperl/porstimpblend [12] http://forum.swarthmore.edu/epigone/modperl/spewinggal [13] http://forum.swarthmore.edu/epigone/modperl/swoskoncla [14] http://perl.apache.org [15] http://perl.apache.org/#docs [16] http://www.cpan.org/modules/by-module/Apache/ [17] http://www.modperl.com [18] http://www.take23.org [19] http://forum.swarthmore.edu/epigone/modperl/ [20] http://marc.theaimsgroup.com/?l=apache-modperl&r=1&w=2
Re: [OT] JMS-like event framework for Perl
* Michael A. Nachbaur ([EMAIL PROTECTED]) [010310 14:25]: > Since today seems to be "The Day of the Off Topic(tm)", I thought I'd jump > in with my question. > > Is there a event messaging framework available for Perl, similar to JMS? > I'd like to be able to have an object registered as a handler for certain > "events", and have perl code throw those events causing the object to be run > automatically (publish / subscribe model). > > I could probably implement something like this to finish my project, but I'd > rather not do a one-off. Does anyone know of anything that can accomodate > this functionality? If I'm the first one trying to modularize this, what > features would you like to see? Hi Michael, Just to put another 2 cents in -- I have this exact same idea and interest. I setup a project on Sourceforge for it (sourceforge.net/projects/perlmq/) but haven't been able to put together an initial ideas document yet. (Real life intrudes.) JMS seems to me a good model to follow as well. Why not use all that hard work lots of people have already done? :-) My initial thoughts were to base both the client and server around POE. Messages would be standard objects but would have different types of payloads: scalar, hash, array, object, XML document. SOAP would be another way to request/send messages as well. There is a mailing list on the sourceforge site to which we can move all this discussion, if you'd like. (That way it will all be archived in one place :-) Thanks! Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Apache request object
How can I access the Apache Request object from a Perl package that I am
calling from a Perl Authorization handler?
Example:
Package TestPackage.pm
---
Package Apache::TestPackage.pm
@EXPORT qw ($home_url);
my $home_url = "http:" . "//" . $ENV{'SERVER_NAME'};
1;
---
Handler TestHandler.pm
---
Package Apache::TestHandler.pm
use Apache::TestPackage.pm
sub handler()
{
my $r = shift;
$r->log_error("Home URL = $home_url");
return OK;
}
1;
-
When I use the handler above, the $home_url does not print out because the
$ENV{'SERVER_NAME'} has not been set at the time that the TestHandler is
called.
I tried using the following code in TestPackage.pm:
my $r = Apache->request();
my $s = $r->server;
but the error I get is: Can't call method "server" on an undefined value.
I also tried using the server_name() function from CGI, but that also relies
on the $ENV{'SERVER_NAME'} as well. I get $home_url = "localhost" when I
call that function from the Package.
Thanks,
Gene Dascher
