On Tue 12-Feb-2002 at 04:02:47PM -0500, Perrin Harkins wrote:
A list of things I've noticed:
* If you have two *different* modules which have the same name, then
either one, or the other is loaded in memory, never both. This is
dead annoying. I think Perl standard modules + CPAN modules
The thing is I am getting some weird behaviour where one application seems
to be getting code from the other. In theory this isn't possible with the
separated namespaces. I suspect my UNIERVSAL use is the problem. Can anyone
verify this? Is it a known problem? Is there any way around it?
To
Jean-Michel Hiver wrote:
[snip]
A list of things I've noticed:
* If you have two *different* modules which have the same name, then
either one, or the other is loaded in memory, never both. This is
dead annoying. I think Perl standard modules + CPAN modules should be
shared, other modules
On Tue, 12 Feb 2002 14:15:37 +1100
Morton-Allen, Matthew [EMAIL PROTECTED] wrote:
However both applications make use of the UNIERVSAL package to create
universally accessible methods (to return the current database handle for
example) within the application.
You don't need UNIVERSAL for the
* If you have two *different* modules which have the same name, then
either one, or the other is loaded in memory, never both. This is
dead annoying. I think Perl standard modules + CPAN modules should be
shared, other modules which are specific to a given script should not.
And who's to
Jean-Michel Hiver wrote:
* If you have two *different* modules which have the same name, then
either one, or the other is loaded in memory, never both. This is
dead annoying. I think Perl standard modules + CPAN modules should be
shared, other modules which are specific to a given script should
* Despite numerous heroic efforts, HTTP HEAD requests are still screwed!
Apache::Registry serves HEAD + Body, and Geoffrey's Apache::HEADRegistry
doesn't work with redirects and 404's (I get like two headers and 3
bodies for 404's. Now that's verbose :-))
No real mod_perl problem on that
I think the problem here is that mod_perl sets the assbackward flag
when setting headers via send_cgi_header() (which CGI.pm does).
Is this only an issue when using CGI.pm or PerlSendHeader then? I seem to
recall having no trouble doing this from a normal handler.
- Perrin
Perrin Harkins wrote:
I think the problem here is that mod_perl sets the assbackward flag
when setting headers via send_cgi_header() (which CGI.pm does).
Is this only an issue when using CGI.pm or PerlSendHeader then? I seem to
recall having no trouble doing this from a normal handler.
However both applications make use of the UNIERVSAL package to create
universally accessible methods (to return the current database handle for
example) within the application.
Better to put those into a package of your own and call them with
fully-qualified names, or import them as Tatsuhiko
A list of things I've noticed:
* If you have two *different* modules which have the same name, then
either one, or the other is loaded in memory, never both. This is
dead annoying. I think Perl standard modules + CPAN modules should be
shared, other modules which are specific to a given
* Global variables should be reinitialized on each request. Or at least
if we want them to be persistent we do not want them to be shared with
different scripts on different virtual hosts!
Try looking into the way mod_perl hooks into the apache configuration. This
may work for setting
-
From: Perrin Harkins [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, 13 February 2002 7:45 AM
To: Morton-Allen, Matthew; [EMAIL PROTECTED]
Subject: Re: mod_perl + UNIVERSAL
However both applications make use of the UNIERVSAL package to create
universally accessible methods (to return the current
Hi all,
On Tue, 12 Feb 2002, Stathy G. Touloumis wrote:
There really is no reason to cleanup the globals since they are still
referenced and in memory. Perhaps you can consider an interface around your
code which can handle the cleanup and such of any variables.
You could also set a
If the UNIVERSAL namespace is shared I
would have thought one or the other (the last one?) would get the
print_error sub and the other loses out but at some point they seem to
coexist just fine. Whilst at some other point they as expected and one
gets
the others. Any theories?
You have a
: ) As with any application that depends on the requirements.
There really is no reason to cleanup the globals since they are still
referenced and in memory. Perhaps you can consider an
interface around your
code which can handle the cleanup and such of any variables.
You could
Hi All,
I have two mod_perl applications that run under different virtual servers on
the same machine. I have named the modules within a directory for each so
that they do not clash (e.g. application::master etc).
However both applications make use of the UNIERVSAL package to create
universally
17 matches
Mail list logo
