Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Message-ID: <4F2BEB35.4070007@apache.org>
Date: Fri, 03 Feb 2012 14:12:05 +0000
From: Mark Thomas <markt@apache.org>
User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64;
 rv:10.0) Gecko/20120129 Thunderbird/10.0
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: catalina.home, catalina.base properties in Tomcat 8
References: 
 <CABzHfVkiNAeXzgv2ru+aJoykrUt9eLnXVsqCPpNNdY5sxvCcow@mail.gmail.com>
In-Reply-To: 
 <CABzHfVkiNAeXzgv2ru+aJoykrUt9eLnXVsqCPpNNdY5sxvCcow@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 03/02/2012 13:35, Konstantin Kolinko wrote:
> Hi!
> 
> Recent commits in trunk changed how Tomcat home and base directories are set up
> and how they are accessed by Tomcat components.
> 
> Tomcat components no longer need catalina.home and catalina.base
> system properties, but the StandardServer class stores the values and
> there is convenient access method in ContainerBase.getCatalinaBase().
> The values are stored as File objects instead of Strings.
> 
> Unless I missed something, the change to startup code is that it no
> longer updates the system properties.
> It just calls Server#setCatalinaBase() and #setCatalinaHome()

Correct.

> If it is not just a bug and the intention is to get rid of those two
> System properties, then I have questions.

The intention is not to get rid of them, but to make the manner in which
they are used and the HOME and BASE directories used by the various
components to be consistent. It was a deliberate decision not to set
them on the grounds that they should be read during start-up and cached
- therefore setting them offers no benefits.

> The problem is that system properties may be used in different
> configuration files and in 3-rd party code.

Which may make the case for adding the setters back in - with
appropriate documentation as to the intended use.

> When Tomcat is run with startup scripts the ${catalina.home} and
> ${catalina.base} must be set by the script. So the problems are not
> apparent.

The only other supported way to start Tomcat is via the Tomcat class and
it has separate handling for this.

> Even so, there are several differences with Tomcat 7:
> 
> 1) Old bootstrap code converted the paths to canonical form. New code
> does not update the properties.
s/paths/paths defined by the properties/

> (To be precise I should say that it converted only non-absolute paths
> as discussed in Re:r1239522 thread, but that is just a little detail.)
> 
> 2) Both properties were initialized, even if only "catalina.home" was set.
> 
> 
> I will list some usages below.
> 
> (1) conf/catalina.policy
> (2) conf/logging.properties
> (3) various *.xml files read by Tomcat
> (4) lib/log4j.properties
> (5) WEB-INF/classes/logging.properties in web applications
> (6) WEB-INF/classes/log4j.properties in web applications
> (7) 3-rd party code
> 
> 
> Regarding (1) I think it is processed early by JRE and uses the values
> set by scripts. JRE itself should convert those paths to canonical
> form.
> 
> Regarding (2) it is processed only if scripts have configured logging,
> and I think it uses the values updated by Bootstrap. (Logging is
> accessed later than Bootstrap).

It accesses the system properties directly so it would have seen the (no
longer) updated values.

> Regarding (3) I think that there might be PropertySource
> implementation that provides the values of those properties. though I
> wonder how 3rd party implementations of PropertySource would look
> like.
> 
> (For reference: see "org.apache.tomcat.util.digester.PROPERTY_SOURCE"
> in config/systemprops.html)

The default implementation uses system properties.

> Regarding (5) and (3) for some time I am pondering an idea that there
> might be some mechanism to provide property names that depends on
> context. E.g. implement ${catalina.context.name} to use in logging
> configuration - maybe through
> ((WebappClassLoader)Thread.getContextClassLoader()).getContext()/getContextName().
> So it is possible to consider the fix along with implementation of
> this new feature (to be discussed separately).
> 
> 
> Regarding (4)(6)(7) - log4j and various 3-rd party code - I do not
> know what to do.
> 
> A possible workaround is to add a new <Listener> to server.xml that
> will set those two system properties when Tomcat starts.
> 
> That is relevant only if we go on with removing those properties.

The simplest solution is looking very much like restoring the update of
these two system properties after the (now consistent) processing.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org