Thanks, Jon, that's going to be useful. On 10 March 2011 19:36, Jonathan Swartz <swa...@pobox.com> wrote: > At this point it seems like you've graduated beyond what Mason's Apache-based > configuration can offer, and should write a wrapper (otherwise known as a > handler class). Then you can set data_dir and everything else > programmatically. > > http://search.cpan.org/perldoc?HTML::Mason::Admin#ADVANCED_CONFIGURATION > > Since you already have existing Mason-Apache configuration that it seems you > can't completely get rid of, see also > > > http://search.cpan.org/perldoc?HTML::Mason::Admin#Mixing_httpd.conf_Configuration_with_a_Wrapper > > HTH > Jon > > On Mar 10, 2011, at 7:41 AM, Mike Taylor wrote: > >> Thanks, Jonathan, for the quick response. What you're describing here >> would indeed by best practice, and I feel stupid for not having done >> it this way in the first place. But because the configurations of the >> various vhosts will be edited by several different people, most of >> them not particularly familiar with HTML::Mason, I am really looking >> for an approach that fails as safe as possible. >> >> Is there a way to have MasonDataDir take on a value related to MasonCompDir? >> >> -- Mike. >> >> >> On 10 March 2011 14:54, Jonathan Swartz <swa...@pobox.com> wrote: >>> When your configuration changes to point to the older component files, >>> can't you, at the same time, also change your data_dir? Having a separate >>> data_dir for the separate source seems cleanest to me. >>> >>> On Mar 10, 2011, at 3:45 AM, Mike Taylor wrote: >>> >>>> Dear HTML::Mason community, >>>> >>>> For reasons which, trust me, do make sense, the configuration of my >>>> HTML::Mason-based web application sometimes changes in such a way that >>>> Mason component root is switched to point to a version of my >>>> application that has older component files. In this situation, >>>> Mason's component compiler rightly sees only that the compiler version >>>> of the component is newer than the source, and therefore does not >>>> recompile. This can lead to terribly confusing situations where the >>>> application is running a mix of old and new code. >>>> >>>> It seems that a good way to ameliorate this problem is to have the >>>> compiled-component cache deleted whenever the web-server (Apache2) >>>> starts up. I have searched the documentation and source code for a >>>> setting that does this, but can't find one -- did I miss it, or is >>>> there no such setting? >>>> >>>> At the moment, I am "solving" this problem using a >>>> PerlPostConfigRequire directive in my Apache2 configuration, having it >>>> invoke a Perl script that removes the component cache. But this is >>>> unsatisfactory for two reasons. First, at the point in the Apache2 >>>> lifecycle where this is invoked, there is (as far as I can see) no way >>>> to get at the Mason data-directory setting, so I have to duplicate >>>> that setting in my Apache2 configuration's PerlSetVar MasonDataDir >>>> directive and the script. And second, I have many different virtual >>>> hosts running from the same set of Mason components, each with their >>>> own Apache2 configuration component and each potentially having a >>>> different MasonDataDir, and I would prefer not to have to duplicate >>>> this script and associated settings for each virtual host. >>>> >>>> One neat way to solve this problem would be if I could set up a >>>> "magic" HTML::Mason component -- as dhandler, for example, is magic -- >>>> that is automatically run when the web-server starts up. Is there >>>> such a component? >>>> >>>> Or is there a better approach? >>>> >>>> Many thanks in advance! >>>> >>>> ------------------------------------------------------------------------------ >>>> Colocation vs. Managed Hosting >>>> A question and answer guide to determining the best fit >>>> for your organization - today and in the future. >>>> http://p.sf.net/sfu/internap-sfd2d >>>> _______________________________________________ >>>> Mason-users mailing list >>>> Mason-users@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/mason-users >>> >>> >>> > > >
------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Mason-users mailing list Mason-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mason-users
