FW: porting from mod_perl1 to mod_perl2
Randy, Did that (made sure to uninstall first). (made sure to replace the mod_perl.so as well) But no cure. I'm still getting the dreaded '8211=>entity: 150'. But it was worth a try Bart PS: Oh Randy and a big thanks of course for maintaining the ppms. It makes the life for the rest of us (mere mortals who dislike compiling) so much easier. -Original Message- From: Randy Kobes [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 10, 2003 7:00 AM To: Bart Terryn Cc: Stas Bekman; [EMAIL PROTECTED] Subject: RE: porting from mod_perl1 to mod_perl2 On Tue, 9 Sep 2003, Bart Terryn wrote: > Stas, > > Sorry to insist. > But here I am again... > > Stas wrote: > >Actually I haven't looked, I have tested with your code. > Thanks a lot for going through the effort... > > >Before setting the header I wasn't getting the unicode > >chars you put in the form back in the dump. After setting > >the header it did print out exacly the same unicode > >character. > > Well that is strange. I just changed my code and still am > getting the endash back as code 150 and not as the 8212 > code (the way it went in). If you're using ppm to install mod_perl, could you try the latest version at http://theoryx5.uwinnipeg.ca/ppms/? There were some changes made recently that may affect the above problem. Note that the version in the mod_perl.ppd hasn't changed, so you may have to uninstall mod_perl and then install it to force ppm to upgrade. -- best regards, randy kobes
RE: porting from mod_perl1 to mod_perl2
On Tue, 9 Sep 2003, Bart Terryn wrote: > Stas, > > Sorry to insist. > But here I am again... > > Stas wrote: > >Actually I haven't looked, I have tested with your code. > Thanks a lot for going through the effort... > > >Before setting the header I wasn't getting the unicode > >chars you put in the form back in the dump. After setting > >the header it did print out exacly the same unicode > >character. > > Well that is strange. I just changed my code and still am > getting the endash back as code 150 and not as the 8212 > code (the way it went in). If you're using ppm to install mod_perl, could you try the latest version at http://theoryx5.uwinnipeg.ca/ppms/? There were some changes made recently that may affect the above problem. Note that the version in the mod_perl.ppd hasn't changed, so you may have to uninstall mod_perl and then install it to force ppm to upgrade. -- best regards, randy kobes
RE: porting from mod_perl1 to mod_perl2
Stas,
Sorry to insist.
But here I am again...
Stas wrote:
>Actually I haven't looked, I have tested with your code.
Thanks a lot for going through the effort...
>Before setting the
>header I wasn't getting the unicode chars you put in the form back in the
>dump. After setting the header it did print out exacly the same unicode
character.
Well that is strange. I just changed my code and still am getting the endash
back as code 150 and not as the 8212 code (the way it went in).
Are you sure that you have the 2 lines in the test program that change the
multibyte utf-8 encoded characters into their values?
(the famous lines 11 and 12)
Because if not, then I can understand that you have to put the changed
header in as you would be sending utf-8 encoded data to the client.
And it would also explain why you would 'see' the same character after
putting the utf-8 header in.
>I didn't have a chance to mess with the hex representations yet.
That makes me wonder even more about the thing above.
[...]
>I think this is where the weak point is. You need to compare characters on
the
>server side, not trying to rely on the browser, which as you have seen will
>render them improperly if you didn't set the right header.
Again that is the purpose of the dreaded lines 11 and 12 of my test program.
I don't want to render the character, I just want to display the actual
(utf-8 encoded) code that I read back from the form.
>You have two things happening: read input, send output. The problem can be
in
>any of the two and worse, it can be in both and the error can fix itself
when
>doubled. You need to verify first that the input is read properly, then the
>same for the output.
Believe me.
I also ran tests that write out the data to disk and then used a hex dump of
that file to actually verify what is in there. I got the same results. But
that go a bit tedious hence my little test program that does more or less
the same thing.
For your convenience here is the test program again
You will note that I change the $q->header print statement, but as said
before the outcome is still wrong.
Could you confirm that you indeed used this script unmodified and still are
recieving correct output?
As said the important part is in line 11 and 12.
You will need perl 5.8 in order to make those 2 lines work properly
(5.6 does not understand unicode correctly)
#!/perl/bin/perl.exe
use strict;
use CGI;
use CGI::Carp qw(fatalsToBrowser);
use CGI::Cookie;
my $q = CGI->new;
my $content = $q->param("utf8-test");
$content .= "verify with \x{2014}";
my @content = unpack('U*', $content);
$content =~ s/([\x{0800}-\x{}])/sprintf('+entity:%d+',ord($1))/ge;
$content =~ s/([\x{0080}-\x{07FF}])/sprintf('+entity: %d+',ord($1))/ge;
print $q->header("text/html; charset=utf-8");
print $q->p($content);
print $q->p('hex');
foreach (@content) {printf "%x ", $_}
>I have started writing the test for mp2 to verify utf8 input, hopefully
I'll
>finish it soon.
Thanks a lot for your support...
Bart
Re: porting from mod_perl1 to mod_perl2
Bart Terryn wrote:
Stas and all of the others,
Stas said:
I think I got your problem solved, you need to:
- print $q->header();
+ print $q->header("text/html; charset=utf-8");
Well actually you did not.
Probably you looked a bit too fast.
(forgivable in view of the numbers of mails you reply to:-)
Actually I haven't looked, I have tested with your code. Before setting the
header I wasn't getting the unicode chars you put in the form back in the
dump. After setting the header it did print out exacly the same unicode character.
I didn't have a chance to mess with the hex representations yet.
[...]
(Oh did I mention already that I have tested only against IE6, because the
browser could be the cause as well of this odd(?) behaviour.)
I think this is where the weak point is. You need to compare characters on the
server side, not trying to rely on the browser, which as you have seen will
render them improperly if you didn't set the right header.
You have two things happening: read input, send output. The problem can be in
any of the two and worse, it can be in both and the error can fix itself when
doubled. You need to verify first that the input is read properly, then the
same for the output.
I have started writing the test for mp2 to verify utf8 input, hopefully I'll
finish it soon.
__
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: porting from mod_perl1 to mod_perl2
Stas and all of the others,
Stas said:
>I think I got your problem solved, you need to:
>- print $q->header();
>+ print $q->header("text/html; charset=utf-8");
Well actually you did not.
Probably you looked a bit too fast.
(forgivable in view of the numbers of mails you reply to:-)
The utf8-test.pl code is reading what comes out of the form (which has a
charset=utf-8 meta tag, so that is OK, see my previous mail)
The utf8-test.pl then replaces the characters higher the 7F with char. ref
entities but with the string '+entity: ' in front of the value(see below
lines 11 and 12 of utf8-test.pl).
And to double verify the information read back from the form is also
unpacked from unicode values into their hex counterparts.
And then both strings are printed out as normal low ascii characters (<7f),
so no need to set the utf-8 flag here.
>From further testing I have seen that only unicode characters that actually
have a representation in the win1252 characters set come back under their
corresponding win1252 characterset position.
So the form would for example contain an ndash character (unicode position
dec 8211 or U+2013) .
But that is read back as character dec 150 or hex 96.
And if the form contains a right single quotation (unicode position dec 8217
or U+2019), it comes back under its win1252 position of dec 146 or hex 92.
I would have expected if I send something in under its unicode position, it
would come back to me under its unicode position.
But then again I may be wrong.
And the utf8 flag in the header only means that is will be utf8 encoded and
should not be confused with the characterset used.
I am under the impression I confusing myself more and more here.
So if somebody has been on this path before and knows the truth, let him
speak up!
(Oh did I mention already that I have tested only against IE6, because the
browser could be the cause as well of this odd(?) behaviour.)
Thanks all for your patience.
I would really like to get to the bottom of this.
Bart
Here is utf8-test.pl, again this time with line numbers
1:#!/perl/bin/perl.exe
2:use strict;
3:use CGI;
4:use CGI::Carp qw(fatalsToBrowser);
5:
6:my $q = CGI->new;
7:my $content = $q->param("utf8-test");
8:$content .= "verify with \x{2014}";
9:my @content = unpack('U*', $content);
10:$content =~ s/([\x{0800}-\x{}])/sprintf('+entity:%d+',ord($1))/ge;
11:$content =~ s/([\x{0080}-\x{07FF}])/sprintf('+entity: %d+',ord($1))/ge;
12:print $q->header();
13:print $q->p($content);
14:print $q->p('hex');
15:foreach (@content) {printf "%x ", $_}
and here is the htlm form that triggers the utf8-test.pl:
http://www.w3.org/1999/xhtml"; lang="en">
test: ë —
and here is the result this all produces:
test: +entity: 235+ +entity: 151+verify with +entity:8212+
hex
74 65 73 74 3a 20 eb 20 97 76 65 72 69 66 79 20 77 69 74 68 20 2014
Re: porting from mod_perl1 to mod_perl2
I think I got your problem solved, you need to:
- print $q->header();
+ print $q->header("text/html; charset=utf-8");
__
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: porting from mod_perl1 to mod_perl2
I had version CGI 3.00 installed. Downgraded it to CGI 2.93, put I still have the same result. The problem as I see it that I have a form with character — in it. But it is returned as character — from the Widows-1252 characterset. Does everybody agree that it should be returned as — (the utf-8 representation I mean)? See my previous mail for the test I used. Bart -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED] Sent: Saturday, September 06, 2003 8:35 AM To: Philip M. Gollucci Cc: Perrin Harkins; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: porting from mod_perl1 to mod_perl2 Philip M. Gollucci wrote: > If you check out the changes to CGI.pm on Licoln Stiens web site, utf8 > was added via a path by someone else > 2.99 - 3.00 likely this is the cause. Bart, can you try then with an earlier version? e.g. 2.93 was good for me. You can get it from here: http://www.cpan.org/authors/id/L/LD/LDS/ __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
RE: porting from mod_perl1 to mod_perl2
Stas wrote:
>Bart, can you test whether you have the same problem when a run the same
code
>under mod_cgi in Apache2 (with perl5.8 ofcourse)? If not, that will point
the
>blaming finger towards mod_perl 2.0.
Well I did that and guess what? mod_cgi fails as well.
So it is not a mod_perl problem
But for me it is still uncertain who to blame. (cgi.pm? apache2? perl5.8?)
I made a small test for this.
Just in case somebody wants to give it a try
Here is my sample page:
-
http://www.w3.org/1999/xhtml"; lang="en">
test: ë —
--
Here is the utf8-test.pl:
---
#!/perl/bin/perl.exe
use strict;
use CGI;
use CGI::Carp qw(fatalsToBrowser);
my $q = CGI->new;
my $content = $q->param("utf8-test");
$content .= "verify with \x{2014}";
my @content = unpack('U*', $content);
$content =~ s/([\x{0800}-\x{}])/sprintf('+entity:%d+',ord($1))/ge;
$content =~ s/([\x{0080}-\x{07FF}])/sprintf('+entity: %d+',ord($1))/ge;
print $q->header();
print $q->p($content);
print $q->p('hex');
foreach (@content) {printf "%x ", $_}
---
and here is the output I get:
test: +entity: 235+ +entity: 151+verify with +entity:8212+
hex
74 65 73 74 3a 20 eb 20 97 76 65 72 69 66 79 20 77 69 74 68 20 2014
--
>From which I understand that the original character — is returned as
hex 97 or dec 151.
And would be correct if the characterset would be window-1252 but that is
not what I expected.
Wanted utf-8 to be returned.
If mod_perl is not the correct forum for this (which I agree it isn't) can
somebody point me in the direction of a correct forum? But as said before
the difficulty is that I don't know who to blame
Kind Regards,
Bart
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: porting from mod_perl1 to mod_perl2
Philip M. Gollucci wrote: If you check out the changes to CGI.pm on Licoln Stiens web site, utf8 was added via a path by someone else 2.99 - 3.00 likely this is the cause. Bart, can you try then with an earlier version? e.g. 2.93 was good for me. You can get it from here: http://www.cpan.org/authors/id/L/LD/LDS/ __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: porting from mod_perl1 to mod_perl2
If you check out the changes to CGI.pm on Licoln Stiens web site, utf8 was added via a path by someone else 2.99 - 3.00 likely this is the cause. Stas Bekman wrote: Perrin Harkins wrote: I am fairly sure it is not perl5.8. I'm fairly sure it is. What is your locale set to? Are you on Red Hat? See previous discussions of locale issues on Red Hat 8 and 9 in the list archives. Bart is on win32, AS Perl 5.8. I doubt it's a locale issue, since it's the client who decides what encoding the data is in, it's either CGI.pm (guessing that what he was using to parse the forms) or more low level (io) issues. Bart, can you test whether you have the same problem when a run the same code under mod_cgi in Apache2 (with perl5.8 ofcourse)? If not, that will point the blaming finger towards mod_perl 2.0. Someone volunteers to add a new test? See t/modperl/print_utf8.t t/response/TestModperl/print_utf8.pm for an example of testing the responding with utf8 data. You can probably adopt one of these couples for testing the posting of utf8 data: t/apache/cgihandler.t t/response/TestApache/cgihandler.pm t/modules/cgi.t t/response/TestModules/cgi.pm t/modules/cgiupload.t t/response/TestModules/cgiupload.pm of course you will want to create a new couple of files for this test. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: porting from mod_perl1 to mod_perl2
On Fri, 2003-09-05 at 21:36, Stas Bekman wrote: > Bart is on win32, AS Perl 5.8. Oops, sorry Bart, I missed that. Even so, I'm suspicious that 5.8 and all of its unicode changes are involved somehow. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: porting from mod_perl1 to mod_perl2
Perrin Harkins wrote: I am fairly sure it is not perl5.8. I'm fairly sure it is. What is your locale set to? Are you on Red Hat? See previous discussions of locale issues on Red Hat 8 and 9 in the list archives. Bart is on win32, AS Perl 5.8. I doubt it's a locale issue, since it's the client who decides what encoding the data is in, it's either CGI.pm (guessing that what he was using to parse the forms) or more low level (io) issues. Bart, can you test whether you have the same problem when a run the same code under mod_cgi in Apache2 (with perl5.8 ofcourse)? If not, that will point the blaming finger towards mod_perl 2.0. Someone volunteers to add a new test? See t/modperl/print_utf8.t t/response/TestModperl/print_utf8.pm for an example of testing the responding with utf8 data. You can probably adopt one of these couples for testing the posting of utf8 data: t/apache/cgihandler.t t/response/TestApache/cgihandler.pm t/modules/cgi.t t/response/TestModules/cgi.pm t/modules/cgiupload.t t/response/TestModules/cgiupload.pm of course you will want to create a new couple of files for this test. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: porting from mod_perl1 to mod_perl2
Bart Terryn wrote: Hi, I have an application running under apache 1.37(win32)/mod_perl1.27_01-dev/perl5.6 build 633 I am trying to move this application to apache 2.0.47(win32)/mod_perl1.99_10-dev/perl 5.8 However I run into a problem with character encoding. Somewhere in this app I put up a form that contains text. The encoding of the html page that contains this form is set to 'utf-8' by the following: That form displays OK in both mod_perl1.0 and mod_perl2.0 When I read the form back under the apache1, everything is OK. When I do the same using the apache 2 combination I run into trouble with the char ref entities entities which are high in the unicode set like: — or –. These characters are returned as unicode characters hex 97 and hex 96. Returned from where? CGI.pm? Does your 'perl -V:useperlio' reports: useperlio='define'; If so, can you give a try with the latest mp2 cvs? However I think it won't change anything, since the only change is that since now perlio is used, you can binmode it to 'utf8'. I have just added tests for sending utf8 data, but we probably need to add the receiving utf8 data as well. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
RE: porting from mod_perl1 to mod_perl2
On Fri, 2003-09-05 at 19:14, Bart Terryn wrote: > PS: some might say that this has nothing to do with mod_perl I would say that, but it's okay, you didn't know. > I am fairly sure it is not perl5.8. I'm fairly sure it is. What is your locale set to? Are you on Red Hat? See previous discussions of locale issues on Red Hat 8 and 9 in the list archives. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
RE: porting from mod_perl1 to mod_perl2
Hi there, On Sat, 6 Sep 2003, Bart Terryn wrote: > Hi, > > I have an application running under apache > 1.37(win32)/mod_perl1.27_01-dev/perl5.6 build 633 > > I am trying to move this application to apache > 2.0.47(win32)/mod_perl1.99_10-dev/perl 5.8 > > However I run into a problem with character encoding. Have you checked perldoc perllocale ? 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
RE: porting from mod_perl1 to mod_perl2
Hi, I have an application running under apache 1.37(win32)/mod_perl1.27_01-dev/perl5.6 build 633 I am trying to move this application to apache 2.0.47(win32)/mod_perl1.99_10-dev/perl 5.8 However I run into a problem with character encoding. Somewhere in this app I put up a form that contains text. The encoding of the html page that contains this form is set to 'utf-8' by the following: That form displays OK in both mod_perl1.0 and mod_perl2.0 When I read the form back under the apache1, everything is OK. When I do the same using the apache 2 combination I run into trouble with the char ref entities entities which are high in the unicode set like: — or –. These characters are returned as unicode characters hex 97 and hex 96. Other character ref entities like the one for e (e umlaut = ë) are returned correctly. So I assume that only characters above 07FFF are returned wrong. Anybody any idea? Thanks in advance Bart PS: some might say that this has nothing to do with mod_perl. And maybe you are right, but I have no clue which part might be causing this. I am fairly sure it is not perl5.8. Although in order to make the apache2/mod_perl2 combination to work I had to upgrade the CGI.pm to version 3.0 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
[ANNOUNCE] mp2: new porting assister package Apache::porting
Apache::porting tries to help you to do the porting to mod_perl 2.0. For more information please refer to: http://perl.apache.org/docs/2.0/api/Apache/porting.html It's a new module and didn't go through much testing. However make sure to check the known issues, before reporting problems: http://perl.apache.org/docs/2.0/api/Apache/porting.html#Culprits Finally, as of this writing you need to get the cvs version of mod_perl 2.0 to get it working. It'll be available in modperl-1.99_10, when it will be released. __ 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: Porting Orphans : (was: apache::sandwich)
[EMAIL PROTECTED] wrote: This brings up a good point, is there a list of 'ModPerl Orphans' anywhere? For the most part I would imagine that a modules author/maintainer will manage the transition to mp2 but there must be a ton of modules that are Orphans with little hope of making it over unless some kind developer makes it happen. It would be pretty great if there was a list and people could start taking responsibility for the tasks to avoid duplicate work as well as to guide folks who have time to contribute and are not sure where to start. Lame suggestion most likely. I was just thinking 'I would like to try to port something but where to start' If there is interest in this I can put up a page for this sort of thing and send email out to all of the existing authors, hunting for orphans to post. It's a good idea to compile a list of modules that need to get ported, discarding those that aren't needed in mp2 (e.g. Apache::Filter and FilterChain are definitely to stay in the mp1 world I believe). However there is a problem with porting modules that include XS code, since the replacement for Apache::src hasn't been completed yet. Pure perl modules porting should be fine. FWIW, I've ported Apache::Peek and Apache::Scoreboard to 2.0, but I can't release them yet as they need a support from mod_perl-2.0 (because of Apache::src/xs stuff), which wasn't committed yet. We are hoping to deliver a much better Makefile.PL support (including things like installing into Apache2/ and automatic configuration of the MM attributes for compilation) __ 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
Porting Orphans : (was: apache::sandwich)
This brings up a good point, is there a list of 'ModPerl
Orphans' anywhere? For the most part I would imagine that
a modules author/maintainer will manage the transition to
mp2 but there must be a ton of modules that are Orphans
with little hope of making it over unless some kind
developer makes it happen.
It would be pretty great if there was a list and people
could start taking responsibility for the tasks to avoid
duplicate work as well as to guide folks who have time to
contribute and are not sure where to start.
Lame suggestion most likely. I was just thinking 'I would
like to try to port something but where to start'
If there is interest in this I can put up a page for this
sort of thing and send email out to all of the existing
authors, hunting for orphans to post.
John-
On Mon, 10 Mar 2003 12:31:05 -0800 (PST)
Nick Tonkin <[EMAIL PROTECTED]> wrote:
Another option would be for you to port Apache::Filter to
run under mp2.
Then your code as well as anyone else's who uses that
module would run
unchanged under mp2. That would be a Good Thing and you'd
be a mod_perl
hero. People on this list would help if you got stuck,
and the
documentation for porting is getting quite extensive.
This doc:
http://perl.apache.org/docs/2.0/devel/porting/porting.html
is
what you want.
Good luck,
- nick
--
Nick Tonkin {|8^)>
porting modules to mp2 docs are updated
Since the questions of porting to mp 2.0 are on raise, and there is some confusion regarding use of Apache::compat. I've done a massive porting docs update: Please review the following if you are involved in porting, and let me know if I've missed something or if something is still unclear: http://perl.apache.org/docs/2.0/devel/porting/porting.html http://perl.apache.org/docs/2.0/api/Apache/compat.html http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html p.s. the site is being updated right now, so please wait for 20 minutes or so as the pdfs are crunched. __ 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: [mp2] porting tip - DefaultType text/html
Nick Tonkin wrote: As the docs say $r->send_http_header is deprecated because it is unneeded in mp2 ... but $r->content_type must be set. Just a minor nit: $r->send_http_header is *not* deprecated, it's *gone*. Since yesterday for it's gone for real and is only available only in the back compatibility layer Apache::compat. So if you choose to use Apache::compat you can keep it, if you don't use Apache::compat you have to remove it. __ 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
[mp2] porting tip - DefaultType text/html
As the docs say $r->send_http_header is deprecated because it is unneeded
in mp2 ... but $r->content_type must be set.
DefaultType is set by default to text/plain in httpd.conf, so browsers
that strictly apply content_type (eg Opera 7) were showing the content as
HTML source.
I had several handlers that simply called $r->send_http_header so
replacing each occurence with $r->content_type wasn't much of an
improvement in code cleanliness and simplicity, if that's what the goal of
eliminating send_http_headers was in the first place.
Therefore, I changed DefaultType from text/plain to text/html and voila --
I don't have to set $r->content_type after all but rather can just delete
all the $r->send_http_headers calls.
YMMV, of course, if you have other parts of your webserver that do not
supply a content-type :)
- nick
--
Nick Tonkin {|8^)>
[mp2] porting tip - must return OK from content-handlers
I had some handlers that did not explicitly return OK -- just printed the
coontent and quit. In apache1/mp1 this 'worked' fine.
After migrating to apache2/mp2 these handlers delivered the content to the
browser but then printed a 500 error message to the browser but _not_ to
the error log.
Just a heads-up.
- nick
--
Nick Tonkin {|8^)>
Re: Need Porting Sanity Check
Hi there, Sorry there's a lot to digest all at once in your message, but here's one tip: On Sat, 29 Jun 2002, Jeff wrote: > - Use 'open my $fh, $filename or die $!; wherever I open files Use Symbol::gensym if you can, it makes dealing with files much less accident prone. 73, Ged.
Re: Need Porting Sanity Check
Jeff wrote:
> So here is my strategy that I would like a sanity check from anyone on.
> Go through and quickly clean up my existing code by adding use strict
> and localizing all my variables (with 'my' and 'local' for special
> variables) and then run is under mod_Perl using the Apache::PerlRun.
> Write all my new code so that it will run under Apache::Registry and
> then when I have spare time (ya right) go work on porting the older code.
PerlRun works reasonably well, and I have used it to quickly port a
large amount of legacy CGI code that made extensive use of globals.
However, it is only very slightly different from Apache::Regsitry. The
difference is that globals get cleared after each invocation, so you
don't have to worry about them retaining values.
You will not have problems with subroutines creating closures if you're
using global variables. You also won't have problems if you're passing
varaibles to subroutines. You will only have trouble if you use
lexicals in your subs that are defined outside the scope of the sub.
This is bad:
my $foo = 7;
print_foo();
sub print_foo {
print "$foo\n";
}
But this is not:
my $foo = 7;
print_foo($foo);
sub print_foo {
my $foo = shift;
print "$foo\n";
}
One thing that I had to change when moving to PerlRun was that the
existing scripts made extensive use of libraries that were not proper
modules, i.e. they did not declare packages, but just used a simple
"require lib.pl" to define a bunch of stuff in the current namespace.
That doesn't work with PerlRun or Registry. There are various
approaches for dealing with this, the quickest and worst being to change
the "require file" to a "do file". The best is to make them actual modules.
- Perrin
Re: Need Porting Sanity Check
Jeff wrote: > Hey thanks for the reply. I am making progress but I have run into a > problem where when I have PerlRun enabled my scripts are not see the > field values being passed in the URL. I'm still using cgi-lib.pl not > CGI.pm. I've never used cgi-lib.pl and you shouldn't either. That package has been deprecated for many years. > By the way, do you know if PerlRun caches CGI.pm because I know > otherwise it takes longer to load than the old cgi-lib.pl CGI.pm -- and any other external modules you use -- will be cached when used from PerlRun. The only thing that isn't cached is your script itself. - Perrin
Re: Need Porting Sanity Check
Jeff Crist wrote: > Excuse my typos, I just wanted to clarify I added 'use strict;' not 'use > stricts;' to my code along with the -w operator (#!/usr/bin/perl -w) and > I'm not seeing all the errors in my logs. Because probably your code was clean in first place. Good for you. BTW, PerlWarn On in httpd.conf is an easier way to enable warnings everywhere. __ 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
Need Porting Sanity Check
Title: Message Excuse my typos, I just wanted to clarify I added 'use strict;' not 'use stricts;' to my code along with the -w operator (#!/usr/bin/perl -w) and I'm not seeing all the errors in my logs.
Need Porting Sanity Check
Title: Message I have a 'medium' traffic e-commerce site (about 30GB xfer a month). It is mostly written in Perl (about 40 scripts or 4,000 lines of code). We have had no problems with performance to date but in preparation for future growth (in addition to other changes to the site's scripts) I thought it would be a good idea to switch from CGI to Mod_Perl. I read all of Stas Bekman's Porting Guidelines and looked at my scripts. While I have a long programming history, I must admit I started cranking out the code (in a nice modular fashion) as soon as I grasped the basic of the language, ignoring things like the -w operator, use strict;, and only used variable localization (my) in some of my subroutines. I have determined that as a result, I would have quite a bit of work to do to move to modPerl (using Apache::Registry) including: - avoid inner subrouting nesting problem by having all Perl scripts called by the webserver only executive code in included files (using require from a main script) - make all variables localized using 'my' and special variables using local (although my coding is sloppy from a localization standpoint, it is written so it doesn't even need global variables - all variables are passed through the subroutines properly even though I forgot to specifically localize them) - Make sure required files are reloaded after modification by setting PerlInitHandler to Reload, Setting PerlSetVar ReloadAll Off, and then when I am developing including Apacher::Reload in the scripts I am working on, then taking it out when they go into production (this was the method that made the most sense to me.) - I actually didn't really understand the problem with testing from the shell and using CGI::Switch or CGI.pm - Use '^T = time' in the scripts that I test filetime to determine its age - Use 'open my $fh, $filename or die $!; wherever I open files to insure they get closed properly That's going to be A LOT of work and I have lots of other modifications to do. So then I get to his section titled 'Apache::PerlRun--a closer look' and come to find out that Apache:PerlRun is basically a nice compromise offering some (not all) of the performance benefits of mod_Perl while not forcing you to have to drastically clean up your code. So here is my strategy that I would like a sanity check from anyone on. Go through and quickly clean up my existing code by adding use strict and localizing all my variables (with 'my' and 'local' for special variables) and then run is under mod_Perl using the Apache::PerlRun. Write all my new code so that it will run under Apache::Registry and then when I have spare time (ya right) go work on porting the older code. On thing that is interesting is that even though I added the -w operator to the end of #!/usr/bin/perl in my scripts and added use stricts; I am not seeing the hundreds of error messages I should see in either error_log or suexec_log. Any ideas? Thanks.
Re: Porting to mod_perl and cookies are breaking. Why?
At 23:55 10.06.2002, Mark Korey wrote:
>We found the problem ... this was an odd one (aren't most!?!).
>Turns out that the path (i.e. $cgi->cookie(-path =>'/', ...); )
>was NOT being set. Guess we assumed that CGI.pm would default it to '/'.
>Setting that seemed to do the trick.
>We are using CGI.pm and did not need to "PerlSetupEnv On".
It's the default to have it On, that's why it got me wondering.
>I'm still not sure why this works differently under mod_perl.
Probably not mod_perl's fault at all, you might have been using a different
path before (or maybe a different vresion of CGI.pm?)
>Semi-related to this, isn't $cgi->cookie just an API which
>uses $ENV{HTTP_COOKIE}?
CGI.pm has mod_perl-related code under the hood. I'm not sure if the same
applies to CGI::Cookie (which is used for $cgi->cookie).
>What's the big advantage of Apache::Cookie?
It's C, so it's faster. It uses the Apache API. You won't have to do things
like print $cgi->header(-cookie => ...), you just do $cookie->bake; But
basically, you don't need it yet.
>I'd like to keep my code as flexible & compatible as possible
>so it will run under both standard CGI & mod_perl, at least
>while we work the kinks out of our mod_perl configuration.
In that case, just keep your current code. You'll only have the use for the
likes of Apache::Cookie when you start moving to the Apache Perl API anyway.
>On Mon, 10 Jun 2002, Per Einar Ellefsen wrote:
>
> > At 05:43 10.06.2002, Mark Korey wrote:
> > >ENV{HTTP_COOKIE} does not contain a newly set cookie, often it
> > >still contains an old value when I try to change it (ie switch to a
> > >different user).
> > >Everything else appears to be working fine.
> >
> > If you're saying that $ENV{HTTP_COOKIE} is empty, you should set
> > "PerlSetupEnv On" in your Location section. See
> > http://perl.apache.org/release/docs/1.0/guide/config.html#PerlSetupEnv
> >
> > Could we see your code (an excerpt showing the problem)? You might be doing
> > something wrong when trying to set cookies. Furthermore, you should really
> > be using CGI.pm, CGI::Cookie or Apache::Cookie for your cookie needs.
--
Per Einar Ellefsen
[EMAIL PROTECTED]
Re: Porting to mod_perl and cookies are breaking. Why?
We found the problem ... this was an odd one (aren't most!?!).
Turns out that the path (i.e. $cgi->cookie(-path =>'/', ...); )
was NOT being set. Guess we assumed that CGI.pm would default it to '/'.
Setting that seemed to do the trick.
We are using CGI.pm and did not need to "PerlSetupEnv On".
I'm still not sure why this works differently under mod_perl.
Semi-related to this, isn't $cgi->cookie just an API which
uses $ENV{HTTP_COOKIE}?
What's the big advantage of Apache::Cookie?
I'd like to keep my code as flexible & compatible as possible
so it will run under both standard CGI & mod_perl, at least
while we work the kinks out of our mod_perl configuration.
Thanks.
- Mark
www.fantasycup.com
On Mon, 10 Jun 2002, Per Einar Ellefsen wrote:
> At 05:43 10.06.2002, Mark Korey wrote:
> >ENV{HTTP_COOKIE} does not contain a newly set cookie, often it
> >still contains an old value when I try to change it (ie switch to a
> >different user).
> >Everything else appears to be working fine.
>
> If you're saying that $ENV{HTTP_COOKIE} is empty, you should set
> "PerlSetupEnv On" in your Location section. See
> http://perl.apache.org/release/docs/1.0/guide/config.html#PerlSetupEnv
>
> Could we see your code (an excerpt showing the problem)? You might be doing
> something wrong when trying to set cookies. Furthermore, you should really
> be using CGI.pm, CGI::Cookie or Apache::Cookie for your cookie needs.
>
>
> --
> Per Einar Ellefsen
> [EMAIL PROTECTED]
Re: Porting to mod_perl and cookies are breaking. Why?
At 05:43 10.06.2002, Mark Korey wrote:
>ENV{HTTP_COOKIE} does not contain a newly set cookie, often it
>still contains an old value when I try to change it (ie switch to a
>different user).
>Everything else appears to be working fine.
If you're saying that $ENV{HTTP_COOKIE} is empty, you should set
"PerlSetupEnv On" in your Location section. See
http://perl.apache.org/release/docs/1.0/guide/config.html#PerlSetupEnv
Could we see your code (an excerpt showing the problem)? You might be doing
something wrong when trying to set cookies. Furthermore, you should really
be using CGI.pm, CGI::Cookie or Apache::Cookie for your cookie needs.
--
Per Einar Ellefsen
[EMAIL PROTECTED]
Porting to mod_perl and cookies are breaking. Why?
Hi,
We're in the process of setting up mod_perl on a site which uses cookies
to perform user authentication. Everything worked fine before mod_perl,
but now the cookie is not set when we check for it.
I've searched the web & "Developer's Cookbook", but can't find any
references
to this type of problem, so I'm turning here!
We have not tried Apache::Cookie yet, I'm hoping that, while it might be
a good solution, it won't be *required*.
Here's what we got:
Embedded Perl version 5.00503 for Apache/1.3.9 (Unix) mod_perl/1.27
and in httpd.conf:
PerlRequire /opt/apache/FSE/share/cgi-bin/start-up.pl
PerlFreshRestart On
Alias /home/ /opt/apache/FSE/share/cgi-bin/
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
PerlSendHeader On
*Why* are cookies not readable?
*How* do we get them working??
ENV{HTTP_COOKIE} does not contain a newly set cookie, often it
still contains an old value when I try to change it (ie switch to a
different user).
Everything else appears to be working fine.
Thanks!
---
mlk @ korey.net
www.fantasycup.com
---
Re: eating memory ... // RE: Porting to OS X
On Wed, 5 Jun 2002, Alvar Freude wrote: > probably it's the same as on FreeBSD: if you use a DSO mod_perl, for each > restart (apachectl graceful or apachectl restart) it eats all the memory > your mod_perl modules use. Try to build it statically; at least on FreeBSD > it helps, and OSX is FreeBSD ... :-) > > But my newest test was with Apache 1.3.23 and mod_perl 1.26; perhaps it's > fixed in 1.27?!? dso should be fine with 1.26 or 1.27, provided you are using Perl 5.6.1 or higher. 5.005_03 still has leakage.
eating memory ... // RE: Porting to OS X
Hi, -- Michael Robinton <[EMAIL PROTECTED]> wrote: > application, which runs on an aging 486 with 64 megs in our shop and uses > about 4 megs including mod_perl enhanced apache, took 40 megs on OSX and > was very slow. This was on a G4 with 500 megs of memory. probably it's the same as on FreeBSD: if you use a DSO mod_perl, for each restart (apachectl graceful or apachectl restart) it eats all the memory your mod_perl modules use. Try to build it statically; at least on FreeBSD it helps, and OSX is FreeBSD ... :-) But my newest test was with Apache 1.3.23 and mod_perl 1.26; perhaps it's fixed in 1.27?!? But nevertheless 4 MB is very small; my frontend Apache 1.3.23 without mod_perl takes 3 MB; my frontend Apache 2.0.36 on developing system >4 MB without mod_perl ... Ciao Alvar -- // Unterschreiben! http://www.odem.org/informationsfreiheit/ // Internet am Telefon: http://www.teletrust.info/ // Das freieste Medium? http://www.odem.org/insert_coin/ // Blaster: http://www.assoziations-blaster.de/
Re: Porting to OS X
David Wheeler wrote: >On 6/4/02 10:54 AM, "Vuillemot, Ward W" <[EMAIL PROTECTED]> >claimed: > >>I think it is relatively an easy move, IMHO. Just beaware that the Mac OS >>filesystem is NOT case-sensitive. Which can cause problems with certain >>applications. . .and we hope (Apple, you listening?) that they will fix this >>gross over-sight. >> > >I don't think that Apple is likely to change this. However, you can install >OS X on a case-sensitive partition (UFS?) if you really want to. > >Regards, > >David > Yes, Apples HFS volumes is not case sensitive and you can partition a drive for UFS, but, Apple provides a case-sensitivity module for Apache. Its called "mod_hfs_apple.so" and comes with the install, you can find it with all of Apache's other modules in /usr/libexec/httpd. Whether this is good enough for case-sensitivity or not I thought it may be of help. -Justin
Re: Porting to OS X
> "David" == David Wheeler <[EMAIL PROTECTED]> writes: >> I think it is relatively an easy move, IMHO. Just beaware that the Mac OS >> filesystem is NOT case-sensitive. Which can cause problems with certain >> applications. . .and we hope (Apple, you listening?) that they will fix this >> gross over-sight. David> I don't think that Apple is likely to change this. However, you David> can install OS X on a case-sensitive partition (UFS?) if you David> really want to. My / has been UFS since day 1 of using OSX for me. I have a separate HFS+ partition for Classic Apps. The downside is that some of the files are not accessible to Classic apps, but as more and more stuff gets at least Carbonized, I'm not really that worried. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
RE: Porting to OS X
At 11:27 AM 6/4/02 -0700, Michael Robinton wrote: >I'd be very interested in how this progresses. I recently helped a >collegue to get a cgi program running under apache using standard perl on >OSX -- I found that the perl distribution that comes with OSX is the >original 5.6 rather than more up to date versions IIRC, the latest OS update upgrades perl to 5.6.1. == Drew Taylor | Freelance web development using http://www.drewtaylor.com/ | perl/mod_perl/MySQL/postgresql/DBI mailto:[EMAIL PROTECTED] | Email jobs at drewtaylor.com -- Speakeasy.net: A DSL provider with a clue. Sign up today. http://www.speakeasy.net/refer/29655 ==
RE: Porting to OS X
From: "Noam Solomon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Subject: Porting to OS X Date sent:Tue, 4 Jun 2002 13:43:11 -0400 >[ Double-click this line for list subscription options ] > >Can anyone give me a rough idea how much time it would take to move a >server serving >mod_perl websites from UNIX to OS X? It uses Apache::Session, >DBI::Mysql, >HTML::Mason, CGI, >and Apache::OpenIndex, among others, and uses both AuthHandlers and >AuthzHandlers. > >I know it's difficult to estimate without knowing how big the websites >are, what kind of >functions they call, etc., but if you could give me an idea of what kind >of problems I can >expect to encounter and how difficult they are to work around, I can give >a quote to my >client. > >Thanks, >Noam Solomon I'd be very interested in how this progresses. I recently helped a collegue to get a cgi program running under apache using standard perl on OSX -- I found that the perl distribution that comes with OSX is the original 5.6 rather than more up to date versions AND that the application, which runs on an aging 486 with 64 megs in our shop and uses about 4 megs including mod_perl enhanced apache, took 40 megs on OSX and was very slow. This was on a G4 with 500 megs of memory. Michael
Re: Porting to OS X [OT] OS X
>> I think it is relatively an easy move, IMHO. Just beaware that the >> Mac OS filesystem is NOT case-sensitive. Which can cause problems >> with certain applications. . .and we hope (Apple, you listening?) that >> they will fix this gross over-sight. I agree it's a problem, and it's caused me some heartache, but Apple, and many of my Apple zealot friends definitely consider it a feature, not a bug. Another annoying thing that may happen while migrating directory structures is: if you have two directorie with /dir_this/dir_that/[lotsof.pl] /dir_dir/dir_this/dir_the_other/[lotsmore.pl] and you're in / cp|mv dir_this dir_dir will cp|mv dir_that to /dir_dir/dir_this/dir_that BUT dir_the_other will be gone. Another "feature" Dvaid
Re: Porting to OS X
On 6/4/02 10:54 AM, "Vuillemot, Ward W" <[EMAIL PROTECTED]> claimed: > I think it is relatively an easy move, IMHO. Just beaware that the Mac OS > filesystem is NOT case-sensitive. Which can cause problems with certain > applications. . .and we hope (Apple, you listening?) that they will fix this > gross over-sight. I don't think that Apple is likely to change this. However, you can install OS X on a case-sensitive partition (UFS?) if you really want to. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
RE: Porting to OS X
This is going OT, but the case insensitivity problem is only for the Mac filesystems. I've that all you need to do is switch the filesystem to ufs (the bsd version) and the problem is solved. Of course, if you can't switch fs types I don't know of a workaround. :-) Drew At 10:54 AM 6/4/02 -0700, Vuillemot, Ward W wrote: > >I think it is relatively an easy move, IMHO. Just beaware that the Mac OS >filesystem is NOT case-sensitive. Which can cause problems with certain >applications. . .and we hope (Apple, you listening?) that they will fix >this gross over-sight. == Drew Taylor | Freelance web development using http://www.drewtaylor.com/ | perl/mod_perl/MySQL/postgresql/DBI mailto:[EMAIL PROTECTED] | Email jobs at drewtaylor.com -- Speakeasy.net: A DSL provider with a clue. Sign up today. http://www.speakeasy.net/refer/29655 ==
RE: Porting to OS X
Wheeler's site provides a lot of great information. When I get to my other computer, I can send you some other useful URLs for setting up UNIX apps on the OS X if you want. I found it took about an evening to install all the software. Another evening to get mod_perl apps up and running, but I had to install XML-related software, too. . .mysql is a snap, too. And I am NOT a sysadmin...not even close. I think it is relatively an easy move, IMHO. Just beaware that the Mac OS filesystem is NOT case-sensitive. Which can cause problems with certain applications. . .and we hope (Apple, you listening?) that they will fix this gross over-sight. Cheers, Ward -Original Message-From: Noam Solomon [mailto:[EMAIL PROTECTED]]Sent: Tuesday, June 04, 2002 10:43 AMTo: [EMAIL PROTECTED]Subject: Porting to OS X Can anyone give me a rough idea how much time it would take to move a server serving mod_perl websites from UNIX to OS X? It uses Apache::Session, DBI::Mysql, HTML::Mason, CGI, and Apache::OpenIndex, among others, and uses both AuthHandlers and AuthzHandlers. I know it's difficult to estimate without knowing how big the websites are, what kind of functions they call, etc., but if you could give me an idea of what kind of problems I can expect to encounter and how difficult they are to work around, I can give a quote to my client. Thanks, Noam Solomon
Re: Porting to OS X
On 6/4/02 10:43 AM, "Noam Solomon" <[EMAIL PROTECTED]> claimed: > Can anyone give me a rough idea how much time it would take to move a server > serving mod_perl websites > from UNIX to OS X? It uses Apache::Session, DBI::Mysql, HTML::Mason, CGI, and > Apache::OpenIndex, > among others, and uses both AuthHandlers and AuthzHandlers. It depends on how good a Sysadmin you are, but I would say a couple of days. I document how to install most of this stuff on my site: http://david.wheeler.net/osx.html I don't cover MySQL, but there's a link to an Apple article on how to install it in the section where I cover installing PostgreSQL. HTH, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Porting to OS X
Can anyone give me a rough idea how much time it would take to move a server serving mod_perl websites from UNIX to OS X? It uses Apache::Session, DBI::Mysql, HTML::Mason, CGI, and Apache::OpenIndex, among others, and uses both AuthHandlers and AuthzHandlers. I know it's difficult to estimate without knowing how big the websites are, what kind of functions they call, etc., but if you could give me an idea of what kind of problems I can expect to encounter and how difficult they are to work around, I can give a quote to my client. Thanks, Noam Solomon
Re: Porting
John Reid wrote: > > > > We have an application written in Java using MVC which we would like to > > port > > > to mySQL/Perl platform. We have used Struts,to create tags. > > > Any inputs in this regards will be appreaciated. > > > > You will probably find that Struts tags can be ported nicely to Template > > Toolkit (http://template-toolkit.org). You might even be able to write a > > converter for your JSP pages. If you're interested in getting some > > object/relational mapping features and a basic MVC structure thrown in as > > well, you can check out OpenInteract (http://openinteract.org/). > > - Perrin > > > > Or what about Apache::ASP and XML Subs? > If you do look at Apache::ASP & see that it falls short for you, please let me know what issues there are as there are likely features I can add that might make your transition a better experience. Apache::ASP is being actively developed, and a major release 2.23 will soon go to CPAN. Also note that for general questions about Apache::ASP, please send them to [EMAIL PROTECTED] or subscribe with [EMAIL PROTECTED] --Josh _ Joshua Chamas Chamas Enterprises Inc. NodeWorks Founder Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Re: Porting
Mark Maunder wrote on Mon, Sep 24 2001 (15:44:25 +0100): > Any clues as to your motivation for porting to mod_perl? I've been trying to > sell a mod_perl solution to some Java nuts for some time and any help would be > much appreciated. What really makes mod_perl better than Java? Are there any > performance benchmarks out there that anyone knows about? Scaleability? JDBC vs. > DBI? Child/Servlet memory footprint size? performance is not the crucial point here, IMHO. it's like young boys arguing about car brands, "my daddy's car is faster than your daddy's car!" it depends on the people who will write/maintain the code and their skills with the particular technology, be it mod_perl, servlets, ruby, python, whatever. basically, someone with comparable proficiency in each of the mentioned technologies will be able to produce a working solution with comparable performance. all of the above technologies have been deployed in large-scale projects, and they can be tuned, so that "performance" questions should not be emphasized more than necessary. if your data model is clean and your algorithms are smart, then the implementation language is just a question of convenience, IMHO. you should concentrate on this fact rather than bragging about "product features". > If someone says to you, why didn't you do it in Java? > What do you say? (Besides > mentioning Sun's lame license.) because i think that mod_perl gives me all the flexibility i need, and it's supported by legions of competent developers. i saw lots of companies offering "premium commercial support" for their products, but almost none of them can maintain the level of support offered by the perl community. in my opinion, there are lots of (mediocre) Java programmers out there, far more than competent mod_perl programmers. it's easier for companies to recruit Java people, and Java has better marketing, impressing suits who pay for your projects. cu, -- Toni Andjelkovic <[EMAIL PROTECTED]>
Re: Porting
> What really makes mod_perl better than Java? This is a common thread, which you should look up in the archives. It's best to avoid starting up a discussion with this vague a question, since it will lead to a flood of advocacy e-mails. > Didn't the eToys guys do some benchmarking? (Perrin?) We did. We knew we were going to use Linux, so we took the fastest Java stuff (Resin + IBM's JVM) and wrote a quick test servlet to select some stuff from Oracle and display it. When we ran the same thing under mod_perl, Perl was a little bit faster. Note that Caucho has some benchmarks they published which are not very good since they have poorly optimized Perl code (it's a Registry script, not a handler). When we saw that Perl was just as fast, we had no reason to switch from a productive platform that we all liked to one that only some of our team had skills on. - Perrin
Re: Porting
Any clues as to your motivation for porting to mod_perl? I've been trying to sell a mod_perl solution to some Java nuts for some time and any help would be much appreciated. What really makes mod_perl better than Java? Are there any performance benchmarks out there that anyone knows about? Scaleability? JDBC vs. DBI? Child/Servlet memory footprint size? If someone says to you, why didn't you do it in Java? What do you say? (Besides mentioning Sun's lame license.) Didn't the eToys guys do some benchmarking? (Perrin?) Manoj Anjaria wrote: > Hello all, > > We have an application written in Java using MVC which we would like to port > to mySQL/Perl platform. We have used Struts,to create tags. > Any inputs in this regards will be appreaciated. > > Thanks > Manoj > > _ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp -- Mark Maunder Senior Architect SwiftCamel Software http://www.swiftcamel.com mailto:[EMAIL PROTECTED]
RE: Porting
> > We have an application written in Java using MVC which we would like to > port > > to mySQL/Perl platform. We have used Struts,to create tags. > > Any inputs in this regards will be appreaciated. > > You will probably find that Struts tags can be ported nicely to Template > Toolkit (http://template-toolkit.org). You might even be able to write a > converter for your JSP pages. If you're interested in getting some > object/relational mapping features and a basic MVC structure thrown in as > well, you can check out OpenInteract (http://openinteract.org/). > - Perrin > Or what about Apache::ASP and XML Subs? John --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.281 / Virus Database: 149 - Release Date: 18/09/2001
Re: Porting
> We have an application written in Java using MVC which we would like to port > to mySQL/Perl platform. We have used Struts,to create tags. > Any inputs in this regards will be appreaciated. You will probably find that Struts tags can be ported nicely to Template Toolkit (http://template-toolkit.org). You might even be able to write a converter for your JSP pages. If you're interested in getting some object/relational mapping features and a basic MVC structure thrown in as well, you can check out OpenInteract (http://openinteract.org/). - Perrin
Porting
Hello all, We have an application written in Java using MVC which we would like to port to mySQL/Perl platform. We have used Struts,to create tags. Any inputs in this regards will be appreaciated. Thanks Manoj _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
Re: Porting CGI scripts help needed
Quoting Bryan Coon <[EMAIL PROTECTED]>: > Each cgi simply calls 'use global;' and then off we go. However, after > moving all this stuff into /perl, none of the subs in the custom .pl > files > are found, I get a complaint: > Undefined Subroutine &Apache::ROOT::compar_2ecgi::checkUser called at See http://perl.apache.org/guide/porting.html#Name_collisions_with_Modules_and The short answer is that all of your required files need to declare a package name, and then you can either use the full name to access their functions or have them export the function names. - Perrin
RE: Porting CGI scripts help needed
> Heres what I did: > I had many scripts in one dir that shared many things; subroutines, global > variables and modules. I wanted to clean things up, so I created a module > called global.pm structured like this: > The custom stuff scripts all end in 1;, and are loaded with my custom > subroutines. For example, I have one called cgi.pl, that > contains all subs > for cgi related tasks, i.e. checkUser(), which verifies a users cookie. > > Each cgi simply calls 'use global;' and then off we go. However, after > moving all this stuff into /perl, none of the subs in the custom .pl files > are found, I get a complaint: > Undefined Subroutine &Apache::ROOT::compar_2ecgi::checkUser > called at . > > compare.cgi calls 'use global;' and then 'checkUser()'. global.pm isn't exporting the symbol names it's defining. if you were to refer to global::checkUser() in one of your scripts, and it worked, then mebbe an EXPORT() list for global.pm is in order so that the function names get defined in the package (Apache::ROOT::compar_2ecgi, made up by apache on the spot) that is accessing them. HTH! L8r, Rob
RE: Porting CGI scripts help needed
You might try adding "use lib '/path/to/global.pm';" to you startup.pl. (Without the "s of course) Good luck. --Joe Breeden -- Sent from my Outlook 2000 Wired Deskheld (www.microsoft.com) > -Original Message- > From: Bryan Coon [mailto:[EMAIL PROTECTED]] > Sent: Thursday, July 26, 2001 6:01 PM > To: '[EMAIL PROTECTED]' > Subject: Porting CGI scripts help needed > > > Hi, > > I have (happily) compiled and configured Apache with > mod_perl, mod_ssl, > mod_php and DSO. Whee! > > Now I am working on porting my scripts over... > > I have always used strict and perl -w, so for the most part, > I think I can > just pop my cgis in the /perl directory as Ive defined it in > httpd.conf. > > However, I had to implement some trickery for my scripts a > while ago via > require/use and am having problems getting my scripts to work. > > Heres what I did: > I had many scripts in one dir that shared many things; > subroutines, global > variables and modules. I wanted to clean things up, so I > created a module > called global.pm structured like this: > --- > use strict; > > ## Local parameters > our $cgibin = "http://path/cgi-bin";; > our $htmldir = "/apache/htdocs" > our $a = "/some/path"; > our $b = "/some/other/path"; > > ## Common modules > use CGI qw(:standard); > use DBI; > use Data::Table; > > ## Custom stuff > require "/path/to/custom/script1.pl"; > require "/path/to/custom/script2.pl"; > 1; > --- > > The custom stuff scripts all end in 1;, and are loaded with my custom > subroutines. For example, I have one called cgi.pl, that > contains all subs > for cgi related tasks, i.e. checkUser(), which verifies a > users cookie. > > Each cgi simply calls 'use global;' and then off we go. > However, after > moving all this stuff into /perl, none of the subs in the > custom .pl files > are found, I get a complaint: > Undefined Subroutine &Apache::ROOT::compar_2ecgi::checkUser > called at . > > compare.cgi calls 'use global;' and then 'checkUser()'. > > What am I doing wrong with this? Any ideas? > > Thanks! > Bryan >
Porting CGI scripts help needed
Hi, I have (happily) compiled and configured Apache with mod_perl, mod_ssl, mod_php and DSO. Whee! Now I am working on porting my scripts over... I have always used strict and perl -w, so for the most part, I think I can just pop my cgis in the /perl directory as Ive defined it in httpd.conf. However, I had to implement some trickery for my scripts a while ago via require/use and am having problems getting my scripts to work. Heres what I did: I had many scripts in one dir that shared many things; subroutines, global variables and modules. I wanted to clean things up, so I created a module called global.pm structured like this: --- use strict; ## Local parameters our $cgibin = "http://path/cgi-bin";; our $htmldir = "/apache/htdocs" our $a = "/some/path"; our $b = "/some/other/path"; ## Common modules use CGI qw(:standard); use DBI; use Data::Table; ## Custom stuff require "/path/to/custom/script1.pl"; require "/path/to/custom/script2.pl"; 1; --- The custom stuff scripts all end in 1;, and are loaded with my custom subroutines. For example, I have one called cgi.pl, that contains all subs for cgi related tasks, i.e. checkUser(), which verifies a users cookie. Each cgi simply calls 'use global;' and then off we go. However, after moving all this stuff into /perl, none of the subs in the custom .pl files are found, I get a complaint: Undefined Subroutine &Apache::ROOT::compar_2ecgi::checkUser called at . compare.cgi calls 'use global;' and then 'checkUser()'. What am I doing wrong with this? Any ideas? Thanks! Bryan
Re: porting mod_perl content handler to CGI
On Fri, Nov 17, 2000 at 11:53:05AM -0800, Bill Moseley wrote: > > Now, I'd like to use a few of my modules under CGI -- for an administration > part of the application that's bigger and not used enough to use up space > in the mod_perl server. But it would be nice to have a common code base. One possibility is to require My::Memory::Hog ; once you know it needs to be used, then to suicide your process when done with the request. That's not always a good idea, if your childinit takes a long time, for instance, but it may simplify your life to not have to worry about the two different environments. > Before I spend much time, has this already been done? I do exactly this for a largish chunk of code, I have a Safari::Request object that I fill in from a comand-line or CGI script. You might also look at Apache::FakeRequest. I can send you mine (I posted it to this list or another list recently). There is definitely a recurring interest in runnng mod_perl scripts from command line and via CGI. That's not feasible for all scripts, but for the more "plain vanilla" ones, it should be. - Barrie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: porting mod_perl content handler to CGI
Bill Moseley wrote: > > Howdy, > > I have an application that's pure mod_perl -- its modules use the request > object to do a few bits of work like reading parameters, query string, > specialized logging, dealing with NOT_MODIFIED, and so on. Normal stuff > provided by the methods of Apache, Apache::Util, Apache::URI and > Apache::Connection. > > Now, I'd like to use a few of my modules under CGI -- for an administration > part of the application that's bigger and not used enough to use up space > in the mod_perl server. But it would be nice to have a common code base. > I have the stub of one I developed for Apache::ASP called Apache::ASP::CGI. I got it to the point that I could run ASP scripts from the command line, but not much farther. I was able to get scripts to run under CGI, but as I recall, I never implemented POST reading very well. If you would like to roll this into a CGI::Apache or Apache::CGI, that would be great. You can find this package in the body of the ASP.pm module. --Joshua - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
porting mod_perl content handler to CGI
Howdy,
I have an application that's pure mod_perl -- its modules use the request
object to do a few bits of work like reading parameters, query string,
specialized logging, dealing with NOT_MODIFIED, and so on. Normal stuff
provided by the methods of Apache, Apache::Util, Apache::URI and
Apache::Connection.
Now, I'd like to use a few of my modules under CGI -- for an administration
part of the application that's bigger and not used enough to use up space
in the mod_perl server. But it would be nice to have a common code base.
So, I'm writing a replacement module of those classes and supporting just
the few methods I need. I'm using CGI.pm, URI, HTTP::Date and so on to
handle those few mod_perl methods I'm using in my modules.
For example, I have a function that does specialized logging that I want to
use both under mod_perl and CGI. So, this would work under CGI
my $r = Apache->request;
my $remote = $r->connection->remote_ip;
where in the replacement package Apache::Connection:
sub remote_ip { $ENV{REMOTE_ADDR} }
Before I spend much time, has this already been done?
Might be kind of cool if one could get new CGI programmers to write all
their CGI applications like mod_perl handlers -- could run as CGI on other
servers, but when they want speed they are ready to use mod_perl.
Anyway, does a mod_perl emulator for CGI exist?
Bill Moseley
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] javascript to perlscript porting tool
Joel Reed wrote: > > I've posted a simple program that may help you if you're > trying to port windoze javascript-based ASP pages to > Apache::ASP. you can find it here... > > http://ruby.ddiworld.com/jreed/web/software/asp2pl.html > I would like to write runtime interpreters for JScript & VBScript -> PerlScript one day. Would you mind if I pulled some of your logic from your work with the necessary kudos? -- Joshua _ Joshua Chamas Chamas Enterprises Inc. NodeWorks >> free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
[OT] javascript to perlscript porting tool
I've posted a simple program that may help you if you're trying to port windoze javascript-based ASP pages to Apache::ASP. you can find it here... http://ruby.ddiworld.com/jreed/web/software/asp2pl.html jr -- Joel W. Reed http://ruby.ddiworld.com/jreed -Did You Know? (DYK?): A group of storks is called a mustering.-
RE: porting DBI to Apache::DBI
Apache::DBI is completely transparent if you get DBI right in the first
place (for better or worse ;) - no need to 'use vars' or anything.
just put
PerlModule Apache::DBI in httpd.conf or
use Apache::DBI in startup.pl
and make sure it occurs before you load DBI (via PerlModule or use)
see
http://perl.apache.org/guide/databases.html#Apache_DBI_Initiate_a_persist
and the man pages for more :)
--Geoff
> -Original Message-
> From: James G Smith [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 29, 2000 1:56 PM
> To: James Array
> Cc: [EMAIL PROTECTED]
> Subject: Re: porting DBI to Apache::DBI
>
>
> "James Array" <[EMAIL PROTECTED]> wrote:
> >Haloo
> >
> > I'm confusing of how to port DBI CGI to
> Apache::DBI mod_perl with
> >Apache::Registry
> >for the most efficient:
> >
> >if my normal DBI CGI is:
> >
> >use strict;
> >use DBI;
> >
> >my $dbh=DBI->connect("database","login","password","mysql");
> >..
> >$dbh->disconnect;
> >
> >=
> >
> >when port to Apache::DBI should I modify it as
> >1:
> >
> >use strict;
> >use DBI;
> >use vars qw($dbh);
> >
> >$dbh=DBI->connect("database","login","password","mysql");
> >
> >$dbh->disconnect;
> >
>
> This would be a good try. If Apache::DBI is loaded first, it
> will cache
> connections and create a new one only if there isn't an
> existing connection
> for the particular combination of connection arguments. More
> details should
> available in the Apache::DBI perldoc.
>
> You definitely want to go with a `use vars' for $dbh if it
> can't be localized
> to a subroutine. But then, I haven't done Apache::Registry
> scripts for so
> long, I can't remember for sure (most of my code now is
> modules). You might
> want to check out the mod_perl Guide on that one.
> --
> James Smith <[EMAIL PROTECTED]>, 979-862-3725
> Texas A&M CIS Operating Systems Group, Unix
>
>
Re: porting DBI to Apache::DBI
"James Array" <[EMAIL PROTECTED]> wrote:
>Haloo
>
> I'm confusing of how to port DBI CGI to Apache::DBI mod_perl with
>Apache::Registry
>for the most efficient:
>
>if my normal DBI CGI is:
>
>use strict;
>use DBI;
>
>my $dbh=DBI->connect("database","login","password","mysql");
>..
>$dbh->disconnect;
>
>=
>
>when port to Apache::DBI should I modify it as
>1:
>
>use strict;
>use DBI;
>use vars qw($dbh);
>
>$dbh=DBI->connect("database","login","password","mysql");
>
>$dbh->disconnect;
>
This would be a good try. If Apache::DBI is loaded first, it will cache
connections and create a new one only if there isn't an existing connection
for the particular combination of connection arguments. More details should
available in the Apache::DBI perldoc.
You definitely want to go with a `use vars' for $dbh if it can't be localized
to a subroutine. But then, I haven't done Apache::Registry scripts for so
long, I can't remember for sure (most of my code now is modules). You might
want to check out the mod_perl Guide on that one.
--
James Smith <[EMAIL PROTECTED]>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix
porting DBI to Apache::DBI
Haloo
I'm confusing of how to port DBI CGI to Apache::DBI mod_perl with
Apache::Registry
for the most efficient:
if my normal DBI CGI is:
use strict;
use DBI;
my $dbh=DBI->connect("database","login","password","mysql");
..
$dbh->disconnect;
=
when port to Apache::DBI should I modify it as
1:
use strict;
use DBI;
use vars qw($dbh);
$dbh=DBI->connect("database","login","password","mysql");
$dbh->disconnect;
===
or
2:
use strict;
use DBI;
use vars qw($dbh);
$dbh ||=DBI->connect("database","login","password","mysql");
.
$dbh->disconnect;
or
3:
need not to change any thing?
__
Get Your Private, Free Email at http://www.hotmail.com
Re: Porting to Apache::Registry
> At 08:54 AM 10/20/99 +0200, Stas Bekman wrote: > >> Besides all the information at perl.apache.org, can you recommend any good > >> resources (book, web pages) that stand out in your memory as being very > >> helpful when you were starting out? > > > >I'm not sure why have you discarded the docs at perl.apache.org so fast, > >did you read them at all? Did you take a look at the guide? > >perl.apache.org/guide > > I said "besides", not that I discarded the docs you mention. 99% of the info you can find about mod_perl located at perl.apache.org, there are a few articles written here and there, but if you don't find the info *about modperl* at modperl site, I'm not sure you will find it elsewhere... See below for the info about the book... > I did read the Guide. It's helpful and a wonderful bit of work. But I > still have questions and I haven't been at this long enough to grok it all > in. For example, you say: > > "Perl's exit() built-in function cannot be used in mod_perl scripts." > > I started to edit my scripts per the examples in the Guide, but then > decided to try it first, and, it turns out, exit() works without explicitly > overriding in my script. Reading perldoc Apache::Registry again, I see > that exit is overridden automatically. I beg your pardon, did you read the whole section or only the first sentence? I'm not hiding it, in third para of: http://perl.apache.org/guide/porting.html#Using_exit_ clearly written the following: Note that if you run the script under Apache::Registry, The Apache function exit() overrides the Perl core built-in function. While you see the exit() listed in @EXPORT_OK of Apache package, Apache::Registry makes something you don't see and imports this function for you. This means that if your script is running under Apache::Registry handler (Apache::PerlRun as well), you don't have to worry about exit(). > Confusing to a newcomer, no? If you read the whole thing, definitely not confusing. Sorry if I sound harsh, But it's a known excuse some folks use to get a free ride: "I read the docs, and didn't find the answer. Can you please tell me...". Again, I'm not trying to offend you, Bill. Just a request to truly RTFM before asking questions. I think it's pretty fair to the folks who spend their time to answer questions. > My CGI scripts were, in a BEGIN block, opening STDERR to a file (and using > that file as a lock file). But now I see that STDERR is reset next time my > script is called. Where can I read about that and other similar behavior > that I should be aware of? In the wonderful book Doug and Lincoln wrote, see www.modperl.com STDERR is being tied by apache to error_log file. I'll add this note to the guide. BEGIN blocks are being run only once per process life: http://perl.apache.org/guide/porting.html#BEGIN_blocks > How do I find out why die() is causing a diagnostics message being sent to > the client? I'm not using Carp or any __WARN__ or __DIE__ handlers in my > script or in the startup.pl file. I beleive, it's because of your previous statement -- you break the tied STDERR and all the output goes to STDOUT. Don't mungle with STDERR unless you know what are you doing. Though it can be because of another reason... Hope this helps... ___ Stas Bekman mailto:[EMAIL PROTECTED]www.singlesheaven.com/stas Perl,CGI,Apache,Linux,Web,Java,PC at www.singlesheaven.com/stas/TULARC www.apache.org & www.perl.com == www.modperl.com || perl.apache.org single o-> + single o-+ = singlesheavenhttp://www.singlesheaven.com
Re: Porting to Apache::Registry
At 08:54 AM 10/20/99 +0200, Stas Bekman wrote: >> Besides all the information at perl.apache.org, can you recommend any good >> resources (book, web pages) that stand out in your memory as being very >> helpful when you were starting out? > >I'm not sure why have you discarded the docs at perl.apache.org so fast, >did you read them at all? Did you take a look at the guide? >perl.apache.org/guide I said "besides", not that I discarded the docs you mention. I did read the Guide. It's helpful and a wonderful bit of work. But I still have questions and I haven't been at this long enough to grok it all in. For example, you say: "Perl's exit() built-in function cannot be used in mod_perl scripts." I started to edit my scripts per the examples in the Guide, but then decided to try it first, and, it turns out, exit() works without explicitly overriding in my script. Reading perldoc Apache::Registry again, I see that exit is overridden automatically. Confusing to a newcomer, no? My CGI scripts were, in a BEGIN block, opening STDERR to a file (and using that file as a lock file). But now I see that STDERR is reset next time my script is called. Where can I read about that and other similar behavior that I should be aware of? How do I find out why die() is causing a diagnostics message being sent to the client? I'm not using Carp or any __WARN__ or __DIE__ handlers in my script or in the startup.pl file. Bill Moseley mailto:[EMAIL PROTECTED]
Re: Porting to Apache::Registry
> I'm just starting in on porting some scripts over to either > Apache::Registry or Apache::PerlRun, and trying to absorb as much as I can. > It's seems a bit overwhelming at first. > > My scripts are reasonably clean, running under -w and use strict, yet I'm > sure I have lots of porting issues to deal with. I understand that it's > hard to answer without knowing details about my setup, but in general are > the speed gains with Apahce::Registry over Apache::PerlRun worth the extra > porting work? > > Besides all the information at perl.apache.org, can you recommend any good > resources (book, web pages) that stand out in your memory as being very > helpful when you were starting out? I'm not sure why have you discarded the docs at perl.apache.org so fast, did you read them at all? Did you take a look at the guide? perl.apache.org/guide > I have a bunch of questions, of course, such as: Under Apache::Registry do > I have to be aware of other Apache::Registry scripts that may be running > under the same server process as my program? For example, I often open > STDERR to a log file in my CGI scripts. Will all scripts running on that > process then write to my log file? > > And I often have a public CGI script, and an 'Admin' script where the > public script opens a log file (using STDERR) with a share lock, but the > 'Admin' script opens with an exclusive lock on the same file when updating > config files. It would seem to make sense to not have to open and close > the log file for each execution, but rather leave the file open and just > grab and release the lock during execution.But I'm really unclear how > to set this up under Apache::Registry and if there are race conditions to > worry about. > > Anyway, I'm really seeking pointers on good references for just starting > out that will help me answer these type of questions and keep me quite for > a while. > > Thanks very much, > > Bill Moseley > mailto:[EMAIL PROTECTED] > ___ Stas Bekman mailto:[EMAIL PROTECTED]www.singlesheaven.com/stas Perl,CGI,Apache,Linux,Web,Java,PC at www.singlesheaven.com/stas/TULARC www.apache.org & www.perl.com == www.modperl.com || perl.apache.org single o-> + single o-+ = singlesheavenhttp://www.singlesheaven.com
Porting to Apache::Registry
I'm just starting in on porting some scripts over to either Apache::Registry or Apache::PerlRun, and trying to absorb as much as I can. It's seems a bit overwhelming at first. My scripts are reasonably clean, running under -w and use strict, yet I'm sure I have lots of porting issues to deal with. I understand that it's hard to answer without knowing details about my setup, but in general are the speed gains with Apahce::Registry over Apache::PerlRun worth the extra porting work? Besides all the information at perl.apache.org, can you recommend any good resources (book, web pages) that stand out in your memory as being very helpful when you were starting out? I have a bunch of questions, of course, such as: Under Apache::Registry do I have to be aware of other Apache::Registry scripts that may be running under the same server process as my program? For example, I often open STDERR to a log file in my CGI scripts. Will all scripts running on that process then write to my log file? And I often have a public CGI script, and an 'Admin' script where the public script opens a log file (using STDERR) with a share lock, but the 'Admin' script opens with an exclusive lock on the same file when updating config files. It would seem to make sense to not have to open and close the log file for each execution, but rather leave the file open and just grab and release the lock during execution.But I'm really unclear how to set this up under Apache::Registry and if there are race conditions to worry about. Anyway, I'm really seeking pointers on good references for just starting out that will help me answer these type of questions and keep me quite for a while. Thanks very much, Bill Moseley mailto:[EMAIL PROTECTED]
