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 <[EMAIL PROTECTED]> 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
