Re: Apache DSO/mod_perl installation problem
Hi there, On Sat, 16 Sep 2000, German Todorov wrote: I have apache 1.3.12 compiled as DSO and Perl 5.6.0 on SunOS 5.7, and I tried to install mod_perl 1.2.4 as DSO This is almost a FAQ now, search the List archive for the last couple of weeks. 73, Ged.
Re: Question
On Tue, Sep 12, 2000 at 04:34:28PM +0100, David Hodgkinson wrote: "Eric Cholet" [EMAIL PROTECTED] writes: well then we're a long shot away, and so are many French natives :) Nah, we won't be that demanding, lest we scare him away from the, erm, "most beautiful city in the world". What? Bath? Dave // Found communication in Paris much improved with a thick, \\ Inspector Clouseau accent...izzat yeur Minkey? Inspector Clouseau ? what's that ? Another french hero that tv-producer is hidding from us, here, in France ?
Re: Does the AxKit-devel mailing list have an archive?
Matt Sergeant wrote:
# my @vary = $r-header_out('Vary') if $r-header_out('Vary');
# push @vary, "Accept-Encoding", "User-Agent";
I think its a mod_perl bug. There's nothing leaky in the perl here.
Isn't it the same as
http://www.perl.com/pub/2000/05/p5pdigest/THISWEEK-2521.html#my_x_if_0;_Trick
Re: usemymalloc mod_perl
On Sun, 17 Sep 2000, Dave Rolsky wrote: On Sat, 16 Sep 2000, Ian Kallen wrote: So, my question for this group: why would I want usemymalloc=y on Solaris 2.6? Besides having to rebuild a somewhat complex mod_perl compile, I'm not looking forward to rebuilding all libraries with XS code so any insight as to the ins and outs of compiling w/ and w/o usemymalloc would be much appreciated! From the guide: It seems that Linux still defaults to system malloc so you might want to configure Perl with -Dusemymalloc. Perl's malloc is not much of a win under linux, but makes a huge difference under Solaris I don't know who established this though. Ask Stas ;) According to CHANGES: 04.09.2000 ver 1.22 * performance: new: "-Dusemymalloc Perl Build Option" (Doug, Jeffrey W. Baker) Ask Doug :) Ask Jeffrey W. Baker :) Ask Ask? :) _ 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://jazzvalley.com http://singlesheaven.com http://perlmonth.com perl.org apache.org
Re: Does the AxKit-devel mailing list have an archive?
On Sun, 17 Sep 2000, Alexander Farber (EED) wrote:
Matt Sergeant wrote:
# my @vary = $r-header_out('Vary') if $r-header_out('Vary');
# push @vary, "Accept-Encoding", "User-Agent";
I think its a mod_perl bug. There's nothing leaky in the perl here.
Isn't it the same as
http://www.perl.com/pub/2000/05/p5pdigest/THISWEEK-2521.html#my_x_if_0;_Trick
Nice catch!
Yes it is the same. Thats good news for Doug :-)
This probably needs fixing in Apache::GzipChain too then, as the code was
directly cut and paste from there.
--
Matt/
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
Clean way of transfering Objects between childinit and request handlers ?
Dear All I want to create an Object in a ChildInit handler and then pass it to request handlers. Its a DB Object / module and it does some initialiastion, it prepares a few statment handles and then stores them in an array for later execution. One solution is to create a the object in a child init handler and to store it in a package global - and then to use a type glob to referance it from other handlers by using that package global (detailed below). However this appears as a bit of a kludge and does not have any repect for encapsulation ;-). I feel there must be a cleaner way of doing this ? A read of the guide etc ... has not given me any clues. Any ideas appreciated. Greg Cope ### type glob example (off the top of my head - could be wrong) package child_init; use vars qw($foo); $foo = My::db_handler-new(); ### package request_handler; *db = \$child_init::foo; $db-foo();
Re: Clean way of transfering Objects between childinit and request handlers ?
* Greg Cope ([EMAIL PROTECTED]) [000917 14:31]: Dear All I want to create an Object in a ChildInit handler and then pass it to request handlers. Its a DB Object / module and it does some initialiastion, it prepares a few statment handles and then stores them in an array for later execution. One solution is to create a the object in a child init handler and to store it in a package global - and then to use a type glob to referance it from other handlers by using that package global (detailed below). However this appears as a bit of a kludge and does not have any repect for encapsulation ;-). I feel there must be a cleaner way of doing this ? A read of the guide etc ... has not given me any clues. Any ideas appreciated. Greg Cope Hi Greg, Check out Class::Singleton for this purpose. Works great for me. Basically, the first time you create the object, do: my $obj = $object_class-instance( ... ); Every successive time you want the object, just call: my $obj = $object_class-instance; And you'll get the same object back. Initialization stuff (such as database connects, whatever) is put in the _new_instance() method, which is called when the object is created but not when the object is returned. The object is stored in the class itself, and Class::Singleton is actually a really simple module (probably a 10-to-1 ratio of documentation-to-code), but it's nice to have a consistent, standard way of doing things. Chris -- Chris Winters Senior Internet Developerintes.net [EMAIL PROTECTED] http://www.intes.net/ Integrated hardware/software solutions to make the Internet work for you.
Re: Clean way of transfering Objects between childinit and requesthandlers ?
On Sun, 17 Sep 2000, Chris Winters wrote: Hi Greg, Check out Class::Singleton for this purpose. Works great for me. Basically, the first time you create the object, do: my $obj = $object_class-instance( ... ); Every successive time you want the object, just call: my $obj = $object_class-instance; And you'll get the same object back. Initialization stuff (such as database connects, whatever) is put in the _new_instance() method, which is called when the object is created but not when the object is returned. The object is stored in the class itself, and Class::Singleton is actually a really simple module (probably a 10-to-1 ratio of documentation-to-code), but it's nice to have a consistent, standard way of doing things. One thing C::Singleton misses is a clear_instance method though, which is pretty much necessary for mod_perl work (I'm surprised Andy hasn't fixed this, since he does a lot of mod_perl stuff)... However copying the code is pretty trivial and adding that method is about another 3 lines. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Re: I'm missing something in Apache::Cookie (fwd)
"Thomas S. Brettin" [EMAIL PROTECTED] writes:
from the looks of the code you guys posted, I would guess that
Cookie-fetch returns a hash reference, not a hash. Could this be the
problem?
It can return either a hash or a hash reference, depending on whether or not
you wantarray. The problem many people encounter is that the values in the
returned hash(ref) are Apache::Cookie OBJECTS, not simply value of the
cookie. There's more to a cookie than just it's value.
I think it goes something like this.
%cookies = Apache::Cookie-fetch;
print ref \%cookies; # prints HASH ??
print ref $cookies{'SESSION'}; # prints Apache::Cookie ??
print $cookies{'SESSION'}-value; # prints the value of SESSION cookie
RTFM to be sure, or run it and see what you get!
--
Joe Schaefer
[EMAIL PROTECTED]
SunStar Systems, Inc.
ANNOUNCEMENT: NEW VERSION: HTML::Template 2.0
ANNOUNCEMENT: NEW VERSION: HTML::Template 2.0 HTML::Template - a Perl module to use HTML Templates CHANGES 2.0 - New Feature: new 'search_path_on_include' option (Jody Biggs) - New Feature: much requested variable __ODD__ added to set of loop_context_vars. - New Feature: new 'no_includes' option (Scott Guelich) - Doc Addition: Added link to Japanese translation (Kawai Takanori) - Bug Fix: loop_context_vars broken again (T.J. Mather, Martin Schroth and Dave Wolfe) - Bug Fix: vanguard_compatibility_mode was broken on first line of included files. (uchum) DESCRIPTION This module attempts make using HTML templates simple and natural. It extends standard HTML with a few new HTML-esque tags - TMPL_VAR, TMPL_LOOP, TMPL_INCLUDE, TMPL_IF, TMPL_UNLESS and TMPL_ELSE. The file written with HTML and these new tags is called a template. It is usually saved separate from your script - possibly even created by someone else! Using this module you fill in the values for the variables, loops and branches declared in the template. This allows you to seperate design - the HTML - from the data, which you generate in the Perl script. A Japanese translation of the documentation is available at: http://member.nifty.ne.jp/hippo2000/perltips/html/template.htm This module is licenced under the GPL. See the LICENCE section of the README. AVAILABILITY This module is available on SourceForge. Download it at: http://download.sourceforge.net/HTML-Template/HTML-Template-2.0.tar.gz The module is also available on CPAN. You can get it using CPAN.pm or go to: http://www.cpan.org/authors/id/S/SA/SAMTREGAR/ MOTIVATION It is true that there are a number of packages out there to do HTML templates. On the one hand you have things like HTML::Embperl which allows you to freely mix Perl with HTML. On the other hand lie home-grown variable substitution solutions. Hopefully the module can find a place between the two. One advantage of this module over a full HTML::Embperl-esque solution is that it enforces an important divide - design and programming. By limiting the programmer to just using simple variables and loops in the HTML, the template remains accessible to designers and other non-perl people. The use of HTML-esque syntax goes further to make the format understandable to others. In the future this similarity could be used to extend existing HTML editors/analyzers to support this syntax. An advantage of this module over home-grown tag-replacement schemes is the support for loops. In my work I am often called on to produce tables of data in html. Producing them using simplistic HTML templates results in CGIs containing lots of HTML since the HTML itself could not represent loops. The introduction of loop statements in the HTML simplifies this situation considerably. The designer can layout a single row and the programmer can fill it in as many times as necessary - all they must agree on is the parameter names. For all that, I think the best thing about this module is that it does just one thing and it does it quickly and carefully. It doesn't try to replace Perl and HTML, it just augments them to interact a little better. And it's pretty fast. DOCUMENTATION The documentation is in Template.pm in the form of POD format perldocs. Even the above text might be out of date, so be sure to check the perldocs for the straight truth. CONTACT INFO This module was written by Sam Tregar ([EMAIL PROTECTED]) for Vanguard Media (http://www.vm.com). You can join the HTML::Template mailing-list by sending a blank message to [EMAIL PROTECTED]
Re: mod_perl guide corrections
[EMAIL PROTECTED] writes: What if you wanted the functionality of the fase handlers before and after the loading of the file.. Could this also be accomplished by proper use of configuration statements in http.conf? Right now I do not think so, so getting the child tied up for the time of the upload I take for granted. I'm not quite sure what your driving at. Let me see if I can describe how things work now, and what I'm trying to accomplish with the patch. Setup: A = mod_proxy enabled front-end server; keepalives enabled delivers static content (images, stylesheets, etc) proxies dynamic content B = mod_perl server; responsible for dynamic content; keepalives disabled Z = browser Event: 1) Z requests a dynamic page from A. Z -GET 1.1- A -PROXY- B -PROXY- A -CLOSE- Z The current mod_proxy CLOSES the connection from A to Z, even if Z requests keepalives, and A implements them. This is bad since subsequent requests for static content (images/stylesheets,etc.) will require a new connection. The patch should prevent mod_proxy from forcibly closing the A-Z connection. 2) Z posts form data that will ultimately be handled by B. Z -POST- A -PROXY- B Currently, mod_proxy opens the connection to B as soon as it determines B is the ultimate destination. As the POST data is read from Z to A, it is passed along directly to B. This will tie up both A and B if the A-Z connection is slow and/or the post data is huge. The patch makes mod_proxy buffer the post data in a temp file by setting the (new) ProxyPostMax directive to a positive number. If the Content-Length header supplied by Z is greater than this number, mod_proxy rejects the post request. Once the post data has been uploaded from Z-A, the patched mod_proxy opens the connection to B and delivers the POST data directly from the temp file. That's what I'm trying to accomplish with the mod_proxy patch. I've done only minimal testing on http requests; https is NOT implemented at all. I'd need something like this implemented, since I use mod_perl for authenticating "POSTers". In my case the POST data must be processed by the mod_perl server. Any help/suggestions are welcome and appreciated! -- Joe Schaefer [EMAIL PROTECTED] SunStar Systems, Inc.
