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 > >
