refactoring client"s decision

I've taken over some code for a client. They've built a framework that
used to run under mod_perl and changed it later, because of problems
they had - what problems remains unknown - to cgi. Ofcourse I'm curious
why they changed it. Here's my view: they create a parent App::Handler
and in every virtual host they create a Site::Handler which has
App::Handler as base. My first guess is that under mod_perl you don't
know which Site::Handler will be called. Ofcourse, at first, the handler
you're actually pointing to will be called, but if you change the
request to another virtualhost, the wrong handler will be called.

This would explain why it's running perfectly under cgi, because in
every script call the correct lib path is defined.

So, my first question is: am I right?
Secondly, what if we're running the cgi under speedycgi?

Thx,
Marc

Re: refactoring client"s decision

Marc Lambrichs wrote:

> So, my first question is: am I right?

Yes. And it's not a mod_perl thing, it's a Perl thing. You can't have multiple
modules with the same name. Now people try this more under mod_perl because they
think different requests behave differently, but that's not the case. Each
request will hit the same long-running Perl interpreter.

> Secondly, what if we're running the cgi under speedycgi?

I don't know. I haven't used speedycgi. FastCGI seems to be what most people
prefer these days, but I don't know about it's problems either.

Typically how people solve this under mod_perl is to give each client it's own
namespace. So you'll have Client1::App::Handler, Client1::Site::Handler,
Client2::App::Handler, Client2::Site::Handler, etc. Another alternative is to
run a separate mod_perl backend apache for each client and just have the front
end proxy redirect to the right one based on the virtual host. Depending on how
many clients you have though, that could get a little wasteful.

--
Michael Peters
Plus Three, LP

Re: refactoring client"s decision

On Sun, May 11, 2008 at 2:52 AM, Marc Lambrichs
wrote:
> Secondly, what if we're running the cgi under speedycgi?

You can do this with FastCGI if you run a different FastCGI backend
for every virtualhost. The same thing would work with mod_perl if you
run a different mod_perl-enabled backend apache for each virtualhost
and proxy to them from the frontend apache.

- Perrin

Re: refactoring client"s decision

Creating packages with the same name for multiple sites is generally a
recipe for confusion. Following what Michael Peters said, the better way
will be to create a properly namespaced package instead.

But in the event that the right thing cannot be done, you can consider
creating a new interpreter for each site with the Options +Parent config
in Apache. Do note that this solution may be memory intensive, and will
not scale as broadly as a shared interpreter.

IMHO, try to get things right the first time. It's usually more painful
to revisit a quick-fix.



Marc Lambrichs wrote:
> I've taken over some code for a client. They've built a framework that
> used to run under mod_perl and changed it later, because of problems
> they had - what problems remains unknown - to cgi. Ofcourse I'm
> curious why they changed it. Here's my view: they create a parent
> App::Handler and in every virtual host they create a Site::Handler
> which has App::Handler as base. My first guess is that under mod_perl
> you don't know which Site::Handler will be called. Ofcourse, at first,
> the handler you're actually pointing to will be called, but if you
> change the request to another virtualhost, the wrong handler will be
> called.
>
> This would explain why it's running perfectly under cgi, because in
> every script call the correct lib path is defined.
>
> So, my first question is: am I right?
> Secondly, what if we're running the cgi under speedycgi?
>
> Thx,
> Marc

Re: refactoring client"s decision

On May 11, 2008, at 2:52 AM, Marc Lambrichs wrote:

> Here's my view: they create a parent App::Handler and in every
> virtual host they create a Site::Handler which has App::Handler as
> base. My first guess is that under mod_perl you don't know which
> Site::Handler will be called. Ofcourse, at first, the handler
> you're actually pointing to will be called, but if you change the
> request to another virtualhost, the wrong handler will be called.

Unless I'm confused, I've been doing that for years without issue.

I routinely have

P2XLP::$package -> base namespace
MyApp::$package -> @ISA( P2XLP::App::$package )

then use agressive class inheritance and package variables /
methods to make everything work beautifully.

Re: refactoring client"s decision

Jonathan Vanasco wrote:

> Unless I'm confused, I've been doing that for years without issue.
>
> I routinely have
>
> P2XLP::$package -> base namespace
> MyApp::$package -> @ISA( P2XLP::App::$package )

Are you saying that you have multiple MyApp::Foo packages running under the same
mod_perl interpreter (which was what the OPs client was trying to do before
giving up and going with normal CGI)? That won't behave correctly. Perl will
always use the first one it finds and ignore the rest.

--
Michael Peters
Plus Three, LP