Please, keep these messages on the list.
Jeff Zhuk wrote:
Andre,
1.
you are right about security. I actually have my JBoss running in a different
space and only use this directory as static and perl root.
I narrowed down the problem of running test.pl by directly providing the first line in the test.pl file:
#!c:/Perl/bin/perl.exe
------------------------------------
This made the trick and allowed the script to work with Apache.
I have a lot of scripts and would not like to hardcode this line there.
When I switch to mod_perl I'll need to replace this line with the pointer to
perl58.dll or perl510.dll, right?
No, don't do that.
But maybe an additional word of explanation:
(Purists, I am simplifying, I know).
When you are running cgi-bin scripts without mod_perl, what happens is :
Apache uses the system default shell to run the script. The system shell
looks at the first line of the script, to determine which program should
run the script. Then the shell does an exec() of that program, with the
path of the script as argument.
This allows for cgi-bin scripts that are either perl, or any other
language (even a simple shell script).
This is all rather heavy and inefficient, because Apache has to start
another process, that process loads a shell, the shell then loads a
whole new perl interpreter, and that perl interpreter first compiles and
then runs your script. Then your script is done and exits, perl exits,
the additional process exits, and everything is forgotten.
And each time you call your script, the same happens again.
All in all, it is rather a wonder that it still works relatively fast.
When you run under mod_perl, the situation is fundamentally different.
First, Apache at startup will load a perl interpreter once and for all.
Then you tell Apache that in some directory, any files being run always
have to be run by that interpreter (that's what you do with "SetHandler
perl-script").
So Apache
1) does not have to load a new shell each time
2) this shell does not have to load perl
because perl is already there and Apache can tell it to run the script
file right away.
So only for that reason, things already go much faster.
For the sake of discussion, let's say that this already gains a factor
10 in speed, at least.
In addition, under some conditions perl will compile the script the
first time it runs it, and keep the compiled code cached in memory.
The next time the same script is run, perl can just re-execute the
cached compiled code.
That is much faster again.
Let's say that this is another cumulative factor 10.
So with both, you have a factor 10 X 10 = 100.
The next step would be to make, if possible and if it makes sense, your
script into a mod_perl Apache module. Then it would be loaded and
compiled when Apache starts, and become an integral part of Apache.
That would be another (smaller) boost in performance, but mainly it
allows you to write code that is much closer to the Apache "innards",
and that can directly intervene in the inner Apache request cycle, which
opens up lots of possibilities to do smart things like rewriting URLs,
doing customised authentication, filtering input and output, etc.. , all
of this quite fast.
That is the real power of mod_perl.
Apart from writing Apache add-on modules directly in C, mod_perl is the
closest you'll get to the Apache insides. Other languages don't even
come close (no matter what the php and python guys may believe).
And of course, lots of people have already done lots of things like
that, for just about any problem under the sun.
Have a look here for more ideas :
http://cpan.uwinnipeg.ca/search?query=apache2&mode=dist
Any way to move this line to httpd.conf?
No, and you don't need to.
Or rather, it's already done.
As explained above, that is what the line "SetHandler perl-script" is
already doing for you.
2.
I think, you are right again when you say that it has nothing to do with
mod_perl loading.
I suspect that my Perl install is not correct enough.
Running Perl from the console I see some libraries missing.
I think that while loading mod_perl, Apache cannot find some support from Perl.
Do you think this might be the reason?
I have no idea, but since you are under Windows, it's not really hard to
re-install everything.
I plan to re-install ActivePerl.
Would you recommend 5.8 or 5.10?
Usually I would recommend the latest one available, but I am still
happily using mostly 5.8.
I recently had a couple of problems with 5.10 in a mod_perl context (had
to change a couple of lines somewhere in a script or mod_perl module)
but don't remember what exactly.
Try perl 5.10 first. You can always downgrade if you have a problem.
Following the procedure as indicated here is the easiest :
http://perl.apache.org/docs/2.0/os/win32/install.html#toc_PPM_Packages
- save your apache/conf directory somewhere
- de-install Apache and perl
- re-install Apache 2.2.x
- re-install perl 5.10 from Activestate
- run the ppm commands indicated
(ppm install http://theoryx5.uwinnipeg.ca/ppms/mod_perl.ppd)
If you need to get back prior configuration stuff, use your saved copy
of the apache/conf directory)
I strongly suggest that in the process of installing Apache, you pick a
sensible installation directory, without spaces in the name, like your
prior c:/apache. This will always save you some aggravation at some
point, and a lot of quotes always.
I can still not figure out why the Apache for Windows packagers decided
to follow the assinine MS customs.
