date:20030109

On Wed, 8 Jan 2003, Perrin Harkins wrote:

 2) The Perl Pet Store
 
 This would be a discussion of porting the J2EE Pet Store reference 
 application to Perl.  It would cover Perl equivalents for various J2EE 
 features, and talk about what was easier or harder to do in Perl.

I think this could make for an excellent talk.

Along similar lines, I'd be interested in hearing about Perl application
frameworks such as OpenInteract, progress of P5EE, etc. - any ammunition I
could use that would help displace the misconception that if an app
server/framework is required then it must be Java-based.

Re: OSCON ideas

2003-01-09 Thread Perrin Harkins

Larry Leszczynski wrote:

On Wed, 8 Jan 2003, Perrin Harkins wrote:



2) The Perl Pet Store

This would be a discussion of porting the J2EE Pet Store reference 
application to Perl.  It would cover Perl equivalents for various J2EE 
features, and talk about what was easier or harder to do in Perl.


I think this could make for an excellent talk.

Along similar lines, I'd be interested in hearing about Perl application
frameworks such as OpenInteract, progress of P5EE, etc. - any ammunition I
could use that would help displace the misconception that if an app
server/framework is required then it must be Java-based.


Several people have brought up benchmarking in reference to the pet 
store.  I don't think it will possible to do a good benchmark of this 
application, partly because it's so big (it's a reference app that uses 
lots of functionality just to demonstrate it) and partly because it's 
well known that the J2EE pet store performs badly.  It does not 
represent anyone's best efforts to make a high-performance Java store.

If people are more concerned with seeing something that would dispel 
myths about Perl performance, rather than a talk on feature portability 
from J2EE to Perl, I could look at implementing something that really 
can be benchmarked like the TPC-W spec or the Doculabs Nile Bookstore 
benchmark.  These would be more comparable to existing Java and .NET 
performance tests.

Personally it would warm my heart to help enable a press release saying 
something like Perl blows away previous price/performance leaders on 
TPC-W benchmark, but I don't know if hearing about that would be as 
interesting to people as the other things I proposed.

Regardless, I think that posting a good reference implementation of one 
of these specs might get mod_perl some good attention from the 
business-oriented mags that usually focus on Java, and would be a 
valuable marketing tool.

- Perrin

Re: OSCON ideas

2003-01-09 Thread Jonathan M. Hollin

Perrin Harkins wrote:


Several people have brought up benchmarking in reference to the pet 
store.  I don't think it will possible to do a good benchmark of this 
application, partly because it's so big (it's a reference app that uses 
lots of functionality just to demonstrate it) and partly because it's 
well known that the J2EE pet store performs badly.  It does not 
represent anyone's best efforts to make a high-performance Java store.

An excellent point.


If people are more concerned with seeing something that would dispel 
myths about Perl performance, rather than a talk on feature portability 
from J2EE to Perl, I could look at implementing something that really 
can be benchmarked like the TPC-W spec or the Doculabs Nile Bookstore 
benchmark.  These would be more comparable to existing Java and .NET 
performance tests.

The saliva begins to leak from my lips...


Personally it would warm my heart to help enable a press release saying 
something like Perl blows away previous price/performance leaders on 
TPC-W benchmark, but I don't know if hearing about that would be as 
interesting to people as the other things I proposed.

Oh yes, now this is more like it.


Regardless, I think that posting a good reference implementation of one 
of these specs might get mod_perl some good attention from the 
business-oriented mags that usually focus on Java, and would be a 
valuable marketing tool.

I think I've just had an orgasm.  ;-)

Perrin, you've probably gathered by now that IMHO you've struck gold 
here.  I honestly don't know why this hasn't been done before. 
Obviously it would be great for all mod_perl programmers to be able to 
direct their PHBs and/or clients to a paper that validates and justifies 
the use of mod_perl.  I, for one, really hope you pursue this.


--
Jonathan M. Hollin

Technical Director:  Digital-Word Co. (http://digital-word.com/)
Co-ordinator:  WYPUG (http://wypug.pm.org/)

Re: OSCON ideas

Hi Perrin -

 If people are more concerned with seeing something that would dispel 
 myths about Perl performance, rather than a talk on feature portability 
 from J2EE to Perl,

I agree benchmarks would be a valuable marketing tool, but personally I
prefer the feature portability angle - I don't have much trouble
demonstrating that I can put together high-performance Perl solutions for
the web.  What I *do* have trouble with is people assuming you have to go
with Java to get a good J2EE-style app framework.


Larry Leszczynski
[EMAIL PROTECTED]

RE: OSCON ideas

2003-01-09 Thread Narins, Josh


Some of you will find this interesting, but I'd be hesistant placing too
much emphasis on it, since it's really just one programmer's view of the
cubes he can see.

Java programmers are dime a dozen

they must breed like rabbits

we've got tons of them

but where do you get a corporate experienced, clean-cut (75%, at least)
person willing to put on the tie 5 days a week and do mod_perl?

that's the only rational I have ever heard as to why we don't have more
mod_perl here. It's obviously much faster than the java pages (which we
spend god awful $$$ on, have you ever have a weblogic server? It's gotta be
50K at least just to say Hi)


I'd also guess that someone has thought if you can't buy a support contract,
it can't be safe to have.





-Original Message-
From: Jonathan M. Hollin [mailto:[EMAIL PROTECTED]] 
Sent: Thursday, January 09, 2003 12:54 PM
Cc: mod_perl list
Subject: Re: OSCON ideas


Perrin Harkins wrote:

 Several people have brought up benchmarking in reference to the pet
 store.  I don't think it will possible to do a good benchmark of this 
 application, partly because it's so big (it's a reference app that uses 
 lots of functionality just to demonstrate it) and partly because it's 
 well known that the J2EE pet store performs badly.  It does not 
 represent anyone's best efforts to make a high-performance Java store.

An excellent point.

 If people are more concerned with seeing something that would dispel
 myths about Perl performance, rather than a talk on feature portability 
 from J2EE to Perl, I could look at implementing something that really 
 can be benchmarked like the TPC-W spec or the Doculabs Nile Bookstore 
 benchmark.  These would be more comparable to existing Java and .NET 
 performance tests.

The saliva begins to leak from my lips...

 Personally it would warm my heart to help enable a press release 
 saying
 something like Perl blows away previous price/performance leaders on 
 TPC-W benchmark, but I don't know if hearing about that would be as 
 interesting to people as the other things I proposed.

Oh yes, now this is more like it.

 Regardless, I think that posting a good reference implementation of 
 one
 of these specs might get mod_perl some good attention from the 
 business-oriented mags that usually focus on Java, and would be a 
 valuable marketing tool.

I think I've just had an orgasm.  ;-)

