atemon has asked for the wisdom of the Perl Monks concerning the following question:

Hi Monks,

Background :
I host three website on a single machine. say www.mywebsite1.com, www.mywebsite2.com, www.mywebsite3.com. All the three runs on mod_perl2. In the start-up files all the sites I added path to the library containing custom modules for the VirtualServer.

Problem : The problem (for me) is that the path added to @INC for one server (VirtualHost) is available to other also. i.e. I added the path /home/mywebsite1.com/www/library to the first virtual host via its start-up file and /home/mywebsite2.com/www/library to second virtual host. 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). Is there a way to restrict the scope of library path added, to the current VirtualHost only?

Cheers !

--VC

Replies are listed 'Best First'.
Re: Scope of @INC in mod_perl 2
by ikegami (Patriarch) on Nov 04, 2009 at 06:58 UTC

    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]
Re: Scope of @INC in mod_perl 2
by WizardOfUz (Friar) on Nov 04, 2009 at 09:45 UTC

    Have you tried using a combination of PerlOptions +Parent and PerlSwitches -I in your VirtualHost directives?

    Update: You might want to read this and this.

[reply]
[d/l]
[select]
Re: Scope of @INC in mod_perl 2
by CountZero (Bishop) on Nov 04, 2009 at 14:10 UTC
    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]

Back to Seekers of Perl Wisdom