RE: [?] Same Named Modules, Different Paths
Yeah, this is an ideal way to go. Althought, depending to what degree you can trust your developers (contractors, etc.) and how much your sys admins want to admin it may or may not be a good fit. > > We have a similar issue here but it is designed more for development of > > modules/code by multiple developers. > > If each of your developers runs her own copy of Apache, each copy > listening to a different port, you can make the namespace collision > problems go away. Use a common httpd.conf for all developers with a > small section specifically for each one, and start Apache separately > for each developer with '-Ddeveloperid'. You can trade off between > the isolation of multiple copies of the complete site(s) on the one > machine, and the fun of sharing some of the code/data. I'd keep it > all separate, discs are cheap enough. > > > User ged > Port 8011 > ErrorLog /home/ged/apache/error_log > PidFile /tmp/ged.pid > LockFile /tmp/... > DocumentRoot ... > > > > User stas > Port 8012 > ErrorLog /home/stas/apache/error_log > PidFile /tmp/stas.pid > LockFile /tmp/... > DocumentRoot ... >
RE: [?] Same Named Modules, Different Paths
Hi all, On Wed, 6 Feb 2002, Stathy G. Touloumis wrote: > We have a similar issue here but it is designed more for development of > modules/code by multiple developers. If each of your developers runs her own copy of Apache, each copy listening to a different port, you can make the namespace collision problems go away. Use a common httpd.conf for all developers with a small section specifically for each one, and start Apache separately for each developer with '-Ddeveloperid'. You can trade off between the isolation of multiple copies of the complete site(s) on the one machine, and the fun of sharing some of the code/data. I'd keep it all separate, discs are cheap enough. User ged Port 8011 ErrorLog /home/ged/apache/error_log PidFile /tmp/ged.pid LockFile /tmp/... DocumentRoot ... User stas Port 8012 ErrorLog /home/stas/apache/error_log PidFile /tmp/stas.pid LockFile /tmp/... DocumentRoot ... 73, Ged.
RE: [?] Same Named Modules, Different Paths
We have a similar issue here but it is designed more for development of modules/code by multiple developers. This is managed through virtual hosts and although we do not have our production server the same as development we are able to view the production code through the development box. The development server is significantly slower due to the need to load/unload modules dynamically as well as perform cleanup but it is not really noticeable. Typically there is not a need to work on many modules per developer change so dynamic loading does not occur often. We have also incorporated Mason and template-toolkit into the same architecture (development/production paths). Our team is not large nor do we expect it to grow much (<10) so this may not be applicable for some environments. I am not sure how your handlers are setup to be executed but for us we have handlers which can be dynamically called depending on the environment that you are in (dev,stage,prod). For development this specific handler can check if there is a module being developed for that virtual host (developer change) and take appropriate action (prepend specific path to @INC, cleanup symbol table/ %INC, load new module) and a cleanup handler which checks to see if a module was loaded and if so perform cleanup (unload, @INC back, clean symbol table/%INC and reload non-developer module version). If you are mostly interested in loading modules specific to the environment it may be easier to have them on seperate boxes but I think it would be wise to be sure and manage the code through CVS or some other change management system as well. Things are working out well so far : ) > I have a problem, and I have a poor solution; I would like to see if I > can do even better. My problem is that I have a set of scripts and > modules that are duplicated on the same Apache server setup. One tree is > for debugging and developing, the other is the main release site. These > are managed through cvs. The issue I ran into was that the debug scripts > would request debug modules, but get the same-named release module if it > was already loaded in the same Apache process (and vice versa). > > Here what my old (buggy under mod_perl) include stuff was like: > > use lib "../lib"; > use MyModule; > > Here is what I had to do to force correct module loading (mostly stolen > from the great mod_perl guide): > > %INC = (); # Possibly unnecessary > do 'FindBin.pm'; > unshift @INC, "$FindBin::Bin"; # There are also modules in the same dir > as the script > unshift @INC, "$FindBin::Bin/../lib/"; > > require MyModule; > import MyModule; > > > So I'm loosing all of that slick compile-time speed savings and clean > code just so I can have two source trees on the same server. One obvious > answer is to move the devel tree off of the same server as the release > tree. I will eventually do that, but it would be cool to see a solution > that works with my current setup. Is there maybe a way to do tricks to > modules like Apache::Registry does to scripts by automagically > prepending the directory name behind the scenes? Any other ideas or > places to RTFM? > > Thanks, > > John Heitmann > >
Re: [?] Same Named Modules, Different Paths
Sam Tregar wrote: > On Sun, 3 Feb 2002, Stas Bekman wrote: > > >>I think the best solution is to run your staging server on a different >>port and use a front-end proxy to rewrite to the right server based on >>the Host: name. Alternatively put 2 NICs with 2 IPs, that will work if >>you don't hardcode the server name in your code/html. >> > > Or 1 NIC with 2 IPs if your OS supports it (Linux does). yup, thanks :0) >>BTW, mod_perl 2.0 solves this problem. >> > > How? Is the "one global namespace per server" changed in 2.0 perhaps? in mp-2.0 each vhost can have its own pool of perl interpreters, but please read the whole thing here: http://www.apache.org/~dougm/modperl_2.0.html#mod_perl%20and%20threaded%20mpms soon these docs will appear on perl.apache.org _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: [?] Same Named Modules, Different Paths
On Sun, 3 Feb 2002, Stas Bekman wrote: > I think the best solution is to run your staging server on a different > port and use a front-end proxy to rewrite to the right server based on > the Host: name. Alternatively put 2 NICs with 2 IPs, that will work if > you don't hardcode the server name in your code/html. Or 1 NIC with 2 IPs if your OS supports it (Linux does). > BTW, mod_perl 2.0 solves this problem. How? Is the "one global namespace per server" changed in 2.0 perhaps? -sam
Re: [?] Same Named Modules, Different Paths
John Heitmann wrote: > Hello, > > I have a problem, and I have a poor solution; I would like to see if I > can do even better. My problem is that I have a set of scripts and > modules that are duplicated on the same Apache server setup. One tree is > for debugging and developing, the other is the main release site. These > are managed through cvs. The issue I ran into was that the debug scripts > would request debug modules, but get the same-named release module if it > was already loaded in the same Apache process (and vice versa). > > Here what my old (buggy under mod_perl) include stuff was like: > > use lib "../lib"; > use MyModule; > > Here is what I had to do to force correct module loading (mostly stolen > from the great mod_perl guide): > > %INC = (); # Possibly unnecessary > do 'FindBin.pm'; > unshift @INC, "$FindBin::Bin"; # There are also modules in the same dir > as the script > unshift @INC, "$FindBin::Bin/../lib/"; > > require MyModule; > import MyModule; > > > So I'm loosing all of that slick compile-time speed savings and clean > code just so I can have two source trees on the same server. One obvious > answer is to move the devel tree off of the same server as the release > tree. I will eventually do that, but it would be cool to see a solution > that works with my current setup. Is there maybe a way to do tricks to > modules like Apache::Registry does to scripts by automagically > prepending the directory name behind the scenes? Any other ideas or > places to RTFM? > > Thanks, Some solutions are here, but they aren't good for production http://perl.apache.org/guide/config.html#Is_There_a_Way_to_Modify_INC_on I think the best solution is to run your staging server on a different port and use a front-end proxy to rewrite to the right server based on the Host: name. Alternatively put 2 NICs with 2 IPs, that will work if you don't hardcode the server name in your code/html. BTW, mod_perl 2.0 solves this problem. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: [?] Same Named Modules, Different Paths
On Sat, 2 Feb 2002, John Heitmann wrote: > Here is what I had to do to force correct module loading (mostly stolen > from the great mod_perl guide): > > %INC = (); # Possibly unnecessary > do 'FindBin.pm'; > unshift @INC, "$FindBin::Bin"; # There are also modules in the same dir > as the script > unshift @INC, "$FindBin::Bin/../lib/"; > > require MyModule; > import MyModule; This isn't going to work if your modules store anything in package globals. You should probably empty the package stash before you load the new module. That'll also save you "subroutine redefined" warnings too, I think. > One obvious answer is to move the devel tree off of the same server as > the release tree. This is undoubtably the best way to go. > Any other ideas or places to RTFM? I've sometimes been able to get away with running the live version through Apache::Registry while developing small changes under mod_cgi. Then when the .cgi version is ready I just copy it into the .pl and restart. However, a full staging server is definitely preferable. -sam
