https://issues.apache.org/bugzilla/show_bug.cgi?id=50677
Summary: Allow system property variables in catalina.properties
Product: Tomcat 7
Version: trunk
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: j...@riggs.me
We currently have two hardcoded "variables" that we substitute in
catalina.properties, ${catalina.base} and ${catalina.home}. Is there value in
expanding this functionality? Here is my scenario:
I have several apps, app1, app2, etc. I have a shared lib directory of jars
that the apps share. In addition, the apps may have several instances running
in different "environments" (prod, QA, dev, etc.), and each environment has a
corresponding version of the lib directory. The Tomcat configs for the apps
(catalina.base) are version-controlled.
Now, I want each instance of these apps (catalina.base) to be as portable as
possible without having to make a bunch of changes for each environment. So, I
want to be able to copy the app1-prod catalina.base to app1-qa and not have to
make a lot of local modifications to catalina.properties and friends to make it
work. My init script knows that app1-qa is a QA instance and needs to point to
the lib-qa shared directory. So, I set a system property in the init script
via CATALINA_OPTS: -Dshared.lib.dir=/path/to/lib-qa for QA and
-Dshared.lib.dir=/path/to/lib-prod for production. What I would like to do is
use this system property via ${property.name} in my common.loader in
catalina.properties. The result is that the catalina.base files are the exact
same from a configuration perspective without a bunch of local modifications.
I have created two proposed patches for this functionality. Both work well,
but each one has the potential for some slightly different behavior, so I would
like to hear the thoughts of the developers on each.
--
Proposal A (currently in production use for my environment):
The variable substitution takes place upon retrieval in
CatalinaProperties.getProperty(), pulling in the current value of the system
property. This allows other properties defined in catalina.properties to be
substituted. The (potential) downside or risk is that the value of a
catalina.property value may change over time if the system properties
referenced in its value are changed by the code during the JVM's lifecycle.
--
Proposal B:
The variable substitution takes place in the class initializer,
loadProperties(). This means that every call to
CatalinaProperties.getProperty() will return the same result, with system
property variables replaced with their value at the time the class was loaded.
The downside of this is that properties set in catalina.properties cannot be
used in other properties defined in that file, because they may not yet be set
based on the order they are returned by the Enumeration. This could be worked
around, but it would probably take another iteration over the properties (not
really a big deal).
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
