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 <[email protected]> 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
>>> [email protected]
>>> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/mason-users
