tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <>
Subject catalina.home, catalina.base properties in Tomcat 8
Date Fri, 03 Feb 2012 13:35:51 GMT

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()

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

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

Recent code changes:  (Tomcat class,
+followup fixes in r1239784, r1240048)  (Bootstrap, Catalina)

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. 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.
(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/
(3) various *.xml files read by Tomcat
(4) lib/
(5) WEB-INF/classes/ in web applications
(6) WEB-INF/classes/ 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

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).

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

(For reference: see "org.apache.tomcat.util.digester.PROPERTY_SOURCE"
in config/systemprops.html)

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 ${} to use in logging
configuration - maybe through
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.

Best regards,
Konstantin Kolinko

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

View raw message