Re: unable to makefile of the modperl

2001-05-04 Thread Anuradha Satyanarayana




Thanks a  lot !!!
After all i got a reply. I am still stuck with the same problem.
I have already installed LW P modules, HTML::HeadParser is also installed,
Apache 1.3.4, libwwwp, and all the other modules. Still then i am getting
these daignostic messages.
In some mails in the mailing list, some guy had got the same problem and u
had mentioned him to upgrade his Apache  Version.  Please tell me if i need
to do so.
I have Apache1.3.4  installed on my machine and modperl 1.25 version.
The problem comes once i give the Makefile command.
Perl Makefile  APACHE_SRC=../../src  NO_HTTPD=1 USE APACI=1 EVERYTHING=1
I have thoroughly gone throught the documentation but could not find any
exact answer.
Will be waiting for your reply.
Thanks and regards
Anuradha





Stas Bekman wrote:

 On Thu, 3 May 2001, Anuradha Satyanarayana wrote:

  Unable to make the modperl Makefile.PL downloaded from perl.apache.org.
  throwing errors like the following:
 
 
  Checking for LWP::UserAgent..failed
  Can't locate HTTP/Request.pm in @INC at lib/LWP/UserAgent.pm line 97.
  BEGIN failed--compilation aborted at lib/LWP/UserAgent.pm line 97.
 
  The libwww-perl library is needed to run the test suite.
  Installation of this library is recommended, but not required.
 
  Checking for HTML::HeadParserfailed
  Can't locate HTML/HeadParser.pm in @INC at Makefile.PL line 1129.
 
 
  Can anyone help?

 Aren't the diagnostic messages clear enough? You need to install these
 modules before you build mod_perl (at least to run 'make test')...

 One of the easy ways to do that:

 $ perl -MCPAN -eshell
 cpan install LWP::UserAgent HTML::HeadParser

 Hope this helps...

 P.S. Make sure you read various and copious mod_perl documentation before
 it starts raining here on the list :) See http://perl.apache.org/#docs

 _
 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://eXtropia.com/
 http://singlesheaven.com http://perl.apache.org http://perlmonth.com/




installing perl-win32-bin-0.6.exe on win98

2001-05-04 Thread David Lanzarote García

 Hello,
 I've tried to install perl-win32-bin-0.6.exe on win98, and the error:
cannot load /apache/modules/apachemoduleperl into server appears.
 I've revised the paths and I think they're ok, so I don't know how to
solve this..
 thanks for your ideas...




install perl-win32-bin-0.6.exe on win98

2001-05-04 Thread David Lanzarote García

 Hello,
 I've tried to install perl-win32-bin-0.6.exe on win98, and the error:
cannot load /apache/modules/apachemoduleperl into server appears.
 I've revised the paths and I think they're ok, so I don't know how to
solve this..
 thanks for your ideas... 




Apache::Session::Flex

2001-05-04 Thread Tatsuhiko Miyagawa

Hi, 

Apache::Session::Flex doesn't work well when restoring object with
existing session id. It is because Apache::Session tries to call
A::S::Generate::* (currently MD5 only) class's validate() method
which Apache::Session::Flex doesn't set.

Patch below fixes this.

--- Flex.pm.origFri May  4 22:00:13 2001
+++ Flex.pm Fri May  4 22:11:48 2001
@@ -42 +42,2 @@
-eval '$incl-{$gen} = \' . $gen . '::generate' || die $@;
+eval '$incl-{$gen}-[0] = \' . $gen . '::generate' || die $@;
+eval '$incl-{$gen}-[1] = \' . $gen . '::validate' || die $@;
@@ -53 +54,2 @@
-$self-{generate} = $incl-{$gen};
+$self-{generate} = $incl-{$gen}-[0];
+$self-{validate} = $incl-{$gen}-[1];


--
Tatsuhiko Miyagawa   Livin' On The EDGE, Co.,Ltd.
mailto:[EMAIL PROTECTED] http://www.edge.co.jp/




Throwing die in Apache::Registry

2001-05-04 Thread Mark Maunder

Hi,

I'm sure this has been discussed, appologies if it has, but I scoured the lists
and docs and didn't get any help.

I have an Apache::Registry script that is using XML::Parser. The parser throws a
'die' call if it encounters a parse error (Why?). I was handling this by putting
the code in an eval block, but this no longer works since all Registry scripts
are already in one huge eval block. So whenever I get a parse error, my code
ignores my eval block which encapsulates it and jumps to the end of the Registry
eval block and effectivelly exits. How does one 'eval' code that might call 'die'
under Apache::Registry?

