Summary: The catalina.config property (which specifies an alternate location for the information contained in catalina.properties) only understands a full URL. This would be a change in the properties loader to check getCatalinaBase()/configUrl before checking new URL(configUrl). I downloaded the latest source and I'm not sure where this change would be made. o.a.t.util.loader.LoaderProperties (doesn't seem to exist anymore?) or o.a.c.startup.CatalinaProperties If the bug is a go, let me know and I'll submit a patch, thanks! Details: During development, we override log4j.properties with log4j.development.properties by specifying -Dlog4j.properties=log4j.development.properties in our JAVA_OPTS when starting Tomcat. It allows us to use a shared development configuration (shared IDEA project) without having to refer to hardcoded paths. During development, we override settings in server.xml (e.g. shutdown port, http, https ports) by using properties we define in catalina.properties. Currently this means we each have to remember to change the value of -Dcatalina.config=file://... because it only takes a URL.
Apologies, I realized my summary was pretty bleak :) What is desired is to provide something like this: -Dcatalina.config=catalina.developer.properties And during bootstrapping, Catalina would check for properties in this order: 1) getCatalinaBase()/getConfigUrl() 2) getConfigUrl() This should preserve backwards compatibility with the full Url. Thanks! Rob
(In reply to comment #0) > Summary: > > The catalina.config property (which specifies an alternate location for the > information contained in catalina.properties) only understands a full URL. > Relative URLs are also allowed. E.g., the following works for me on Windows XP: set JAVA_OPTS=-Dcatalina.config=file:../conf/catalina2.properties The URL is relative to the current directory at the time when the JVM is launched. On Windows that is determined by what is written in your shortcut, or what is the current directory in your shell when you launch %CATALINA_HOME%\bin\catalina.bat. The above example works when you are in %CATALINA_HOME%\bin, which is the most usual case. > o.a.c.startup.CatalinaProperties o.a.c.startup.Bootstrap o.a.c.startup.CatalinaProperties
Hi Konstantin, Many thanks for the quick reply! Unfortunately, that relatively is different on every developer's machine based on their own CATALINA_HOME and where they've chosen to check out CATALINA_BASE for the branch they're working on. So we still have to remember to change the custom property every time we work on a different branch inside of our project settings. This is versus the log4j-like approach of looking for an unqualified filename in a known location (in log4j's case, it's the web app classloader, but I think you understand what I'm saying :) Would I be more likely to have a patch approved by overloading the use of the existing property or suggesting a new property? catalina.config=foo.properties versus: catalina.config.filename=foo.properties Just curious if/where I should spend my time. Thanks again!! Rob
Hi guys, First of all, amazing work on the build environment. Instructions were easy to follow and everything (including the unit tests) worked on the first go. Contributing could not be easier! Attached a patch containing the following: - Added "catalina.config.filename" system property with a default value of "catalina.properties". This way you can specify another config file to use without having to worry about URLs or base directories. - Updated documentation to include a description of the new property. Let me know if there are any questions or anything missing from the patch. Thanks! Rob
Created attachment 24869 [details] Patch to add new catalina.config.filename property.
Thanks for the patch and sorry this didn't get looked at further at the time. I've just picked this up as part of my review of the remaining Tomcat 6 bugs. I opted to implement this as part of the existing catalina.config property rather than as a new property.