tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: VirtualHost inheritance (was Re: [Bug 43753] ...)
Date Fri, 02 Nov 2007 08:38:43 GMT
Mladen Turk schrieb:
> Rainer Jung wrote:
>> Hi,
>> be careful:
> OK :)
>> I also added an option JkMountCopyAll,
> OK, but clone is called when there is no "JkMountCopy All" defined
> if (sconf && sconf->was_initialized == JK_TRUE && jk_mount_copy_all
>     clone_jk_config
> So if there is *no* module directives and JkMountCopy All is not defined
> the clone_jk_config is still called (without mounts but with copied
> envvars).

Yes, at the moment I don't trust the state handling ...
I still need to check and fix that.

To not clone if JkMountCopyAll is set is OK, because then we
automatically use the same config struct, as the parent vhost. httpd
simply does not call our create structure in this case and instead
inhertis the full structure automatically.

We only want to clone (and empty the JkMounts), if we have an "empty"
vhost, but don't want to inherit the JkMounts (the latter being the

>> which automatically puts a
>> JkMountCopy into every vhost and saves memory, because we then do not
>> clone but instead share the config struct (if no other jk directives are
>> in the vhost).
> But they use different apr_pools with different lifetime, so that might
> be the problem later. Cloned configs although allocated don't register
> pool cleanup

OK. Needs fixing.

> Anyhow the envvar tables should be NULLed in clone, cause
> merge will later concatenate them for each vhost.

That's easy and most likely the point. Then we have the same question here:

- we shouldn't inherit JkEnvVars by default between vhosts
- we could have an option to inherit them (like JkEnvVarCopy) per vhost
and one to inherit them globally (JkEnvVarCopyAll).

Why is globally ineriting interesting in its own: if people use a lot of
vhosts (hundreds), with global inheritance of everything (mounts and
vars), they can automatically share the same jk config structure and
save quite some memory.

> Regards,
> Mladen.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message