Mark.





Re: Throwing die in Apache::Registry

2001-05-04 Thread Stas Bekman

On Fri, 4 May 2001, Mark Maunder wrote:

 Hi,

 I'm sure this has been discussed, appologies if it has, but I scoured the lists
 and docs and didn't get any help.

 I have an Apache::Registry script that is using XML::Parser. The parser throws a
 'die' call if it encounters a parse error (Why?). I was handling this by putting
 the code in an eval block, but this no longer works since all Registry scripts
 are already in one huge eval block. So whenever I get a parse error, my code
 ignores my eval block which encapsulates it and jumps to the end of the Registry
 eval block and effectivelly exits. How does one 'eval' code that might call 'die'
 under Apache::Registry?

http://perl.apache.org/guide/perl.html#Exception_Handling_for_mod_perl


_
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: Throwing die in Apache::Registry

2001-05-04 Thread Perrin Harkins

on 5/4/01 9:28 AM, Mark Maunder at [EMAIL PROTECTED] wrote:
 I have an Apache::Registry script that is using XML::Parser. The parser throws
 a
 'die' call if it encounters a parse error (Why?).

Because it's an exception and the parser can't continue.

 I was handling this by
 putting
 the code in an eval block, but this no longer works since all Registry scripts
 are already in one huge eval block.

It should still work.  An eval{} is scoped like any other block.  Maybe you
have a typo?  Post your code and we'll look at it.

- Perrin




Regarding modperl installation (fwd)

2001-05-04 Thread Stas Bekman

Gosh, sometimes I feel like I've forked the mod_perl mailing list :(

