Hi there Josh (and everybody)
I've got a strange problem-- I've just tracked down what's causing it (and given enough time, I'll figure out the solution) but I was hoping that perhaps someone else had run into it before and might have a quick answer... I have some commercial software I've written for a client (storefront software) and it is in early production now so I'm having to do dev work in a copy of the software tree.. To explain my setup a little better, I have one _whole_ domain dedicated to the production side and another whole domain dedicated to the dev side. Production gets domain #1 and its own apache virtual config. In the config I set all the variables (I think I'm okay there) and preload all the code and modules. No problem there either. The code and modules are located in their _own_ directory completely separate from the dev version. Dev side gets domain #2 and its own virtual config. Again, all config vars seem to be okay and preload code and modules. So far so good. The code and modules are likewise located in their own directory tree which mirrors the production tree except for the base dir and of course any changes in the code that are newer than the production code. Okay, everything was working swimmingly and seemingly like it should when I noticed a tiny glitch. As things often go, in tracking down the glitch I discovered a weak area of my code that needed some significant revisions. No problem there, the revisions work, I'm cool with that part-- but when I go to test them out live in the dev server, I get really weird squirrely results. The exercisers run the modules flawlessly so I know its not the modules themselves.. Some sleuthing reveals a problem with @INC... BOTH the production AND development libraries are somehow winding up in the @INC array-- I'm puzzled at how this is happening as both of the virtual configs only set their own respective library directories and there is NO crossover between the code other than the common Apache web server. So the bottom line cause of my weirdness is that I'm loading up modules (I'm guessing at random, or perhaps by @INC order, I'm not sure) from the wrong code tree (library directory). And in my DEV version, which should be using the NEW module under test, its ACTUALLY using the OLD version in production. There is NO OTHER WAY to get the production module, and printing out the @INC array confirms that both paths are in there. I remember Josh saying something about this awhile back but I can't find the message... Any suggestions? fwiw, here is the @INC array. The two paths in question are "/web/asp/impact/lib" and "/web/asp/stores/lib". . /usr/lib/perl5/5.6.1 /usr/lib/perl5/5.6.1/i686-linux /usr/lib/perl5/site_perl /usr/lib/perl5/site_perl/5.6.0 /usr/lib/perl5/site_perl/5.6.1 /usr/lib/perl5/site_perl/5.6.1/ /usr/lib/perl5/site_perl/5.6.1//i686-linux /usr/lib/perl5/site_perl/5.6.1/i686-linux /usr/local/apache/ /usr/local/apache/lib/perl /web/asp/impact/lib /web/asp/stores/lib --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
