handler using a module
Hi all,
I have written a handler to take care of requests and there is something
unexpected [to me, anyway :-) ] happening which may be my fault, but I
was wondering if someone can explain it to me. Perhaps there is a
problem with my programming style.
The code is long, so I'll briefly mention what I think is relevant
[hopefully I don't leave anything out]. I have a handler called
myHandler.pl:
-
## File myHandler.pm
package myHandler;
use lib 'my Path';
use myOwnFunctions; ## Located in my Path
my $ah = HTML::Mason::ApacheHandler - new (...);
sub handler {
my $r = shift;
$ah - handle_request ($r);
}
1;
-
In the file myOwnFunctions.pl:
package myOwnFunctions;
sub myFunction {
}
1;
-
So in an HTML file that will be processed by Mason, I call myFunction
() and it says it is undefined. This surprised me since I indicated
that I am using myOwnFunctions in the handler with the use directive.
Is that not the way to do it? So, then I thought I should call
myFunction as:
myOwnFunctions::myFunction ()
and that gave me an error. By accident, I typed:
myHandler::myFunction ()
and that worked... I don't quite know why. I presume I have done a
mistake somewhere. Or is this how it should be?
Thanks!
Ray
AW: MP1 - MP2 migration Problems.
Hello again,
i did a new setup of our Apache and mod_perl2 with your hint´s.. Configured
again some startup.pl stuff. but no luck 8-)
Error is still the same in error.log from apache.
[Thu Feb 14 14:33:58 2008] [error] [Thu Feb 14 14:33:58 2008] -e: Can't locate
object method request via package Apache at /usr/lib/cgi-bin/test1.pl line
4.\n
Code looks like this for test1.pl
#!/usr/bin/perl
my $r = Apache-request;
$r-send_http_header('text/plain');
$r-print(mod_perl rules!\n);
Hmm. Is someone able to use this code under apache2 with compat enabled.
Perhaps it is broken in some ways ?
bye
Roman
-Ursprüngliche Nachricht-
Von: André Warnier [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 13. Februar 2008 23:01
An: modperl@perl.apache.org
Cc: Petry Roman, IT
Betreff: Re: MP1 - MP2 migration Problems.
Of course, what I forgot to mention below - and sorry if you know that
already - is that whichever perl modules you pre-load in your main
Apache server config via the startup.pl script, you do not need to use
anymore in all your perl scripts or Apache/mod_perl handlers.
(At the cost of having them (insibly) duplicated in all the children
processes).
But it may simplify your migration problems, and you can always tune
this later.
André
André Warnier wrote:
Hi.
About your problem below...
I am not sure that this is going to help, nor even if it is really
relevant to your specific problem. Just trying to give you ideas,
because it reminds me of something.
Below are two configurations, of two of our systems which have slightly
different versions of mod_perl and the rest.
I went through the same kind of problems you're going through, a while
ago when going from Apache 1.x to Apache 2.x, and then again more
recently when there were some changes in the mod_perl naming of modules
between mod_perl 1.9xx and mod_perl 2.0, and then some additional things
happened during a Linux Debian upgrade from Sarge to Etch, which changed
the location where some Apache2 stuff was installed.
And there is still some difference to this day in some Perl scripts or
modules between these two systems, which greatly bothers me, but it
basically works.
The main difference is in the two first use statements in our
startup.pl script (which I assume you are familiar with, as a way to
pre-load some perl stuff when the server starts).
I do not remember precisely which problems we had, but they were of the
same general gist as yours, so maybe this helps.
Here it goes :
1) system colin (Debian Sarge, older)
=
version (uname -a) :
Linux colin 2.6.8-11-amd64-k8 #1 Sun Oct 2 21:26:54 UTC 2005 x86_64
GNU/Linux
Apache2 version : see below
Perl version (perl -v) : 5.8.4
mod_perl version (per Apache log) :
[Wed Feb 13 22:24:59 2008] [notice] Apache/2.0.54 (Debian GNU/Linux)
DAV/2 mod_jk/1.2.6 PHP/4.3.10-22 mod_perl/1.999.21 Perl/v5.8.4
configured -- resuming normal operations
mod_perl startup.pl script : (invoked via PerlRequire in httpd config)
--
#!/usr/bin/perl
# modperl2_startup.pl
# Apache2 / mod_perl 2 startup script
use Apache2 ();
use Apache::compat ();
use lib /usr/lib/apache2/perllib; # that's a local perl lib directory
use lib /home/EFS/lib; # that also
use ModPerl::Util ();
use Apache::RequestRec ();
use Apache::RequestIO ();
use Apache::RequestUtil ();
use Apache::Filter ();
use Apache::ServerUtil ();
use Apache::Connection ();
use Apache::Log ();
use Apache::Const -compile = qw(:common :log REDIRECT);
use APR::Const -compile = ':common';
use APR::Table ();
use ModPerl::Registry ();
use CGI ();
CGI-compile(':all');
1;
lines in httpd.conf :
(or, rather, in /etc/apache2/mods-available/perl.conf) :
PerlRequire /usr/lib/apache2/perllib/modperl2_startup.pl
SetEnv PERL5LIB /usr/lib/apache2/perllib
2) system arthur (Debian Etch, more recent)
==
version (uname -a) :
Linux arthur 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux
Apache2 version : see below
Perl version (perl -v) : 5.8.8
mod_perl version (per Apache log) :
[Wed Feb 13 22:29:38 2008] [notice] Apache/2.2.3 (Debian) DAV/2
mod_jk/1.2.18 PHP/4.4.4-8+etch4 mod_ssl/2.2.3 OpenSSL/0.9.8c
mod_perl/2.0.2 Perl/v5.8.8 configured -- resuming normal operations
mod_perl startup.pl script :
--
#!/usr/bin/perl
# modperl2_startup.pl
# Apache2 / mod_perl 2 startup script
use Bundle::Apache2 ();
use Apache2::compat ();
use lib /usr/local/lib/apache2/perllib; # that's a local perl lib
directory
use lib /home/EFS/lib; # that also
use ModPerl::Util ();
use Apache2::RequestRec ();
use Apache2::RequestIO ();
use Apache2::RequestUtil ();
use Apache2::Filter ();
use Apache2::ServerUtil ();
use Apache2::Connection ();
use Apache2::Log ();
use Apache2::Const -compile = qw(:common
Re: MP1 - MP2 migration Problems.
Andre, On Wed, 2008-02-13 at 23:00 +0100, André Warnier wrote: Of course, what I forgot to mention below - and sorry if you know that already - is that whichever perl modules you pre-load in your main Apache server config via the startup.pl script, you do not need to use anymore in all your perl scripts or Apache/mod_perl handlers. This is the first time that NOT using use because it was preloaded is mentioned. In fact, how would the modules compile (while testing for example)? (At the cost of having them (insibly) duplicated in all the children processes). Again, this is the first time this is mentioned. It would mean that, say 10 or 20 scripts under mod_perl using DBI,DBD::Oracle,CGI and Template would have the effect of using up to 20 times the memory footprint? Wasn't preloading suposed to do the exact opposite? I'm at a loss here But it may simplify your migration problems, and you can always tune this later. André Regards, Rafael Caceres
Re: handler using a module
Hi Marcel, Marcel Greter wrote: I can only tell why myHandler::myFunction () is working. I think you export the myFunction in Module myOwnFunctions. I assume you didn't post that part of the code? Ah, yes -- I didn't think that was doing it but yes, I also have: require Exporter; our @ISA = qw (Exporter); our @EXPORT = qw (myFunction); our @EXPORT_OK = qw (myFunction); Therefore myFunction is also accessible within the namespace myHandler, and therefore the second version is working as I would expect. But I cannot tell you why myOwnFunctions::myFunction itself is not working. Hmmm, I see. Is there any problem if I continue with myHandler::myFunction () for now? Maybe later on, I will figure out what is wrong...perhaps some other silly mistake that I also didn't post? I will continue investigating... As someone new to Mason and modperl, what is the correct way of doing this? i.e., the correct practice? Should myOwnFunctions be exporting? More importantly, should I do this: use lib 'my Path'; use myOwnFunctions; ## Located in my Path I thought by doing so, it loads myOwnFunctions once per process. But I'm having doubts about whether what I'm doing makes any sense... :-) Thank you! Ray
Re: [MP2][QUESTION]Session and inactivity
On Thu, Feb 14, 2008 at 2:01 AM, titetluc titetluc [EMAIL PROTECTED] wrote:
All of these modules propose an expiration mechanism, but they do not
propose a mechanism to automatically destroy session at expiration (this is
what I call a callback mechanism).
This implies that the session destruction has to be called explicitly.
No, mod_auth_tkt simply uses cookies so there is nothing to destroy,
CHI will automatically stop returning expired data,
Apache::SessionManager will automatically stop returning expired
sessions. No explicit checks are required. The only suggestion that
requires you to check if a session is expired is storing a timestamp
in a session yourself.
For example,
session_create(inactivity = 30, callback = sub{print Session
automagically destroyed;})
There would be no need to call a session_delete function !!
What is it that you're concerned about here? Do you have code that
you need to run when a session expires? Or are you just worried about
running out of disk space?
- Perrin
Re: handler using a module
On Thursday 14 February 2008 08:33:34 am Raymond Wan wrote: So in an HTML file that will be processed by Mason, I call myFunction () and it says it is undefined. This surprised me since I indicated that I am using myOwnFunctions in the handler with the use directive. Is that not the way to do it? So, then I thought I should call myFunction as: myOwnFunctions::myFunction () and that gave me an error. By accident, I typed: myHandler::myFunction () and that worked... I don't quite know why. I presume I have done a mistake somewhere. Or is this how it should be? Mason uses it's own namespace for the code it generates from your templates. So unless you have a use lib...; use myOwnFunctions; in your template, it won't have your functions in scope. This: package myHandler; use lib 'my Path'; use myOwnFunctions; ## Located in my Path imports myOwnFunctions into the myHandler namespace, which is visible from Mason (either because you did a use or through Mason magic).
Re: MP1 - MP2 migration Problems.
On Wed, Feb 13, 2008 at 3:08 PM, Petry Roman, IT [EMAIL PROTECTED] wrote: Looks ok i think. Apache.pm is loaded.. So why can´t i get it to work.. damn thing 8-). This is starting to look like a bug in Apache2::compat to me. I think request() is defined in the wrong namespace. I'll try to make a patch for you to try. Do you actually use the Apache-request() call? In a Registry script, you can get $r just by calling shift at the beginning of the program. - Perrin
Re: MP1 - MP2 migration Problems.
On Thu, 14 Feb 2008, Perrin Harkins wrote:
On Wed, Feb 13, 2008 at 3:08 PM, Petry Roman, IT
[EMAIL PROTECTED] wrote:
Looks ok i think. Apache.pm is loaded.. So why can´t i get it to work.. damn
thing 8-).
This is starting to look like a bug in Apache2::compat to me. I think
request() is defined in the wrong namespace. I'll try to make a patch
for you to try.
Does the attached patch work (untested)?
Do you actually use the Apache-request() call? In a Registry script,
you can get $r just by calling shift at the beginning of the program.
That's a good point.
--
best regards,
Randy KobesIndex: lib/Apache2/compat.pm
===
--- lib/Apache2/compat.pm (revision 627863)
+++ lib/Apache2/compat.pm (working copy)
@@ -279,20 +279,6 @@
}
}
-sub request {
-my $what = shift;
-
-my $r = Apache2::RequestUtil-request;
-
-unless ($r) {
-die cannot use $what ,
-without 'SetHandler perl-script' ,
-or 'PerlOptions +GlobalRequest';
-}
-
-$r;
-}
-
{
my $orig_sub = *Apache2::Module::top_module{CODE};
*Apache2::Module::top_module = sub {
@@ -321,6 +307,20 @@
package Apache;
+sub request {
+my $what = shift;
+
+my $r = Apache2::RequestUtil-request;
+
+unless ($r) {
+die cannot use $what ,
+without 'SetHandler perl-script' ,
+or 'PerlOptions +GlobalRequest';
+}
+
+$r;
+}
+
sub unescape_url_info {
my ($class, $string) = @_;
Apache2::URI::unescape_url($string);
svn commit: r627753 - /perl/Apache-Reload/trunk/MANIFEST
Author: phred Date: Thu Feb 14 06:13:58 2008 New Revision: 627753 URL: http://svn.apache.org/viewvc?rev=627753view=rev Log: Forgot to include all.t in the MANIFEST - perhaps I should follow my own additions to RELEASE :) Thanks to Steve Hay for the spot. Modified: perl/Apache-Reload/trunk/MANIFEST Modified: perl/Apache-Reload/trunk/MANIFEST URL: http://svn.apache.org/viewvc/perl/Apache-Reload/trunk/MANIFEST?rev=627753r1=627752r2=627753view=diff == --- perl/Apache-Reload/trunk/MANIFEST (original) +++ perl/Apache-Reload/trunk/MANIFEST Thu Feb 14 06:13:58 2008 @@ -5,6 +5,7 @@ lib/Apache/Reload.pm lib/Apache2/Reload.pm t/conf/extra.last.conf.in +t/all.t t/reload.t t/lib/Apache/TestReload.pm t/lib/Apache2/TestReload.pm
