Limiting the scope of @INC doesn't help because the following isn't true:
When I try to use some modules with same name as one used with previous servers(VirtualHost), its trying to load from the path added by previous servers (VirtualHost).
If a named module has already been loaded, Perl won't try to load it again. It doesn't get to the point of using @INC.
And if you forced your way around that too, it would still not work since you'd have two modules trying to occupy the same namespace.
Sorry, but an instance of Perl can't handle two modules with the same name.
| [reply]
[d/l]
[select] |
| [reply]
[d/l]
[select] |
Actually, what you are trying to do goes against the grain of what mod_perl is all about: i.e. integrating a persistent Perl-interpreter inside the web-server.If you have custom modules for each virtual server, these modules should be named differently and if the differences are just matters of configuration which are hard-coded into the modules then you should factor out the differences and put it in separate configuration files that are specific for each virtual server. It is never a good idea to have same-named modules that live in the same namespace do different things (other than through a config-file). That way lies madness and problems.
CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James
| [reply] |
In my humble opinion, there is nothing wrong with setting up different @INC environments for different VirtualHosts. Actually, it's a great way to test different versions of a module.
| [reply]
[d/l] |
Maybe, but not within one persistent Perl-interpreter as mod_perl does.
CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James
| [reply] |
