try
CGI->initialize_globals();
at the begining of the script but before you use params

if you are depending on the 'use CGI' statement to initialize your params (like a 
command line script), it will cause
problems in Registry.  Thats becuase it is initialized once on the initial 'use CGI' 
and it stays in memory for the life
of the webserver.  So each time you use a script, you have to initialize the CGI 
params to your current request.

-----Original Message-----
From: Stas Bekman [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 05, 2003 12:07 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: HTTP POST: parameters "empty" when using ModPerl::Registry
(okay when using ModPerl:PerlRun)...


Steve Bannerman wrote:
> All,
>
> I apologize if this has already been covered...I looked at the archives
> since May but couldn't see anything covering this (there were related items
> but their solutions didn't solve this problem).
>
> Here an explanation of the problem:
>
> We want to post experiment results to an "upload server" which is running
> Apache HTTP Server (2.0.46) and mod_perl (1.99_09).  When we post a sequence
> of files to the server, some of them are written to the local disk and some
> are not.  That is, the test fails when using ModPerl::Registry but it
> succeeds when using ModPerl::PerlRun.
>
> In analyzing which ones work and which ones do not, I wrote a quick test to
> see why the transfer is not working.  From the looks of the results, it
> appears that the first request handled by a particular Apache process/thread
> "works" and that any subsequent requests handled by that thread "fail."
> Works means that the file in the test gets saved to disk and fail means that
> a file of size "0" gets written to disk.
>
> Below are the httpd.conf segments (working and failing), the test client
> (test_client.pl) and the test server (test_server.pl which is accessible
> from the /cpdn/cgi-bin location).
>
> Any suggestions?  Thanks in advance...
>
> Also, does it matter if I use ModPerl::PerlRun instead of ModPerl::Registry
> (I have read some about this at
> http://apache.perl.org/docs/2.0/api/ModPerl/Registry.html but the
> documentation there is a little light).

The docs need work, this is just a copy of mp1 registry docs, which need
adjustments. However most things work the same way. The differences between
Registry and PerlRun are easily summarizes with this diff:

ModPerl-Registry> diff -u lib/ModPerl/Registry.pm lib/ModPerl/PerlRun.pm
--- lib/ModPerl/Registry.pm     2003-03-22 20:52:24.000000000 -0800
+++ lib/ModPerl/PerlRun.pm      2003-03-22 20:52:24.000000000 -0800
@@ -1,4 +1,4 @@
-package ModPerl::Registry;
+package ModPerl::PerlRun;

  use strict;
  use warnings FATAL => 'all';
@@ -30,11 +30,11 @@
      make_namespace  => 'make_namespace',
      namespace_root  => 'namespace_root',
      namespace_from  => 'namespace_from_filename',
-    is_cached       => 'is_cached',
-    should_compile  => 'should_compile_if_modified',
-    flush_namespace => 'NOP',
+    is_cached       => 'FALSE',
+    should_compile  => 'TRUE',
+    flush_namespace => 'flush_namespace_normal',
      cache_table     => 'cache_table_common',
-    cache_it        => 'cache_it',
+    cache_it        => 'NOP',
      read_script     => 'read_script',
      rewrite_shebang => 'rewrite_shebang',
      set_script_name => 'set_script_name',
@@ -53,17 +53,10 @@

PerlRun doesn't cache the script on each request and it flushes the script's
namespace on each request. You can see the actual functions in
lib/ModPerl/RegistryCooker.pm. If you can try to take it from here and see
what the problem is (your code/registry?), that would be cool. Thanks.

Also make sure you are using the latest CGI.pm (2.93 or higher is good).

__________________________________________________________________
Stas Bekman            JAm_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


Reply via email to