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 + CPA
: ) 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
> 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 hav
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
Any theories?
Matt.
-Original Message-
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
&
> > * 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 settin
> 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 give
> 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 Tatsuhi
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 h
> 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
> >* 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 probl
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 scr
> >* 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
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 f
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 modul
> 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?
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