Perrin, you've probably gathered by now that IMHO you've struck gold 
here.  I honestly don't know why this hasn't been done before. 
Obviously it would be great for all mod_perl programmers to be able to 
direct their PHBs and/or clients to a paper that validates and justifies 
the use of mod_perl.  I, for one, really hope you pursue this.


-- 
Jonathan M. Hollin

Technical Director:  Digital-Word Co. (http://digital-word.com/)
Co-ordinator:  WYPUG (http://wypug.pm.org/)


--
This message is intended only for the personal and confidential use of the designated 
recipient(s) named above.  If you are not the intended recipient of this message you 
are hereby notified that any review, dissemination, distribution or copying of this 
message is strictly prohibited.  This communication is for information purposes only 
and should not be regarded as an offer to sell or as a solicitation of an offer to buy 
any financial product, an official confirmation of any transaction, or as an official 
statement of Lehman Brothers.  Email transmission cannot be guaranteed to be secure or 
error-free.  Therefore, we do not represent that this information is complete or 
accurate and it should not be relied upon as such.  All information is subject to 
change without notice.

Re: OSCON ideas

2003-01-09 Thread Geoffrey Young



but where do you get a corporate experienced, clean-cut (75%, at least)
person willing to put on the tie 5 days a week and do mod_perl?


I suspect that there are actually quite a few people on this list that would 
_love_ to do mod_perl full time.  after talking to a few employers over the 
past year, it's getting them all in one place that's the problem - you 
probably want them onsite and, unlike the slurry of java programmers in your 
immediate area, what mod_perl experts there are are spread over the globe 
and may be unwilling to relocate.

open up to telecommuting and I suspect you would soon find yourself fully 
staffed.

--Geoff

Re: OSCON ideas

2003-01-09 Thread Dave Rolsky

On Thu, 9 Jan 2003, Jonathan M. Hollin wrote:

 Perrin Harkins wrote:

 (http://conferences.oreillynet.com/cs/os2003/create/e_sess).  I'm
 thinking about possible talks to submit and I want a little feedback on
 what people are most interested in.  Here are two options I'mconsidering:

 I would be extremely interested in talks covering any work that our Perl
 gurus have done using Bayesian Rules.  I am particularly interested in
 the usage of Bayesian rules for search-engines, spam management, log
 analysis, firewalling and encryption - has anybody ever covered any of
 these fields?

Ken Williams has.  Ken?


-dave

/*===
House Absolute Consulting
www.houseabsolute.com
===*/

RE: OSCON ideas


 I suspect that there are actually quite a few people on this 
 list that would 
 _love_ to do mod_perl full time.  
 
 open up to telecommuting and I suspect you would soon find 
 yourself fully 
 staffed.

Definitely.  Put me in this category.  I'm faced with having to relocate at
some point in the not so distant future, and the worst part of it is I'd
have to leave my current job where I get to do mod_perl most every day.  My
preliminary searches aren't looking too fruitful, and I think my first
option would be to telecommute to my current job anyway.  I'm planning on
pitching that idea to them when the time comes that I have to move, but I
dunno that they would agree to do it, which would be a shame for both
parties.

-Fran

[OT] Re: OSCON ideas


  but where do you get a corporate experienced, clean-cut (75%, at least)
  person willing to put on the tie 5 days a week and do mod_perl?

Josh:

I was with you right up to the part about wearing a tie  :-)


 I suspect that there are actually quite a few people on this list that
 would _love_ to do mod_perl full time.  after talking to a few
 employers over the past year, it's getting them all in one place
 that's the problem - you probably want them onsite and, unlike the
 slurry of java programmers in your immediate area, what mod_perl
 experts there are are spread over the globe and may be unwilling to
 relocate.
 
 open up to telecommuting and I suspect you would soon find yourself
 fully staffed.

Geoff:

I agree, most of the interesting mod_perl gigs I've seen would involve
relocating, which isn't a good option for me right now.  And I know a fair
number of people who would rather be doing mod_perl than what they're
doing now, or who do some mod_perl but would like to do it full time, or
who do it but are being gradually phased out in favor of Java.

But what do we do to change the perception (reality?) that mod_perlers are
hard to find?  In terms of web services, I think the slurry of available
Java programmers compared to mod_perl programmers is a result (maybe in a
roundabout way) of assumptions that Java is the only way to go for
application frameworks.  To a large extent, there are lots of Java
programmers out there because there are lots of Java jobs out there (gotta
go where the work is).  We're hiring Java programmers to augment in-house
Java expertise, because we're building products on top of J2EE
technologies.  Why are we using J2EE instead of a Perl-based application
framework?  I don't know for sure, nobody asked me, although it's very
likely that no non-Java options were presented as viable alternatives.  
But even if Perrin's OSCON talk (hint hint) gave me some valuable
ammunition to show that I could just as easily design on top of a
Perl-based application framework as on J2EE, we still come back around to
the perception that it's easier to find Java programmers.

Re: [OT] Re: OSCON ideas

2003-01-09 Thread Dave Rolsky

On Thu, 9 Jan 2003, Larry Leszczynski wrote:

 But even if Perrin's OSCON talk (hint hint) gave me some valuable
 ammunition to show that I could just as easily design on top of a
 Perl-based application framework as on J2EE, we still come back around to
 the perception that it's easier to find Java programmers.

My theory is that it takes a heck of a lot more bodies to build a J2EE app
than it does to build a Perl app.  So maybe you just need more Java
programmers to get anything done at all in Java ;)

Seriously, I think there is some truth to this.


-dave

/*===
House Absolute Consulting
www.houseabsolute.com
===*/

Re: OSCON ideas

2003-01-09 Thread wsheldah


I agree.  There are probably more of us than might be immediately obvious,
too. If a mod_perl programmer doesn't see too many mod_perl jobs in their
area, they're likely to highlight other areas when they go job hunting even
if they'd rather do mod_perl and could do it well.

I wonder if telecommuting plus occasional travel for face-to-face would
sell better than pure telecommuting. Is this done very often in telecommute
situations?

Wes




Geoffrey Young [EMAIL PROTECTED] on 01/09/2003 01:49:23 PM

To:Narins, Josh [EMAIL PROTECTED]
cc:mod_perl list [EMAIL PROTECTED]
Subject:Re: OSCON ideas



 but where do you get a corporate experienced, clean-cut (75%, at least)
 person willing to put on the tie 5 days a week and do mod_perl?

I suspect that there are actually quite a few people on this list that
would
_love_ to do mod_perl full time.  after talking to a few employers over the
past year, it's getting them all in one place that's the problem - you
probably want them onsite and, unlike the slurry of java programmers in
your
immediate area, what mod_perl experts there are are spread over the globe
and may be unwilling to relocate.

open up to telecommuting and I suspect you would soon find yourself fully
staffed.

--Geoff

RE: OSCON ideas

 
 I wonder if telecommuting plus occasional travel for 
 face-to-face would
 sell better than pure telecommuting. Is this done very often 
 in telecommute
 situations?

This is exactly what I hope to propose if the need arises in my situation.
Would love to hear from others who have had success doing this (maybe
offline if people feel this is straying too far).  

-Fran

development techniques

2003-01-09 Thread Jim Martinez

The start of a new year has me thinking of how I can improve things.  
Like the way I develop, debug and test code.

Do you develop with an xterm tailing the logs, an emacs window (or other
editor) to edit the script and/or the packages (and on some occassions
httpd.conf), and a web browser (on an alternate virtual desktop)?  Do you
pepper code with :

print option: . $option{$foo . br if $debug;

Fairly low tech, huh.

At apachecon, a speaker (who neither bragged nor rambled) mentioned lwp
use instead of (or to complement) the web browser portion.

Will the use of lwp instead of a browser improve my coding ability (either
in terms of speed or just improving my perl coding)?  Seems like I'd have
to spend too much time with the lwp script (tell it to first request the
page then choose option A and B then hit the submit button ... )

Is there some way to improve this cycle : edit code - refresh browser -
possibly look at the error log - edit code - ...

Or maybe you use another approach that's better?

Happy new near (9 days late),
Big big Jim

RE: development techniques


 Do you develop with an xterm tailing the logs, an emacs 
 window (or other
 editor) to edit the script and/or the packages (and on some occassions
 httpd.conf), and a web browser (on an alternate virtual 
 desktop)?  

Bingo. :-)

Do you
 pepper code with :
 
 print option: . $option{$foo . br if $debug;

If it's a longer-term debugging option that I might want again later then I
might make a debug() method where I'll do 
debug('this worked ok') and the debug() method might examine a flag to see
whether it should do anything with that message.  
Or a log() method that recognizes various levels of messages and obeys a
debug_level setting or something.  I once used a Java package (the name
escapes me but it was probably something simple like jLog) that worked sort
of this way, though it also had some xml config files and such... anyways,
I'm sure there are plenty of perl modules to do something similar, but the
debug() is a fairly effective 2 minute alternative.  If's it just a quick
one-time debug, I'll typically just use a warn or similar.  

 
 Fairly low tech, huh.
 
 At apachecon, a speaker (who neither bragged nor rambled) 
 mentioned lwp
 use instead of (or to complement) the web browser portion.
 
 Will the use of lwp instead of a browser improve my coding 
 ability (either
 in terms of speed or just improving my perl coding)?  Seems 
 like I'd have
 to spend too much time with the lwp script (tell it to first 
 request the
 page then choose option A and B then hit the submit button ... )

This sounds more like a testing suite than regular old
debugging-while-you-go.  Probably a place for both.

 
 Is there some way to improve this cycle : edit code - 
 refresh browser -
 possibly look at the error log - edit code - ...

Honestly, this method has always been very efficient for us and most of the
time we don't need anything more sophisticated for devel/debug.  Now for
more formal testing, that gets trickier for us and we're currently looking
for a good way to build some automated tests of our code and our web
interface without it getting too unwieldy.  This will probably be where we
spend a lot of time in the first part of the year.  Maybe LWP will be handy
here.

-Fran

Anyone ever have Apache::Session::File files getting corrupted?


This is going to be a somewhat preliminary feeler post because we are not
yet able to fully describe or recreate the bug we're seeing, but I'm hoping
some of you have seen something similar.

We use Apache::Session::File as the storage module for our Apache::Session
sessions.  I have written an object (RMS::Session where RMS is our app) that
basically is just a wrapper class for the Apache::Sessions.  When I
instantiate a new RMS::Session, it goes and ties to the actual
Apache::Session, gets a hold of the session hash, populates it's member
variables with values from the session hash, and unties/undefs the session
hash.  Thus we end up with a perl object representing our session with a
friendly OO interface for our developers that they are used to, and the real
session is freed for use by other requests.

Everytime I instantiate a new RMS::Session, I timestamp the Apache::Session
and I increment a 'retrievals' variable.  Pretty much every request into our
app needs to look at the session for something, so the end result is that
sessions are being tied and written a lot.  In some cases, a user will click
into an area of our application that has say three frames, and the content
of all three frames will go and look at the session, so three requests for
the same session could come in at the same time, so it's probably exercising
the locking mechanism fairly well.

Here's the basic problem we're seeing...our sessions have a very well
defined set of variables in them so the size of the session file is very
predictable - in our case, they all are between 320-360 bytes at all times.
What seems to be happening is that sometimes (more on this later) the files
get written out in a corrupted state, and I've noticed it's a well-defined
corruption to where the session file will shrink to a size of either 150
bytes or 63 bytes. Once this happens, the session is corrupted, in that I
can no longer successfully retrieve any information from it.  The session is
still there, but the contents have been completely garbled.

Unfortunately, it's neither predictable nor easy to reproduce.  First, it
only happens occasionally.  we haven't yet found one set of actions that we
can take and cause it to happen every time.  One test we use to demonstrate
it is to simply log in and out several times.  Sometimes, 7 or 8 logins will
go by without incident, and then the 9th will cause a corrupted session.
Other times, 10 logins in a row will lead to a corrupted session.  Secondly,
it happens far more frequently on our production server than our development
server (same exact code and versions of perl and all modules).  I've begun
to suspect that perhaps it only happens after a certain period of latency.
Since our production server has a lot more data in it's database, operations
tend to take much longer than they would during development. Perhaps this
means that there's more opportunity in production for a request to ask for a
session that's still held/locked by another child request.  Like I said,
it's still very preliminary.

Anyway, my question for now is whether anyone has seen corruption like this
with Apache::Session::File in your typical multi-user mod_perl web app
environment?  We're just trying to narrow down the possibilities since it's
been two days of four engineers trying to come up with any sort of recipe
for reliable reproduction or pattern to the bug with no luck so far.

Thanks,
Fran

RE: development techniques - specifically debug methods

2003-01-09 Thread C. Jon Larsen


There is a good technique in the mod_perl cookbock that talks about using 
a Debug module with exported constants. If you program to the API where 
all of your code is compiled into bytecode at server startup into 
discrete packages then this means that all of your debug if() sections 
sprinkled throughout the code are not included as part of the run time 
footprint. This can be quite nice if you have largish chunks of code that 
should run only in debug mode.

I guess this might work for registry scripts too, the 1st time the are 
compiled. 

On Thu, 9 Jan 2003 [EMAIL PROTECTED] wrote:

 
  Do you develop with an xterm tailing the logs, an emacs 
  window (or other
  editor) to edit the script and/or the packages (and on some occassions
  httpd.conf), and a web browser (on an alternate virtual 
  desktop)?  
 
 Bingo. :-)
 
 Do you
  pepper code with :
  
  print option: . $option{$foo . br if $debug;
 
 If it's a longer-term debugging option that I might want again later then I
 might make a debug() method where I'll do 
 debug('this worked ok') and the debug() method might examine a flag to see
 whether it should do anything with that message.  
 Or a log() method that recognizes various levels of messages and obeys a
 debug_level setting or something.  I once used a Java package (the name
 escapes me but it was probably something simple like jLog) that worked sort
 of this way, though it also had some xml config files and such... anyways,
 I'm sure there are plenty of perl modules to do something similar, but the
 debug() is a fairly effective 2 minute alternative.  If's it just a quick
 one-time debug, I'll typically just use a warn or similar.  
 
  
  Fairly low tech, huh.
  
  At apachecon, a speaker (who neither bragged nor rambled) 
  mentioned lwp
  use instead of (or to complement) the web browser portion.
  
  Will the use of lwp instead of a browser improve my coding 
  ability (either
  in terms of speed or just improving my perl coding)?  Seems 
  like I'd have
  to spend too much time with the lwp script (tell it to first 
  request the
  page then choose option A and B then hit the submit button ... )
 
 This sounds more like a testing suite than regular old
 debugging-while-you-go.  Probably a place for both.
 
  
  Is there some way to improve this cycle : edit code - 
  refresh browser -
  possibly look at the error log - edit code - ...
 
 Honestly, this method has always been very efficient for us and most of the
 time we don't need anything more sophisticated for devel/debug.  Now for
 more formal testing, that gets trickier for us and we're currently looking
 for a good way to build some automated tests of our code and our web
 interface without it getting too unwieldy.  This will probably be where we
 spend a lot of time in the first part of the year.  Maybe LWP will be handy
 here.
 
 -Fran 
 

-- 
+ Jon Larsen; Chief Technology Officer, Richweb.com
+ GnuPG Public Key http://richweb.com/jlarsen.gpg
+ Richweb.com: Providing Internet-Based Business Solutions since 1995
+ Business Telephone: (804) 359.2220
+ Jon Larsen Cell Phone: (804) 307.6939

Re: development techniques

2003-01-09 Thread Andrew Wyllie

On Thu, 09 Jan 2003, Jim Martinez wrote:

 The start of a new year has me thinking of how I can improve things.  
 Like the way I develop, debug and test code.
 
 Do you develop with an xterm tailing the logs, an emacs window (or other
 editor) to edit the script and/or the packages (and on some occassions
 httpd.conf), and a web browser (on an alternate virtual desktop)?  Do you
 pepper code with :
 
 print option: . $option{$foo . br if $debug;
print option: . $option{$foo} . br if $debug;

 
 Fairly low tech, huh.

yepi, I do that.

 At apachecon, a speaker (who neither bragged nor rambled) mentioned lwp
 use instead of (or to complement) the web browser portion.
 
 Will the use of lwp instead of a browser improve my coding ability (either
 in terms of speed or just improving my perl coding)?  Seems like I'd have
 to spend too much time with the lwp script (tell it to first request the
 page then choose option A and B then hit the submit button ... )


I think the advantage of using LWP for testing is that you could write a
large series of tests which could be run frequently.  So, if you make some
little change way down in the guts of your code, you can then run all your
tests to make sure everything is still working without having to worry
about missing something along the way.  So, it may seem like a lot of
work up front, but in the long run you are better off.

There is other stuff out there that you can use for testing.  Test::Unit
come to mind, and there is a test framework I read about called puffin
(http://www.puffinhome.org/) which sounds like it could be useful.


andrew

 
 Is there some way to improve this cycle : edit code - refresh browser -
 possibly look at the error log - edit code - ...
 
 Or maybe you use another approach that's better?
 
 Happy new near (9 days late),
 Big big Jim

RE: development techniques

2003-01-09 Thread Narins, Josh


--

I find ab to be very quick to type
ab('processing...');ab(\%whats_in_here);

use Data::Dumper;
sub ab {
return if exists $ENV{SERVER}  $ENV{SERVER} eq 'PRODUCTION';
my $msg=shift;
if (ref $msg) {
print STDERR scriptname:  . Data::Dumper-Dumper($msg) . \n;
} else {
print STDERR scriptname: $msg\n;
}
}

---

This is pretty easy to use...


use Time::HiRes qw(gettimeofday tv_interval);
our($start_time,$last_time);
sub handler {
  $start_time = $last_time = [gettimeofday];
  timer(subname.1);
  timer(subname.2);
  timer(subname.2a);
}

sub timer {
return if exists $ENV{SERVER}  $ENV{SERVER} eq 'PRODUCTION';
my $msg=shift;
my $new_time = [gettimeofday];
ab(join
':','Split',substr(tv_interval($last_time,$new_time),0,6),$msg);
ab(join
':','Total',substr(tv_interval($start_time,$new_time),0,6),$msg);
$last_time = $new_time;
}

---

I have these in my ~/.vimrc

:ab timtim sub timer {#{{{CRreturn if exists $ENV{SERVER} 
$ENV{SERVER} eq 'PRODUCTION';CRmy $msg=shift;CRmy $new_time =
[gettimeofday];CRab(join
':','Split',substr(tv_interval($last_time,$new_time),0,6),$msg);CR
ab(join
':','Total',substr(tv_interval($start_time,$new_time),0,6),$msg);CR
$last_time = $new_time;CR}CR#}}}CR

:ab abbb sub ab {#{{{CRreturn if exists $ENV{SERVER}  $ENV{SERVER}
eq 'PRODUCTION';CRmy $msg=shift;CRif (ref $msg) {CR
print STDERR scriptname:  . Data::Dumper-Dumper($msg) . \n;CR}
else {CRprint STDERR scriptname: $msg\n;CR
}CR}CR#}}}CR

The funny {{{ and }}} are for vim's foldmethod=marker


---

Yes, lwp-request for testing.

I make sure my output is XHTML, so I can use XPath to do things like [[look
up all href= of a]], and try running lwp-request on them, too
(non-recursively, of course, but it's all Intranet, regardless)

---



--
This message is intended only for the personal and confidential use of the designated 
recipient(s) named above.  If you are not the intended recipient of this message you 
are hereby notified that any review, dissemination, distribution or copying of this 
message is strictly prohibited.  This communication is for information purposes only 
and should not be regarded as an offer to sell or as a solicitation of an offer to buy 
any financial product, an official confirmation of any transaction, or as an official 
statement of Lehman Brothers.  Email transmission cannot be guaranteed to be secure or 
error-free.  Therefore, we do not represent that this information is complete or 
accurate and it should not be relied upon as such.  All information is subject to 
change without notice.

Re: development techniques

2003-01-09 Thread wsheldah


I use HTTP::WebTest for that sort of regression testing, just to make sure
nothing breaks along the way. I also use LWP and HTML::LinkExtor to check
some dynamically generated pages to make sure it's still generating valid
links. (It broke once, so after fixing I added a test for it... )

For debug messages I generally just use warn statements temporarily, then
remove them when done. I've toyed with Log::Log4perl a little bit, and will
probably use that if I ever decide it's worth the setup time. I think it's
based on a Java logging tool called Log4J or Log4Java or the like.

Wes



Andrew Wyllie [EMAIL PROTECTED] on 01/09/2003 04:22:43 PM

Please respond to [EMAIL PROTECTED]

To:Jim Martinez [EMAIL PROTECTED]
cc:mod_perl list [EMAIL PROTECTED]
Subject:Re: development techniques


On Thu, 09 Jan 2003, Jim Martinez wrote:
(snip)

 Will the use of lwp instead of a browser improve my coding ability
(either
 in terms of speed or just improving my perl coding)?  Seems like I'd have
 to spend too much time with the lwp script (tell it to first request the
 page then choose option A and B then hit the submit button ... )


I think the advantage of using LWP for testing is that you could write a
large series of tests which could be run frequently.  So, if you make some
little change way down in the guts of your code, you can then run all your
tests to make sure everything is still working without having to worry
about missing something along the way.  So, it may seem like a lot of
work up front, but in the long run you are better off.

There is other stuff out there that you can use for testing.  Test::Unit
come to mind, and there is a test framework I read about called puffin
(http://www.puffinhome.org/) which sounds like it could be useful.


andrew

Re: development techniques

2003-01-09 Thread Rob Nagler

mpm writes:
 Debugging of the applications now looks like:
 $ced-log('warn',No price for this product)

Here's an an alternative that we've evolved from Modula-2 to C to Java
to Perl :-)  Firstly, I try to distinguish between stuff I always
want to see and debugging messages.  The former we call logging, and
wrap it in a class Bivio::IO::Alert which also outputs the source line
of the caller, time, etc. configurably.  This is very handy for
figuring out what's complaining.

The latter we call trace messages which is presented by
Bivio::IO::Alert, but is defined as follows:

_trace('No price for this product') if $_TRACE;

The if $_TRACE is an optimization, which can be left out but avoids
the overhead of argument evaluation.

The _trace() subroutine and $_TRACE variable is dynamically generated
by our Trace module, which any package can register with as follows:

use vars ('$_TRACE');
Bivio::IO::Trace-register;

You can then configure tracing with two configuration values, which
also can be passed on the command line.  Here's an example:

'Bivio::IO::Trace' = {
package_filter = '/Bivio/  !/PDF/',
call_filter = '$sub ne Bivio::Die::_new',
},

Here I want to see tracing from all packages with the word Bivio in
their names but not PDF, and I want to ignore individual calls from
the subroutine Bivio::Die::_new.  In practice, we rarely use the
call_filter, so from any bOP command line utility, you can say, e.g.,

b-release install my-package --TRACE=/Release/

which translates to:

'Bivio::IO::Trace' = {
package_filter = '/Release/',
},

You can set the call filter or any other configuration value from the
command line with --Bivio::IO::Trace.call_filter='$sub ne foo'

 We use LWP for testing.  For things like cookies and argument parsing, LWP 
 is great for regression testing.  For content, it is much harder to come 
 up with a pass/fail situation since the content can change, but still 
 possible.

You might want to check out Bivio::Test::Language::HTTP.  It parses
the incoming HTML, and allows you to write scripts like:

test_setup('PetShop');
home_page();
follow_link('Dogs');
follow_link('Corgi');
follow_link('Female Puppy Corgi');
add_to_cart();
checkout_as_demo();

This particular code does a number of things including validating that
animals are getting in the cart.  Additional script language is defined in
Bivio::PetShop::Test::PetShop, which subclasses
Bivio::Test::Language::HTTP, which provides follow_link and home_page
generically.

 I haven't found a better way to do web development testing durring 
 development.  Possibly writing the test first would provide some 
 improvement since you know when you have completed the change(see XP 
 docs).

I agree.  A very important practice is unit testing, especially with
large applications.  For an alternative to Test::More and xUnit, have
a look at Bivio::Test, which allows you to write tests that look like:

Bivio::Test-unit([
'Bivio::Type::DateTime' = [
from_literal = [
[undef] = [undef],
['2378497 9'] = ['2378497 9'],
['-9'] = [undef, Bivio::TypeError-DATE_TIME],
['Feb 29 0:0:0 MST 1972'] = ['2441377 0'],
['Feb 29 13:13:13 XXX 2000'] = ['2451604 47593'],
['1972/2/29 0:0:0'] = ['2441377 0'],
['2000/2/29 13:13:13'] = ['2451604 47593'],
['Sun Dec 16 13:47:35 GMT 2001'] = ['2452260 49655'],
],
from_local_literal = [
[undef] = [undef, undef],
['2378497 9'] = ['2378497 7209'],
['-9'] = [undef, Bivio::TypeError-DATE_TIME],
['Feb 29 0:0:0 MST 1972'] = ['2441377 7200'],
['Feb 29 13:13:13 XXX 2000'] = ['2451604 54793'],
['1972/2/29 0:0:0'] = ['2441377 7200'],
['2000/2/29 13:13:13'] = ['2451604 54793'],
],
],
]);

We can write a lot of tests very quickly with this module.  We don't
always do this, but every time we don't, we regret it and end up
writing a test anyway after figuring out that we still aren't
perfect coders. :-)

Yet another trick we use is executing a task from within emacs or on
the command line.  A task in bOP is what the controller executes
when a URI is requested.  For example,

b-test task login

There are two advantages to this: 1) you don't have to restart Apache
and go to another program (browser or crawler) and 2) you get the
stack trace when something goes wrong and you can type C-c C-e (in
emacs) to go right to the error.  We added this facility recently,
because we got tired of the internal server error restart loops.
They slow things down tremendously, and anyway, you often want to look
at the HTML to see if some thing has changed.  The output of 'b-test
task' is the resultant HTML and any mail messages that would be sent,
which you can then search on immediately directly in emacs without
first having to say Tools - View Source and get

Re: Anyone ever have Apache::Session::File files getting corrupted?


 I think most people don't use Apache::Session::File in production.  It's 
 more of a testing thing.  In your situation, you would probably get 
 great performance from MLDBM::Sync with SDBM_File.  I'd suggest trying 
 that if you can't determine the cause of the Apache::Session::File issues.

Not to say that the other options won't work, but we're using
Apache::Session::File in production with no issues, handling in excess of
30 hits per second.  It works fine, and it's easy to keep old session
files cleaned up with a simple cron job that finds and deletes session
files older than some limit.

During development we also noticed race conditions with near-simultaneous
pageloads into framesets.  Try the 'Transaction' option when you tie to
the session - here is how that part of our mod_perl handler looks:


   # NOTE:
   #   At this point, $session_id is either set to some
   #   value from a cookie (for an existing session)
   #   or it is undef

   my %session = ();
   my $opts = {
 Directory = $SESSIONFILEROOT/$site,
 LockDirectory = $SESSIONLOCKROOT/$site,
 Transaction   = 1,
  };
   eval {
  tie %session, 'Apache::Session::File', $session_id, $opts;
   };
   if ( $@ ) {
  # Session tie failed for some reason.  If it was because
  # an existing session is invalid, create a new session:
  if ( $@ =~ /^Object does not exist in the data store/ ) {
 $session_id = undef;
 eval {
tie %session, 'Apache::Session::File', $session_id, $opts;
 };
  }
  if ( $@ ) {
 # Totally failed to create the session - bail out:
 $r-log_error( Tie failed: $@);
 return SERVER_ERROR;
  }
   }


HTH,
Larry Leszczynski
[EMAIL PROTECTED]

RE: OSCON ideas - missing proceedings

2003-01-09 Thread Mark Schoonover

Any chance they will bring it back to San Diego?? :)

.mark

-Original Message-
From: Robert Landrum [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 09, 2003 2:03 PM
To: [EMAIL PROTECTED]
Subject: Re: OSCON ideas - missing proceedings

One of the other things I disliked about the last OSCON was the missing
Perl Conference Proceedings.  I still have very fond memories of reading
about
Damians very sick, very twisted, Coy.pm in the 1999 Perl Conference
Proceedings.

Did anyone else notice that they weren't made available at the last OSCON?

Any chance we could convince O'Reilly to bring that back?

Rob

Re: OSCON ideas

2003-01-09 Thread Gunther Birznieks



[EMAIL PROTECTED] wrote:

 

I wonder if telecommuting plus occasional travel for 
face-to-face would
sell better than pure telecommuting. Is this done very often 
in telecommute
situations?


This is exactly what I hope to propose if the need arises in my situation.
Would love to hear from others who have had success doing this (maybe
offline if people feel this is straying too far).  

I don't know if it is really appropriate for OSCon, but I think topics 
on telecommuting tips and tricks definitely tug at the heart strings of 
many programmers out there.

I know that for my own company, I both like and dislike telecommuting.

On the dislike side, I don't think I would ever hire someone whom I did 
not know for telecommuting even if they came recommended because 
everyone needs to be managed differently and it's very hard to learn the 
body language without having been there in person for 6 months to a year.

This adds a lot to inefficiency of communication which means money out 
the window when I could just otherwise hire someone local (unless local 
talent were not withstanding).

But we do support telecommuting. After a couple years with us, our RD 
director moved to Melbourne (instead of Singapore), and when our 
webmaster moved back temporarily to New York for personal reasons, he 
telecommuted for months.

Anyway, how to make this on topic for OSCon? I am not sure.

Perhaps somewhere in this seed of an idea lies a study/comparison of 
Open Source Development models and tools being very similar (with 
perhaps some interesting differences) between telecommuting programmers 
in a corporation in terms of the methods and tools they use to do their 
jobs.

Re: development techniques

2003-01-09 Thread Thomas Bolioli

I use my debugging module 
(http://cpan.perl.org/authors/id/T/TB/TBOLIOLI/Log-AndError-0.99.tar.gz) 
which prints to stderr (hence I got bit by the mod_cgi issues with 
read/write deadlocks on pipes) while tailing the logs, etc. I am looking 
to include a syslog and other output drivers to my mod which should 
allow for more fancy versions of the tail -f method.
The key to the print xxx if $debug method is to use stderr, categorize 
diag msgs, have multiple levels and lastly to have many lines of code 
marked to send diag info to the debugger. By using the module I have 
eliminated the if statements and simply pass diag info to the debugger 
which in turn determines if the msg is of importance given current 
debugging levels. This is more of a performance drag but it cleans up 
the code plenty.
Tom


Jim Martinez wrote:

The start of a new year has me thinking of how I can improve things.  
Like the way I develop, debug and test code.

Do you develop with an xterm tailing the logs, an emacs window (or other
editor) to edit the script and/or the packages (and on some occassions
httpd.conf), and a web browser (on an alternate virtual desktop)?  Do you
pepper code with :

print option: . $option{$foo . br if $debug;

Fairly low tech, huh.

At apachecon, a speaker (who neither bragged nor rambled) mentioned lwp
use instead of (or to complement) the web browser portion.

Will the use of lwp instead of a browser improve my coding ability (either
in terms of speed or just improving my perl coding)?  Seems like I'd have
to spend too much time with the lwp script (tell it to first request the
page then choose option A and B then hit the submit button ... )

Is there some way to improve this cycle : edit code - refresh browser -
possibly look at the error log - edit code - ...

Or maybe you use another approach that's better?

Happy new near (9 days late),
Big big Jim


 


--
-
Terra Novum Research
[EMAIL PROTECTED]
www.terranovum.com
(617) 923-4132

PO Box 362
Watertown, MA 02471-0362

Never meant half the things I said to you,
so you know,
there's a half that might be true.
 - Glenn Philips

Re: development techniques

2003-01-09 Thread Dave Rolsky

On Thu, 9 Jan 2003, Thomas Bolioli wrote:

 I use my debugging module
 (http://cpan.perl.org/authors/id/T/TB/TBOLIOLI/Log-AndError-0.99.tar.gz)
 which prints to stderr (hence I got bit by the mod_cgi issues with
 read/write deadlocks on pipes) while tailing the logs, etc. I am looking
 to include a syslog and other output drivers to my mod which should
 allow for more fancy versions of the tail -f method.

Rather than re-inventing that wheel why not take a look at Log::Dispatch
and Log4Perl.


-dave

/*===
House Absolute Consulting
www.houseabsolute.com
===*/

Re: development techniques

Jim Martinez wrote:
[...]

At apachecon, a speaker (who neither bragged nor rambled) mentioned lwp
use instead of (or to complement) the web browser portion.

Will the use of lwp instead of a browser improve my coding ability (either
in terms of speed or just improving my perl coding)?  Seems like I'd have
to spend too much time with the lwp script (tell it to first request the
page then choose option A and B then hit the submit button ... )


There are many benefits to using command line tools (which can be 
anything, but LWP::UserAgent and other packages in libwww-perl are a 
gift from god). Here are some of them off the top of my head:

1. You get the results as they come in (browsers tend to cash things).
2. You can program things:
 - make a sequence of request/response cycles based on a response
 - you can choose to display only certain bits of the response:  e.g., 
show me only headers, only the body, only the size of the body, only 
certain keywords, etc.
3. You can easily reproduce sequences or specific inputs, especially 
when there is a sequence of request/response pairs to get to some state.
4. you can involve someone else in debugging the problem, without 
needing to come down (fly?) to his cubicle to explain how a certain 
anomaly is reached. So you can educate your users to create test scripts 
that reproduce the problem.
5. We (mod_perl programmers) very often use the single server mode 
(httpd -X) to test things. If you have a page with embedded images, it's 
going to take a while before you get the output, because you have only 
one server (this is documented in the guide).
6. Filling in forms.
- You can prefill forms programmatically (saving you a lot of time and 
protecting from mistyping things)
- You can provide inputs which with normal manual typing won't be 
possible (so you can test your program's behavior when a 10MB core file 
is submitted as a fname form's field).
... I guess there are many more things that could be added here, you get 
the idea.

Apache::Test is one of the new tools that work with both versions of 
Apache (and mod_perl and other mod_*). If you are a 3rd party mod_perl 
module developer (CPAN or in-house) you definitely should use it to test 
your module. See:
http://perl.apache.org/docs/general/testing/testing.html

The only major drawback to command line tools I can see is when you need 
to observe the html as is (e.g. you can't use some logic/parser to 
verify correctness), here the browser is definitely more useful. So 
knowing when to use what technique is important. Both have an application.

(I've also noticed that lwp-get sometimes have a significant delay 
because it tries to resolve IPs, even though the request is made to 
localhost. So many times I end up using just 'lynx --source')

Is there some way to improve this cycle : edit code - refresh browser -
possibly look at the error log - edit code - ...

Or maybe you use another approach that's better?


Inject mod_perl into your brain ;0)

Seriously, I don't think that the core of this cycle can be any 
different, other than the 'refresh browser' part.

Talking about the 'refresh browser' part. In one of the companies I've 
worked for, there was this girl who did some perl coding and who was 
very inefficient, because she didn't know she could do a refresh. Many 
times she needed to debug a form to which you get after a sequence of 
several forms, all requiring a lot of things to type in. So every time 
she would change a bit of code (1 sec), she would go to the first form 
and start filling in a form, then submit, get to the next form, fill it 
in, submit, and so on, till she gets to the stage she is debugging, see 
that her fix didn't work and start all again from scratch. On the way 
she would enter different data by mistake which
would lead her to the wrong stage and she would need to start from 
scratch again. I'm sure that you all have seen someone in your office do 
that. Do them and your company a favor, explain to them that you can do 
a refresh to resubmit just the last stage. Or even better, show them the 
light by pointing them to libwww-perl.

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: mod_perl pre-install questions

Richard wrote:

I had a brand new server setup yesterday, which has SuExec installed.
 
I read somewhere, I don't remember where, that mod_perl won't work with 
SuExec.
 
Is that true? Or did I just think I read that somewhere?

It's true. It's all explained here:
http://perl.apache.org/docs/1.0/guide/install.html#Is_it_possible_to_run_mod_perl_enabled_Apache_as_suExec_


I see mod_perl in my RPM package installer, with the options of ignore 
dependancies and force install, what do you recommend?

I'd recommend to install it manually, YMMV. This has been discussed many 
times here, check the archives if you are curious why.

What do I need to do to install it? Should I use the RPM installer?
Do I need to disable SuExec?
 
If not, how will the user and group settings in httpd.conf work with 
mod_perl installed?
 
Thank you for any advice you may have

You will find all the information that you need here:
http://perl.apache.org/docs/1.0/guide/
Please take some time to read things under this URL.

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

RE: OSCON ideas - missing proceedings

2003-01-09 Thread Nathan Torkington

Mark Schoonover writes:
 Any chance they will bring it back to San Diego?? :)

Not for two years at least (the duration of the contract with the
Portland hotel).  The San Diego hotel was much more expensive and
remote, compared to the Portland hotel.  I think people are really
going to enjoy being in the middle of a city at this year's OSCON.

Nat

Re: OSCON ideas - missing proceedings

2003-01-09 Thread Nathan Torkington

Robert Landrum writes:
 One of the other things I disliked about the last OSCON was the missing
 Perl Conference Proceedings.

They didn't appear because we didn't have time at O'Reilly to do it.
They're prepared in Framemaker, to fit with our style guide, and take
a huge and painful amount of time to do.  Jon Orwant did them in 2000,
I did them in 2001, and nobody had time to do them in 2002.  I can't
see them in 2003, either, as we're not soliciting refereed papers this
year.

We do make presentation materials available online after the conference
ends, for what that's worth.

Nat

Re: OSCON ideas - more talk ideas

2003-01-09 Thread Slava Bizyayev

Hi Nigel,

OSCON is so far away from the Web Content Compression features. They
discarded my proposal to talk about Effective Content Delivery over the Web.
You know, O'Reilly itself delivers uncompressed web content to date (indeed,
they have mod_gzip and mod_perl installed on Apache):

C05 -- S06 GET / HTTP/1.1
C05 -- S06 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/msword, */*
C05 -- S06 Referer:
http://users.outlook.net/~sbizyaye/cgi-bin/pp-slav.cgi/index.html
C05 -- S06 Accept-Language: en-us
C05 -- S06 Accept-Encoding: gzip, deflate
C05 -- S06 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)
C05 -- S06 Host: www.perl.com
C05 -- S06 Accept-Charset: ISO-8859-1
== Body was 0 bytes ==

C05 -- S06 HTTP/1.1 200 OK
C05 -- S06 Date: Fri, 10 Jan 2003 02:04:44 GMT
C05 -- S06 Server: Apache/1.3.26 (Unix) PHP/4.2.1 mod_gzip/1.3.19.1a
mod_perl/1.27
C05 -- S06 P3P: policyref=http://www.oreillynet.com/w3c/p3p.xml,CP=CAO
DSP COR CURa ADMa DEVa TAIa PSAa PSDa IVAa IVDa CONo OUR DELa PUBi OTRa IND
PHY ONL UNI PUR COM NAV INT DEM CNT STA PRE
C05 -- S06 Content-Type: text/html; charset=ISO-8859-1
C05 -- S06 X-Cache: MISS from www.perl.com
C05 -- S06 Transfer-Encoding: chunked
C05 -- S06 == Incoming Body was 41869 bytes ==
== real URL = http://www.perl.com/ ==
== Transmission: text  chunked ==
== Latency = 0.330 seconds, Extra Delay = 1.480 seconds
== Restored Body was 41731 bytes ==

Let's forgive them, hopefully they know better what they are doing...

;-)

Fortunately for us, I'm still here (I mean on mod_perl mailing list) to
answer any of your practical questions concerning Apache::Dynagzip
implementation.

Regards,
Slava


- Original Message -
From: Nigel Hamilton [EMAIL PROTECTED]
To: mod_perl list [EMAIL PROTECTED]
Sent: Thursday, January 09, 2003 11:55 AM
Subject: Re: OSCON ideas - more talk ideas


 HI,

 I'd really like to see talks on:

 1. Web Server Compression - a comparison, between mod_gzip, DynaGzip
 Compress etc, pros / cons, SSL compression, and example configurations

 2. Application Server Options - a comparison between pure-perl,
 Apache/mod_perl, POE, SpeedyCGI etc


 Nige

 --
 Nigel Hamilton
 Turbo10 Metasearch Engine

 email: [EMAIL PROTECTED]
 tel: +44 (0) 207 987 5460
 fax: +44 (0) 207 987 5468



 http://turbo10.com Search Deeper. Browse Faster.

Re: Passing CGI environment to subprograms

I don't see any reason why your `` invoked process doesn't see the CGI 
env vars. For example:

#!/usr/bin/perl
print Content-type: text/plain\n\n;
$ENV{'PATH'} = '/bin:/usr/bin';
delete @ENV{'IFS', 'CDPATH', 'ENV', 'BASH_ENV'};
print qx{printenv |grep REMOTE_ADDR};

prints:
REMOTE_ADDR=127.0.0.1

So as you can see, it works. The problem is probably in your external 
program, since the env vars are all there.

Or may be you are using PerlSetEnv Off?
http://perl.apache.org/docs/1.0/guide/config.html#PerlSetupEnv

I've now located and tried the subprocess_env() in conjunction w/
spawn_proc_prog().  I just do a foreach on the ENV hash and stuff 
the values
into subprocess_env().  That works (I have a test perl subprogram 
that just
dumps the ENV), but now I am not able to get the output of the program.
I
pasted in the read_data() func from the example and I have a single 
scalar
accepting the return value from spawn_proc_prog() per the example 
and that
is supposed to give me the output filehandle.

Can you post a simple test program that reproduces the problem?

Also it'd be really useful if somebody could add a test suite for 
Apache::Subprocess for (mod_perl 1.0). You can look at the 
t/apr/subprocess test in mod_perl 2.0 to a basic example. It's a good 
way to learn how to use Apache::Test, which is covered here:
http://perl.apache.org/docs/general/testing/testing.html

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

An URL is not Invoking the Anticipated Perl Module

2003-01-09 Thread Steve D

The problem: Apache is generating File does not exist within its
error.log and the message Object not found (The requested URL was not
found. Error number 404.) while
attempting to call a perl module from a brower.

Since I am new with mod_perl, and somewhat with familiar perl, I must
confess the following problem has baffled me while someone else may quickly see
what is being done wrong.
Appreciation is expressed in advance to anyone who can tell me what the
problem might be or recommends a remedy.

Below youll see the path settings found in the various configurations
files. I have followed the string
of recommendations found in the on-line documentation (from perl.apache.org, etc.) and
but have also made minor adjustments relevant to this particular servers
configuration. I understand that I
am providing some information (not much) which is not relevant to the immediate
problem but can assist to give an overview the operating environment as a
whole.

Here are the details:

Given:

1) The file httpd.conf contains the lines:

ServerRoot "/etc/httpd"

Include conf.d/*.conf

(The presence of this include statement is before the invocation of the
various LoadModules found in most httpd.conf files. Hence, the perl environment
is set early in the Apache initialization process.)

2) and the file /etc/httpd/conf.d/perl.conf contains the
lines:

LoadModule perl_module modules/mod_perl.so
PerlRequire "/var/www/perl/startup.pl"

Alias /perl/ /var/www/perl/
Directory /var/www/perl

SetHandler perl-script

PerlHandler ModPerl::Registry::handler

PerlOptions +ParseHeaders

Options +ExecCGI
/Directory

Location /CurrDate

SetHandler per-script

PerlResponseHandler MyApache::CurrDate
/Location

3) and the file /etc/httpd/perl/startup.pl contains the line:

use lib qw(/var/www/perl);

4) and the file /etc/httpd/perl/MyApache/CurrDate.pm contains the
line:

package MyApache::CurrDate;

then why does /var/httpd/error.log report:

[error] [client 192.168.0.100] File does not exist:
/var/www/html/CurrDate

So, in otherwords, why is does the URL //192.168.0.100/CurrDate 'not'
invoke CurrDate.pm from the anticipated directory of
/var/httpd/perl/MyApache?
Notice the Apache error log indicates that it is trying to access a file
under the directory /var/www/html/ rather than /var/www/perl/. This is done even though the perl.conf
file includes the Location directive which should redirect program
control to the respective perl module.
And, the startup script specs the parent directory where perl modules
can be found.

Incidentally, the intent of MyApache/CurrDate.pm is to test the existing
mod_perl environment for its ability to run handlers. (Better said, it is to test my ability
and the present set up. The system
is being initialized for the first time on this system. Another version of CurrDate.pm, in the
form of a script, was executable from a browser. So, Apache and Perl are likely set up
correctly.) Security of the files shouldn't be a problem.
The permissions of all respective
files have been set to assure they ought to be both readable and executable from
a browser.

Now when the browser is pointed to a different address, i.e.
//192.168.0.100/perl/CurrDate, then partial progress 'maybe' occurring
for
an Apache exception indicates:

[error] 13440: ModPerl::Registry: /var/www/perl/CurrDate.pm not found or
unable to stat

So it appears, with this later URL address, access to modperl is being
accomplished (!?). Granted, yet
another problem may exists; namely, the one generated by the ModPerl Registry
method. Hence, I may have two
problems to resolve rather than just the one.

An article (it is entitled Getting Your Feet Wet with mod_perl)
declares a handler with the syntax PerlResponseHandler ModPerl::Registry where
I have used a different syntax. It
was PerlHandler ModPerl::Registry::handler for the former would not work on
this system. The later was able to
successfully run a script. This
change was made to the directory /var/www/perl and not to the location called by
/CurrDate name space. This may not have relevance to the problem at
hand.

I understand Apache directives have a precedence. However, I have sequenced the order of
the directories in various ways without a resolution or apparent different
effect. Any
suggestions?

Thank you for your assistance.
#!/usr/bin/perl
#
# FileID: /perl/MyApache/currDate.pm
# Edition: 1600.08012003
# Editor: Steve Davis
# Install.: Powder Springs, GA
# Purpose: To display the current date
#
package MyApache::CurrDate;

use strict;
use warnings;

use Apache::RequestRec ();
use Apache::RequestIO ();
use Apache::Const -compile = qw(OK);

sub handler {

my ($SEC,$MIN,$HOUR,$MDAY,$MON,$YEAR,$WDAY,$YDAY,$ISDST) = localtime(time);
my $CURR_MONTH =
(Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,Oct,Nov,Dec) [$MON + 1];
my $CURR_YEAR = $YEAR +

Re: An URL is not Invoking the Anticipated Perl Module