Perl Modules
Hi, I'm trying to get a bird view of stable available modules with perl, and dwell further on liking, to explore.Could somebody suggest me a descriptive reference bank where I could lay hand on such kind of a material. Regards Kinshuk
Re: Perl Modules
I'm trying to get a bird view of stable available modules with perl, and dwell further on liking, to explore.Could somebody suggest me a descriptive reference bank where I could lay hand on such kind of a material. http://perl.apache.org/src/apache-modlist.html This is how to interpet the status of each module: http://cpan.llarian.net/modules/00modlist.long.html#ID1_ModuleListi Notice though that many modules are marked as dev, while they can safely used in production. It's just that their authors either didn't remember to update the status of the module or they have been brainwashed by their school teachers that there is no such a thing as 100%. :) Also make sure to check Andrew Ford's mod_perl Pocket Reference http://www.oreilly.com/catalog/modperlpr/, which gives an overview of the available modules. _ 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/
Re: strange runtime error
On Wed, 18 Jul 2001, Scott Every wrote:
i have a fairly simple mod-perl script which returns data from a mysql db
on occasion for no apparent reason an internal error screen pops up. if
reloaded the page works just fine.
the logs contain this message:
exit is not exported by the GLOB(0x88414cc) module at (eval 397) line 1
[Wed Jul 18 14:13:29 2001] [error] Can't continue after import errors at
(eval 397) line 1
BEGIN failed--compilation aborted at (eval 397) line 1.
my script doesn't use any 'exit' statements so i am not sure what to do.
any ideas what i'm doing wrong?
You are running under Apache::Registry, aren't you? Check this out:
http://perl.apache.org/guide/porting.html#Terminating_requests_and_process
To debug the problem you need the function calls trace:
Try to install this handler:
require Carp;
$SIG{__DIE__} = \Carp::confess;
so you will see a trace.
Notice that this can break the error propogations within eval {} blocks,
per: http://perl.apache.org/guide/perl.html#Catching_Uncaught_Exceptions
Another approach with recent Perls would be something like this
(including the test case, with properly working eval {} catching blocks):
--
require Carp;
use subs qw(CORE::GLOBAL::die);
*CORE::GLOBAL::die = sub {
if ($_[0] =~ /exit is not exported/){
local *CORE::GLOBAL::die = sub { CORE::die(@_) };
Carp::confess(@_); # Carp uses die() internally!
} else {
CORE::die(@_); # could write CORE::die to forward @_
}
};
eval { foo(); }; warn $@ if $@;
print \n;
eval { poo(); }; warn $@ if $@;
sub foo{ bar(); }
sub bar{ die qq{exit is not exported}}
sub poo{ tar(); }
sub tar{ die normal exit}
--
prints:
$ perl -w test
Subroutine die redefined at test line 5.
exit is not exported at test line 6
main::__ANON__('exit is not exported') called at test line 17
main::bar() called at test line 16
main::foo() called at test line 12
eval {...} called at test line 12
normal exit at test line 5.
the 'local' in:
local *CORE::GLOBAL::die = sub { CORE::die(@_) };
is important, so you won't lose the overloaded CORE::GLOBAL::die.
Matt, how about updating your Exception Handling for mod_perl section to
use my hairy snippet? :) Well I just wrote it, so it's possible it can be
made less hairy :)
*CORE::GLOBAL:: is a cool thing!
_
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/
Re: Using mod_perl to modify referer...
Brian [EMAIL PROTECTED] writes: I have a unique situation in which I need to change the http_referer. What I've done is written a quick script that looks like this: [snip] Now, the problem is this: It works perfectly as long as the client remains on our server. But, if they go to another domain the referer reverts back to what it was before. I need to change it, and have it stay changed. Is there ANY way of doing this with mod_perl? Any help is appreciated. I've been beating my head on the desk for a while here. :o) There is no way to do this. The REFERER field is set by the web client and can not be altered by the server. Once it's sent to the server as part of a HTTP request, the server is free to modify it as it sees fit (as you've done in mod_perl), but it can not tell the client to adopt this new value. Two possible workarounds would be to direct hyperlinks to an intermediate page which in turn redirects the client the final destination. That should set the REFERER correctly to the intermediate page (though perhaps not for 302 redirects). Another possibility would be to abandon using the REFERER field altogether. Use a cookie to encode the necessary information or encode it in the query string of the request itself.
Re: BOF?
On Tue, 17 Jul 2001, Ask Bjoern Hansen wrote: Sunday evening where? sounds like the hotel bar is the only real option. i'll be there 8.30-9pm i guess.
Re: BOF?
[EMAIL PROTECTED] (brian moseley) wrote: On Tue, 17 Jul 2001, Ask Bjoern Hansen wrote: Sunday evening where? sounds like the hotel bar is the only real option. i'll be there 8.30-9pm i guess. Since it seems like Sunday night is the overwhelming favorite, I'll just have to meet up with y'all as-catch-can throughout the week. See you soon! ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
[ANNOUNCE] SOAP::Lite 0.51 (mod_soap and mod_xmlrpc included)
New version of SOAP::Lite has entered CPAN. number of fixes related to different Perl version and platforms number of fixes in XMLRPC::Lite fixed POP3 server added support for SOAP 1.2 (spec is still in draft, implementation is subject to change) added mod_xmlrpc transport (Apache::XMLRPC::Lite) added JABBER transport added MQ transport added TCP over SSL transport added non-blocking TCP multiserver included FastCGI transport modified XML::Parser::Lite to work on Perl 5.005 modified deserializer to work with different schemas (1999/2001) added extended array support (only in deserializer) improved WSDL support modified dispatch for XMLRPC server to work exactly as for SOAP added example with Inline::C module (inline.daemon). Dispatch to C, C++, assembler, Java, Python and Tcl :). all transport are available for both SOAP::Lite and XMLRPC::Lite: HTTP (daemon, CGI, mod_perl), SMTP/POP3, TCP, IO, JABBER, MQ tested on Perl 5.00503, 5.6.0, 5.6.1, 5.7.1 and 5.7.2 updated documentation and added new examples Module is available from http://www.soaplite.com/ and from CPAN. I'll be in SanDiego next week and will answer my emails slowly. Best wishes, Paul. __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
Re: BOF?
On Thu, 19 Jul 2001, brian moseley wrote: On Tue, 17 Jul 2001, Ask Bjoern Hansen wrote: Sunday evening where? sounds like the hotel bar is the only real option. i'll be there 8.30-9pm i guess. my flight arrives at 10:15 so i'll drop by the bar at 11:30 or so. -jwb
Re: [ANNOUNCE] SOAP::Lite 0.51 (mod_soap and mod_xmlrpc included)
On Thu, 19 Jul 2001, Paul Kulchenko wrote: New version of SOAP::Lite has entered CPAN. number of fixes related to different Perl version and platforms number of fixes in XMLRPC::Lite fixed POP3 server added support for SOAP 1.2 (spec is still in draft, implementation is subject to change) added mod_xmlrpc transport (Apache::XMLRPC::Lite) added JABBER transport added MQ transport added TCP over SSL transport added non-blocking TCP multiserver included FastCGI transport modified XML::Parser::Lite to work on Perl 5.005 modified deserializer to work with different schemas (1999/2001) added extended array support (only in deserializer) improved WSDL support modified dispatch for XMLRPC server to work exactly as for SOAP added example with Inline::C module (inline.daemon). Dispatch to C, C++, assembler, Java, Python and Tcl :). all transport are available for both SOAP::Lite and XMLRPC::Lite: HTTP (daemon, CGI, mod_perl), SMTP/POP3, TCP, IO, JABBER, MQ tested on Perl 5.00503, 5.6.0, 5.6.1, 5.7.1 and 5.7.2 updated documentation and added new examples Dunno if you got my email, but I'd like to see the ability to dynamically modify the dispatch tables. At the moment I'm doing it as a hack into your SOAP::Lite internals. -- 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: [ANNOUNCE] SOAP::Lite 0.51 (mod_soap and mod_xmlrpc included)
Hi, Matt!
Dunno if you got my email, but I'd like to see the ability to
dynamically
modify the dispatch tables. At the moment I'm doing it as a hack
into your SOAP::Lite internals.
Sure, I replied the same day (July 13). Recently I had a problem with
my yahoo mail, so I sent you short mail asking whether you got my
reply :)). I though you're busy to answer :)). Fortunately I have a
copy. Here it is.
--- Paul Kulchenko [EMAIL PROTECTED] wrote:
Date: Fri, 13 Jul 2001 10:19:24 -0700 (PDT)
From: Paul Kulchenko [EMAIL PROTECTED]
Subject: Re: adding to dispatch_to
To: Matt Sergeant [EMAIL PROTECTED]
Hi, Matt!
Is there any way I can call dispatch_to, and *add* to the list,
rather than
change it? I'm building Attribute::WebService, where you'll be
able
to say:
sub foo : WebService { ... }, and have it automatically create a
That's so CL! That actually means that we can not only generate
server code (ot simplify it), but also build WebService description
(WSDL) from it. In fact, I was going to talk to you about taglib
for
Axkit that supports SOAP functionality, but I already delayed next
version and want to make a release in a couple of days. Yet we can
definitely talk about it if you're interested.
As for dispatch_to call, you can always do:
$server-dispatch_to($server-dispatch_to, @module_list);
Keep also in mind that dispatching can be done with dispatch_with()
also (which lets you bind specific namespace or SOAPAction to CLASS
or object).
Let me know if you face any problems or if you want to test it with
my current beta. There are many changes, and though they shouldn't
have any influence on this side, we can try just to be on the safe
side. Thanks, Matt, I'm very excited about it. I also plan to use
Attribute::* for providing type/name (instead of using SOAP::Data),
but as far as I know Attribute class is Perl 5.6 and later and I
still want to support 5.004 if possible.
Best wishes, Paul.
Let me know what do you think and we definitely should talk in
SanDiego. Also I didn't find Attribute::WebService on CPAN yet. I
would be glad also to work on SOAP-enabling taglib library and on
better COM integration. Thanks, Matt!
Best wishes, Paul.
--- Matt Sergeant [EMAIL PROTECTED] wrote:
On Thu, 19 Jul 2001, Paul Kulchenko wrote:
New version of SOAP::Lite has entered CPAN.
number of fixes related to different Perl version and platforms
number of fixes in XMLRPC::Lite
fixed POP3 server
added support for SOAP 1.2
(spec is still in draft, implementation is subject to change)
added mod_xmlrpc transport (Apache::XMLRPC::Lite)
added JABBER transport
added MQ transport
added TCP over SSL transport
added non-blocking TCP multiserver
included FastCGI transport
modified XML::Parser::Lite to work on Perl 5.005
modified deserializer to work with different schemas (1999/2001)
added extended array support (only in deserializer)
improved WSDL support
modified dispatch for XMLRPC server to work exactly as for SOAP
added example with Inline::C module (inline.daemon).
Dispatch to C, C++, assembler, Java, Python and Tcl :).
all transport are available for both SOAP::Lite and XMLRPC::Lite:
HTTP (daemon, CGI, mod_perl), SMTP/POP3, TCP, IO, JABBER, MQ
tested on Perl 5.00503, 5.6.0, 5.6.1, 5.7.1 and 5.7.2
updated documentation and added new examples
Dunno if you got my email, but I'd like to see the ability to
dynamically
modify the dispatch tables. At the moment I'm doing it as a hack
into your
SOAP::Lite internals.
--
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 **
\\//
//\\
// \\
__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
[ANNOUNCE] RoboWeb 1.0b, web application test suite generator
I have developed a semi-automatic test generator for web applications. I've called it RoboWeb and it's now available for download from sourceforge, hoping that it can be useful to others. The project page at sourceforge is http://sourceforge.net/projects/roboweb. Here's an excerpt from the README, and after it a comparison with Test::CGI, which is a tool at CPAN whose intent is similar. RoboWeb is a suite of Perl scripts that allow for recording live user browsing sequences and insert assertions during them to later reproduce and automatically verify correctness of output of a web application. Recording test sequences is easy: just fire the roboweb_proxy script and make your browser point to it. The proxy will generate a test sequence script as you browse and you can insert must_match commands in the recorded sequence by entering regular expressions directly in your browser's URL box. These commands get translated into assertions that will be run against the server response text when the sequences are reproduced, to verify that server responses are correct. RoboWeb will also automatically put your web application backend database in a constant 'test-scenario' state before recording test sequences and before executing test scripts. This allows for reliable testing of complex web applications. Also, the recorded test sequence scripts support cookies, which allows them to interact successfully with most web application. After you collect a number of test sequences you can execute them via the TEST script, which will produce standard perl Test::Harness output. COMPARISON WITH THE Test::CGI MODULE The intent of Test::CGI is almost the same. It's about crafting test sequences that will be run against a web application in an automated fashion. The main differences I see between both approaches are: 1. RoboWeb makes it much easier to generate a test suite, because test sequence scripts under it are almost completely machine generated, except assertions, which are easily inserted by entering regexps in the URL box as you browse through your app. Test::CGI instead requires that all HTTP requests be hand coded by the test writer. 2. RoboWeb runs against a live web server, versus Test::CGI, which runs web apps as standalone CGI processes. Test::CGI is less complete in this regard, because it doesn't allow to test apps in the environment they'll be running on (e.g. mod_perl apps that rely on persitent variables are not testable with Test::CGI). 3. The RoboWeb client (which uses LWP::UserAgent and an HTTP::Cookie jar) supports cookies, which allow it to test most web applications. Test::CGI does not support cookies. 4. Test::CGI cannot request plain documents, whereas Roboweb can. 5. Both RoboWeb and Test::CGI produce Test::Harness output. Regards, Claudio Garcia
Re: perlsection syntax--where's tfm?
Randal L. Schwartz wrote: will == will trillich [EMAIL PROTECTED] writes: will http://perl.apache.org/guide/config.html mentions this type of will thing in passing, but surely there's an in-depth will how-this-works somewhere... will Limit GET POST will Order allow,deny will Allow from all will /Limit Uh, actually, not to solve your smaller problem, but to solve your bigger problem instead: STOP LIMITING THE LIMITS. Almost *all* usage of Limit is *wrong*. Just leave it off. (ow. no need to shout! :) i'd done that because i wasn't able to post at all, until i'd added limit postallow everything/ at one time. -- mailto:[EMAIL PROTECTED] http://www.dontUthink.com/
cvs commit: modperl-2.0/Apache-Test/lib/Apache TestRun.pm TestServer.pm
sbekman 01/07/19 18:48:11
Modified:pod modperl_dev.pod
Apache-Test/lib/Apache TestRun.pm TestServer.pm
Log:
--- 1 ---
one of the supported debuggers can be invoked via the -debug switch:
e.g.: run with the defaults: gdb
% ./t/TEST -debug
or use ddd:
% ./t/TEST -debug=ddd
Note that currently we tell 'ddd' to internally use 'gdb'.
--- 2 ---
--breakpoint : set as many breakpoint as needed by repeating the key
e.g:
% ./t/TEST -debug -breakpoint=modperl_cmd_switches \
-breakpoint=modperl_cmd_options
will set the 'modperl_cmd_switches' and 'modperl_cmd_options'
breakpoints and run the debugger. But first it'll set the
'ap_run_pre_config' breakpoint and run till there, since without it we
cannot set breakpoints in mod_perl code if it's loaded via DSO.
If you want to tell the debugger to jump to the start of the mod_perl
code you may run:
% ./t/TEST -debug -breakpoint=modperl_hook_init
In fact --breakpoint automatically turns on the debug mode, so you can
run:
% ./t/TEST -breakpoint=modperl_hook_init
Revision ChangesPath
1.30 +32 -0 modperl-2.0/pod/modperl_dev.pod
Index: modperl_dev.pod
===
RCS file: /home/cvs/modperl-2.0/pod/modperl_dev.pod,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- modperl_dev.pod 2001/07/17 02:10:25 1.29
+++ modperl_dev.pod 2001/07/20 01:48:11 1.30
@@ -232,6 +232,38 @@
then the I-debug shell will have a (gdb) prompt, type 'where' for
stacktrace.
+You can change the default debugger by supplying the name of the
+debugger as an argument to I-debug. E.g. to run the server under
+Cddd:
+
+ % ./t/TEST -debug=ddd
+
+=head2 Advanced Debugging
+
+If you debug mod_perl internals you can set the breakpoints using the
+I-breakpoint option, which can be repeated as many times as
+needed. When you set at least one breakpoint, the server will start
+running till it meets the Iap_run_pre_config breakpoint. At this
+point we can set the breakpoint for the mod_perl code, something we
+cannot do earlier if mod_perl was built as DSO. For example:
+
+ % ./t/TEST -debug -breakpoint=modperl_cmd_switches \
+ -breakpoint=modperl_cmd_options
+
+will set the Imodperl_cmd_switches and Imodperl_cmd_options
+breakpoints and run the debugger.
+
+If you want to tell the debugger to jump to the start of the mod_perl
+code you may run:
+
+ % ./t/TEST -debug -breakpoint=modperl_hook_init
+
+In fact I-breakpoint automatically turns on the debug mode, so you
+can run:
+
+ % ./t/TEST -breakpoint=modperl_hook_init
+
+
=head2 Running Individual Tests
Run a single test:
1.11 +39 -19modperl-2.0/Apache-Test/lib/Apache/TestRun.pm
Index: TestRun.pm
===
RCS file: /home/cvs/modperl-2.0/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- TestRun.pm2001/06/27 06:21:24 1.10
+++ TestRun.pm2001/07/20 01:48:11 1.11
@@ -16,27 +16,30 @@
my @others = qw(verbose configure clean help ping);
my @flag_opts= (@std_run, @others);
my @string_opts = qw(order);
+my @debug_opts = qw(debug);
my @num_opts = qw(times);
-my @list_opts= qw(preamble postamble);
+my @list_opts= qw(preamble postamble breakpoint);
my @hash_opts= qw(header);
-my @exit_opts= qw(clean help ping debug);
+my @help_opts= qw(clean help ping);
+my @exit_opts= (@help_opts,@debug_opts);
my @request_opts = qw(get head post);
my %usage = (
- 'start-httpd' = 'start the test server',
- 'run-tests' = 'run the tests',
- 'times=N' = 'repeat the tests N times',
- 'order=mode' = 'run the tests in one of the modes: (repeat|rotate|random)',
- 'stop-httpd' = 'stop the test server',
- 'verbose' = 'verbose output',
- 'configure' = 'force regeneration of httpd.conf',
- 'clean' = 'remove all generated test files',
- 'help'= 'display this message',
- 'preamble'= 'config to add at the beginning of httpd.conf',
- 'postamble' = 'config to add at the end of httpd.conf',
- 'ping'= 'test if server is running or port in use',
- 'debug' = 'start server under debugger (e.g. gdb)',
- 'header' = add headers to (.join('|', @request_opts).) request,
+ 'start-httpd' = 'start the test server',
+ 'run-tests' = 'run the tests',
+ 'times=N' = 'repeat the tests N times',
+ 'order=mode' = 'run the tests in one of the modes: (repeat|rotate|random)',
+ 'stop-httpd' = 'stop the test server',
+ 'verbose' = 'verbose output',
+