-- Forwarded message --
Date: Fri, 4 May 2001 16:26:16 +0530
From: Qazi Firdous Ahmed [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Regarding modperl installation

Hi..

After having gone through your installation steps, i tried installing
with the same during which i encountered a couple of issues to be
resolved. I would request you to guide me in this regard.
I have attached a file wherein the results of Makefile command  and the
issues are to be seen.
Further i am using Apache Version 1.3.14, modperl version 1.25,
libwww-perl5.53 which i downloaded from cpan and apache.org.
I tried to put the various missing modules in one of the
directories(directories given by perl-v command), but still it is giving
the errors.
This is very critical for the project i am working on.
Hope to get your expertised guidance for the same.

Thanking you in anticipation
Qazi Firdous Ahmed


 mod_perl


Re: Throwing die in Apache::Registry

2001-05-04 Thread Mark Maunder

OK this is a little embarrasing... I assumed the script was die'ing when it hit the
XML::Parser routine and that eval wasn't catching the exception. Well the Apache
child is actually segfaulting. (Excuse: I'm running virtual hosts with seperate
logs. I didn't check the main error_log.). I checked the list archive and there's
tons of documentation about this and I think I saw a patch. (If anyone has more info
though, I'd appreciate it.) I'm running XML::Parser 2.30.

Thanks for the help and sorry about the time waster :)

Perrin Harkins wrote:

 on 5/4/01 9:28 AM, Mark Maunder at [EMAIL PROTECTED] wrote:
  I have an Apache::Registry script that is using XML::Parser. The parser throws
  a
  'die' call if it encounters a parse error (Why?).

 Because it's an exception and the parser can't continue.

  I was handling this by
  putting
  the code in an eval block, but this no longer works since all Registry scripts
  are already in one huge eval block.

 It should still work.  An eval{} is scoped like any other block.  Maybe you
 have a typo?  Post your code and we'll look at it.

 - Perrin

--
Mark Maunder
[EMAIL PROTECTED]
http://swiftcamel.com/

 Try not.
 Do.
 Or do not.
 There is no try.
 ~yoda





Re: install perl-win32-bin-0.6.exe on win98

2001-05-04 Thread Randy Kobes

On Fri, 4 May 2001, David Lanzarote García wrote:

  Hello,
  I've tried to install perl-win32-bin-0.6.exe on win98, and the error:
 cannot load /apache/modules/apachemoduleperl into server appears.
  I've revised the paths and I think they're ok, so I don't know how to
 solve this..
  thanks for your ideas... 
 

If you're using thispackage, then you must also use the Perl
and Apache binaries that come with it. Is that the case? 
Alternatively, if you're using ActivePerl, there's mod_perl
ppms available at http://theoryx5.uwinnipeg.ca/ppmpackages/
that you can install with the ppm utility.

best regards,
randy kobes





RE: Insecure dependency errors

2001-05-04 Thread Barry Veinotte


 -Original Message-
 From: Stas Bekman [mailto:[EMAIL PROTECTED]]
 Sent: Thursday, May 03, 2001 11:56 PM
 To: Cees Hek
 Cc: Barry Veinotte; [EMAIL PROTECTED]
 Subject: Re: Insecure dependency errors 
 
 
 On Fri, 4 May 2001, Cees Hek wrote:
 
  On Thu, 3 May 2001, Barry Veinotte wrote:
 
   [Thu May  3 15:06:57 2001] [error] Insecure dependency in open while
   running with -T switch at 
/usr/local/www/vhosts/ad-eagle.com/cgi-bin/ad-eagle/lib/AdEagle.pm line 472.
 
   The scripts using the .pm are running under Apache::Registry and have been 
running
   fine. Then last night a major upgrade was done to the servers. Now the scripts 
are
   dying with this error. None of them are running -T   I don't think any on the 
server are,
   and know none under Apache::Registry are.
 
   Only Apache::Registry scripts are being affected. Anyone have any ideas as to
   where I could start looking?
 
 % perldoc perlsec
 
  Check your Apache config files for  PerlTaintCheck On, and check all your
  registry scripts for the -T switch.  Also, taint checking is automatically
  turned on when scripts are run setuid (I don't know if that can affect
  Registry scripts, but it's probably worth checking the file permissions on
  all your scripts and modules)
 
 -T doesn't affect mod_perl scripts, only PerlTaintCheck. The same goes for
 setuid, Apache::Registry scripts aren't executed as plain perl scripts.
 Instead they are being read as plain files, placed into the handler()
 function (and the package) and only then executed.
 
 See: http://perl.apache.org/guide/porting.html#Taint_Mode
 _
 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://eXtropia.com/
 http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
 

 Thanks for the words of wisdom Gents. These errors were not occuring before the 
admins did their major upgrade so I knew the code was okay. However, after verifying 
a
few times that there was nothing setuid or containg a -T switch, and wasting a day and 
a
half on searching for the cause of these senseless errors,  I found a fix.  REBOOT

I still don't know why mod_perl thought I was throwing a  -T  at it, but rebooting the 
box shook it loose.

Doh!

Barry




Re: Regarding modperl installation (fwd)

2001-05-04 Thread G.W. Haywood

Hi Stas,

On Sat, 5 May 2001, Stas Bekman wrote:

 Gosh, sometimes I feel like I've forked the mod_perl mailing list :(

Yeah, I know what you mean.  Allow me...

 -- Forwarded message --
 Date: Fri, 4 May 2001 16:26:16 +0530
 From: Qazi Firdous Ahmed [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: Regarding modperl installation

 After having gone through your installation steps, i tried installing
 with the same during which i encountered a couple of issues to be resolved.

Building mod_perl takes place in several steps.

Simplified, the steps are:

1. Get the sources and unpack them.  (% tar xzvf )
2. Create your Makefile.   (% perl Makefile.pl)
3. Compile.  (% make)
4. Test. (% make test)
5. Install.  (# make install) 
6. Configur. (# emacs,vi,edlin...)

You have completed the first two, and sent the results from the
second.  There is nothing seriously wrong with the output but you have
not properly installed the modules required to preform one of the
steps.  Fortunately this step ('make test') is optional.  You can
install mod_perl without doing it.  So all you have to do now is steps
four and five.  As you see, you usually do the install as user 'root'
but the others can be done as any user.

Unfortunately you have an old version of Perl (5.004) so you should
heed the advice of the build scripts and upgrade.  I would suggest
version 5.005_03.  You must compile Perl, Apache and mod_perl with 
the same compiler.

 Further i am using Apache Version 1.3.14, modperl version 1.25,

While you are rebuilding Perl, I'd suggest starting again with version
1.3.19 of Apache.

 libwww-perl5.53 which i downloaded from cpan and apache.org.  I
 tried to put the various missing modules in one of the
 directories(directories given by perl-v command), but still it is
 giving the errors.

Don't worry about it for now.  Try using the CPAN shell next time.

perl -MCPAN -eshell

 This is very critical for the project i am working on.

I hope you have some time for reading...

 Hope to get your expertised guidance for the same.

...http://perl.apache.org/guide

73,
Ged.




Re: Regarding modperl installation (fwd)

2001-05-04 Thread Jeffrey W. Baker



On Sat, 5 May 2001, Stas Bekman wrote:

 Gosh, sometimes I feel like I've forked the mod_perl mailing list :(

You get the most astonishing emails from these consultant types.

Infosys is a world leader in providing IT consulting and software
services[.] [1]

From the world consulting leader comes this amazing request.  The
requestor is working on an important assignment, and mod_perl is very
critical to the assignment.  No doubt the requestor needs some help, else
his client might get snippy.  As they should, since the person assigned to
this important project has obviously never installed a Perl module before,
and cannot even read the first line of stdout, exhorting him to install
Perl 5.004_04.

Anyway, we know how this world leader feels about Perl:

Serious CGI-based web applications use native executables, since
scripting languages are very slow.

...and web server APIs, like the one mod_perl exposes:

For web-bases software product, it is not worth [it] to risk the chances
of crashing the web servers, and portability is bad, leading to very high
development costs relative to other means. [2]

Even when I am in a good mood, paid consultants looking for free advice
ruffle my feathers.  When I'm in a bad mood, it warrants a response.

-jwb

[1] http://www.infy.com/
[2] http://www.infy.com/corporate/thought-papers/technical_alternatives_jan18.doc


 -- Forwarded message --
 Date: Fri, 4 May 2001 16:26:16 +0530
 From: Qazi Firdous Ahmed [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: Regarding modperl installation

 Hi..

 After having gone through your installation steps, i tried installing
 with the same during which i encountered a couple of issues to be
 resolved. I would request you to guide me in this regard.
 I have attached a file wherein the results of Makefile command  and the
 issues are to be seen.
 Further i am using Apache Version 1.3.14, modperl version 1.25,
 libwww-perl5.53 which i downloaded from cpan and apache.org.
 I tried to put the various missing modules in one of the
 directories(directories given by perl-v command), but still it is giving
 the errors.
 This is very critical for the project i am working on.
 Hope to get your expertised guidance for the same.

 Thanking you in anticipation
 Qazi Firdous Ahmed






Re: Throwing die in Apache::Registry

2001-05-04 Thread Tom Harper

Mark--

While you may be having problems with segfaults because
of expat = yes rule--  i was having similar problems
with XML parser relating to the the die statement.

I do the same thing as far as eval'ing the parsefile
call.  Also, I removed the die statement from parser.pm 
(v 2.29 line 240 or so) so it would return a useful error 
message rather than just die uninformatively.

Maybe this is what you were asking about?

Tom

At 09:19 AM 5/4/01 +0100, Matt Sergeant wrote:
On Fri, 4 May 2001, Perrin Harkins wrote:

 on 5/4/01 9:28 AM, Mark Maunder at [EMAIL PROTECTED] wrote:
  I have an Apache::Registry script that is using XML::Parser. The
parser throws
  a
  'die' call if it encounters a parse error (Why?).
 
 Because it's an exception and the parser can't continue.
 
  I was handling this by
  putting
  the code in an eval block, but this no longer works since all Registry
scripts
  are already in one huge eval block.
 
 It should still work.  An eval{} is scoped like any other block.  Maybe you
 have a typo?  Post your code and we'll look at it.

More likely is a b0rked $SIG{__DIE__} handler, like fatalsToBrowser. Yick.

-- 
Matt/

/||** Founder and CTO  **  **   http://axkit.com/ **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** mod_perl news and resources: http://take23.org  **
 \\//
 //\\
//  \\




Re: [OT] Re: mod_perl subs defined, but don't exist? SOLVED mostly

2001-05-04 Thread will trillich

On Fri, May 04, 2001 at 12:29:30AM -0500, Ken Williams wrote:
 [EMAIL PROTECTED] (will trillich) wrote:
  sub search {
  # 
  {
  use CGI qw/:standard/;
  my $form = join '',
  map {
  hidden(
  -name = $_,
  -value = $arg-{$_},
  ) . \n
  }
  grep(
  $arg-{$_} and ($_ ne 'd') and ($_ ne 'go')
 
 as is, the functions that follow (top-level 'sub xyz {}') get
 screwy. code disappears.
 
 replace and with  and all is well. boggles my mind.
 
 
 Well, as far as I can tell, the original code doesn't even compile
 because there aren't enough arguments to grep().  That's why I couldn't
 test it.  

grep(
$arg-{$_} and ($_ ne 'd') and ($_ ne 'go')
, keys %$arg # note the leading comma...
)

aha -- so maybe x and y and z , pdq has lexical precedence
where the (z,pdq) parses higher, as in

x and y and (z , pdq)

versus what i expected, which was

(x and y and z) , pdq

hmm?

-- 
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!



Re: PERL.COM, ORA and Songline mailservers SUCK!

2001-05-04 Thread Nathan Torkington

Jesse Erlbaum writes:
 I've been trying for THREE DAYS to email SOMEBODY at PERL.COM about
 taking out a damn ad in their Perl.Com newsletter.

The bounces from songline and oreillynet were very bogus.  I've sent
your mail to someone high up at perl.com to figure out what's going on
and get in touch with you.  Sorry for the trouble you've had reaching
us!

Nat
(editor at O'Reilly, also [EMAIL PROTECTED] if you have any more trouble
with ORA mail servers)




Apache::DBI + persistent connections

2001-05-04 Thread Wayne Izatt

Hi all. I've ploughed through the documentation
regarding persistent db connections under mod_perl,
but I guess I'm not properly understanding just what
is meant by persistent connection.

The scenario I have is a simple CGI script running
under Apache::Registry. I added Apache::DBI to
httpd.conf to buy the app ssome persistent
connections. The app consists of a single script that
makes one connection to MySQL.

It is my understanding that when the app is running
and I look at the status under MySQL, that I should
see only one connection. However, what I see is plenty
of connections, as many as there were before I added
Apache::DBI to the mix.

Now, the script fetches and parses html docs and calls
itself for each image in the doc etc. What I'm seeing,
typically, is the same number of connections to MySQL
as there are images in the document.

Which leads me to think that persistent means that,
if a single script makes multiple connect requests
(with the same parameters), a single connection will
be utilized. But if multiple instances of the script
are active, each instance/process will be generating
connections.

Would this be correct?

Enlightenment much appreciated
wayne

___
Do You Yahoo!?
Get your free @yahoo.ca address at http://mail.yahoo.ca



Re: Apache::DBI + persistent connections

2001-05-04 Thread Jules

- Original Message -
From: Wayne Izatt [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, May 04, 2001 3:17 PM
Subject: Apache::DBI + persistent connections


 Which leads me to think that persistent means that,
 if a single script makes multiple connect requests
 (with the same parameters), a single connection will
 be utilized. But if multiple instances of the script
 are active, each instance/process will be generating
 connections.

correct.

Apache::DBI doesn't POOL connections, it merely keeps them open so that each
child doesn't keep reopening a new connection each time connect is called.

~j






Re: Apache::DBI + persistent connections

2001-05-04 Thread Andrew Ho

Wayne,

WIIt is my understanding that when the app is running
WIand I look at the status under MySQL, that I should
WIsee only one connection. However, what I see is plenty
WIof connections, as many as there were before I added
WIApache::DBI to the mix.

Apache is a forking server. There are x forked child processes serving
requests, each of which has a full Perl interpreter in it. What you are
seeing is likely one database connection per server child. Use ps and
count the number of Apache processes (or check /server-status) and that
number should match the number of MySQL connections.

The difference by using Apache::DBI is that those connections will stick
around, rather than being created/destroyed per HTTP request per child.
The number extant at any given time may be more or less than before, the
important thing is that they are persistent, saving resources on both
sides for connection establishing.

Humbly,

Andrew

--
Andrew Ho   http://www.tellme.com/   [EMAIL PROTECTED]
Engineer   [EMAIL PROTECTED]  Voice 650-930-9062
Tellme Networks, Inc.   1-800-555-TELLFax 650-930-9101
--




Re: Regarding modperl installation (fwd)

2001-05-04 Thread Stas Bekman

On Fri, 4 May 2001, ___cliff rayman___ wrote:

 G.W. Haywood wrote:

  Unfortunately you have an old version of Perl (5.004) so you should
  heed the advice of the build scripts and upgrade.  I would suggest
  version 5.005_03.  You must compile Perl, Apache and mod_perl with
  the same compiler.

 curious - why 5.005_03 as opposed to the recently released 5.6.1?

It's too new and not production stress-tested enough. 5.005_03 is used
for a long time and it's *known* to be good for your production
environment. While 5.6.1 is supposed to be stable and bugs-free, chances
are that it's not 100% clean and we will have to wait for a few more sub
versions (which means more time and testing), before we can endorse the
masses to use it.

Of course some people run the bleeding edge versions on their servers
(either because they need some new features, unavailable in the stable
versions, or just because...). But these people usually don't complain on
the list, they send patches if they find something broken.

_
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: Regarding modperl installation (fwd)

2001-05-04 Thread Aaron Johnson

What version of the CPAN module do you have?  Version 1.56+ should no longer
force you to upgrade.

Aaron Johnson
( is it 1.56 or 1.57, anyway 1.59 is out now and it doesn't force you to
upgrade :^)

Mithun Bhattacharya wrote:

 Umm aren't we forgetting something here - like the average user who uses
 CPAN to keep track of his modules ??? I mean last time I did install
 Bundle::libnet or even install CPAN I think it went ahead and installed
 perl 5.6.1 Unless ofcourse installing everything from tar balls is what
 is suggested for the moment

 Mithun




Re: Regarding modperl installation (fwd)

2001-05-04 Thread G.W. Haywood

Hi there,

On Fri, 4 May 2001, ___cliff rayman___ wrote:

 G.W. Haywood wrote:
 
  Unfortunately you have an old version of Perl (5.004) so you should
  heed the advice of the build scripts and upgrade.  I would suggest
  version 5.005_03.
 
 curious - why 5.005_03 as opposed to the recently released 5.6.1?

Caution.  I (and any, more significant, others) still use 5.005_03 in
live sites.  My own development servers use 5.7.  There have been a
few problems reported with 5.6 and I have seen one or two myself.
Although the problems which I saw were largely the result of slightly
dubious coding practices and were easily fixed, some people had more
serious problems and it's why I moved to 5.7 for development.

I've no personal experience of 5.6.1 and although I have had no
problems at all with 5.7 there's a health warning on the packet...

73,
Ged.




Re: Regarding modperl installation (fwd)

2001-05-04 Thread G.W. Haywood

Hi there,

On Sat, 5 May 2001, Mithun Bhattacharya wrote:

 Umm aren't we forgetting something here - like the average user who uses
 CPAN to keep track of his modules ??? I mean last time I did install
 Bundle::libnet or even install CPAN I think it went ahead and installed
 perl 5.6.1

It tried to do that to me too, once.  I stopped it.  But then I'm very
choosy about what I allow to be installed on my machines.  :)

73,
Ged.




Re: Regarding modperl installation (fwd)

2001-05-04 Thread Mithun Bhattacharya

I may be wrong on this but doesnt perl 5.05  come with CPAN v 1.48 ???
In anycase I am pretty sure I had to actually abort the upgrade if I
wanted to keep my perl 5.05 everytime I tried to go to CPAN v 1.59. I
will try to lay my hand on a clean box and try it out to see what
happens and get back soon.

Hmm to think of it I faintly recall something about libnet requiring
IO::Sockets provided by perl 5.6.1 or something I am not sure maybe
someone on the list can throw more light on that.



Mithun



Apache::Filter upgrade issues...

2001-05-04 Thread Trevor Phillips

Hi! I recently upgraded a test server to a recent Apache::Filter, and hit
problems due to the new dependency on filter_register() being called. I
don't mind upgrading my filters to call this, but I have one, in which I
use Apache::Request (a sub-class of Apache), which I cannot seem to work
around.

The guts of the code goes something like this:

sub handler
{
   my $r = shift;
   my $IsFilter = ($r-dir_config('Filter') =~ /^on/i?1:0);
   $r = Apache::Request-new($r);
   if ($IsFilter)
   {
  $r = $r-filter_register();
  my ($fh, $status) = $r-filter_input();
  return $status unless $status == OK;  # The Apache::Constants OK
  my @file = $fh;
   }
etc...
}

The above code fails in that the extra methods provided by Apache::Request
are
no longer there.

The above code worked fine previously (prior to the requirement of
filter_register)...

Any ideas? How can I use both Apache::Filter and Apache::Request together?

--
. Trevor Phillips -   http://jurai.murdoch.edu.au/ . 
: CWIS Systems Administrator -   [EMAIL PROTECTED] : 
| IT Services   -   Murdoch University | 
 --- Member of the #SAS#  #CFC# 
| On nights such as this, evil deeds are done. And good deeds, of /
| course. But mostly evil, on the whole. /
 \  -- (Terry Pratchett, Wyrd Sisters)  /