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() 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: http://svn.apache.org/viewvc?rev=1239522&view=rev (Tomcat class, +followup fixes in r1239784, r1240048) http://svn.apache.org/viewvc?rev=1239527&view=rev (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/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). 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) 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. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
