Actually, my initial suspicions were correct: It *was* a caching issue.
I had assumed that the object cache under Mason's cache root separated
cached objects based on the component root that they were served from,
but that appears not to be the case.

I'm somewhat surprised at this, as it seems clear that components served 
from different component paths need to be assumed to be different, 
but...

In any event, adding a configuration line to the httpd.conf to set the 
Data Directory for each virtual host to a different path works just 
fine, e.g.:

<VirtualHost 216.75.194.225:80>
     ServerName      siteA.com
     ServerAlias www.siteA.com

     DocumentRoot /web/siteA/htdocs

     PerlSetVar   MasonCompRoot /web/siteA/htdocs
     PerlSetVar   MasonCompRoot /usr/local/apache2/mason/siteA
     .
     .
     .
</VirtualHost>

This is all explained fairly clearly in the Administrator's Manual at 
www.masonhq.com.

<Steve>


On Mon, 16 Jan 2006, Mike M. wrote:

> We had the same exact problem.  In our case, it was because of a 
> mod_perl clash with libraries.  Our sites all use a set of common perl 
> libraries that we wrote.  Mod_perl uses the same memory space for all 
> the virtual hosts, so if you load the same library in more than one 
> virtual host, you get weird results like what you mention (because they 
> all seem to share things).  To solve the problem, we had to actually run 
> a separate apache instance for each virtual host that uses the same 
> libraries.
> 
> Hope this helps.
> 
> -mm
> 
> Stephen Reppucci wrote:
> > Hi folks,
> >
> > I'm relatively new to Mason, having used it for a couple of months now.
> > I've read the O'Reilly book, and poked around on the masonhq.com site,
> > but haven't found anything explaining this.
> >
> > I have two sites that I'm working on, they're currently running as
> > separate Virtual Hosts on the same web server, each with their own
> > document root. I've set Mason's component root to the document root
> > for each virtual host.  (I've attached a sanitized version of my
> > apache configs for reference.)
> >
> > The problem is that I'm getting the content for Site A when I make a
> > request for Site B. I've double checked my apache configs, and everything
> > seems correct. It smells to me like some type of caching issue, but possibly
> > I'm just missing something in my understanding of how to configure 
> > Mason to work correctly in this type of setup.
> >
> > Could someone please let me know if there's something obviously wrong
> > with what I'm trying to do here, and maybe point me at some other
> > docs I should be reading to get past this problem?
> >
> > Thanks!
> > <Steve>
> >
> >
> > <VirtualHost 216.75.194.225:80>
> >     ServerName      siteA.com
> >     ServerAlias www.siteA.com
> >
> >     DocumentRoot /web/siteA/htdocs
> >   
> >     PerlSetVar   MasonCompRoot /web/siteA/htdocs
> >     PerlModule HTML::Mason::ApacheHandler
> >     PerlModule URI
> >   
> >     <LocationMatch "\.(cmp|html|css)$">
> >       SetHandler  perl-script
> >       PerlHandler HTML::Mason::ApacheHandler
> >     </LocationMatch>
> >  
> >     <LocationMatch "(\.mas|handler)$">
> >       SetHandler  perl-script
> >       PerlHandler "sub { return Apache::Constants::NOT_FOUND }"
> >     </LocationMatch>
> >
> >     ErrorLog  logs/siteA/errors
> >     CustomLog logs/siteA/access combined env=!do-not-log
> > </VirtualHost>
> >
> > <VirtualHost 216.75.194.225:80>
> >   ServerName      siteB.com
> >   ServerAlias www.siteB.com
> >  
> >   DocumentRoot  /web/siteB/htdocs
> >  
> >   PerlSetVar   MasonCompRoot /web/siteB/htdocs
> >   PerlModule HTML::Mason::ApacheHandler
> >   PerlModule URI
> >
> >   <LocationMatch "\.(cmp|html|css)$">
> >     SetHandler  perl-script
> >     PerlHandler HTML::Mason::ApacheHandler
> >   </LocationMatch>
> >  
> >   <LocationMatch "(\.mas|handler)$">
> >     SetHandler  perl-script
> >     PerlHandler "sub { return Apache::Constants::NOT_FOUND }"
> >   </LocationMatch>
> >
> >     ErrorLog  logs/siteB/errors
> >     CustomLog logs/siteB/access combined env=!do-not-log
> > </VirtualHost>
> >
> >   
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Mason-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mason-users
> 

-- 
Steve Reppucci                                       [EMAIL PROTECTED] |
Logical Choice Software                          http://logsoft.com/ |
=-=-=-=-=-=-=-=-=-=-  My God!  What have I done?  -=-=-=-=-=-=-=-=-=-=



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Mason-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mason-users

Reply via email to