One additional way to do it is to create a symbolic link in tomcat's
$CATALINA_HOME/conf/engine/host/ that points to a fixed location where you
deploy my-application.xml. But worth mentioning here is that you still have
to have the passwords in plain text configuration files. In this method,
whenever you deploy your application, with whatever configuration, tomcat
will always refer to your newly deployed my-application.xml rather than
having a copy of the old version or having to deploy another time to
$CATALINA_HOME. While symbolic links are Linux-only, Windows has shortcuts.
I never tried this method on Windows, but I guess Windows shortcuts are
also preserved even if the original copy of the file was removed.
If you use Ant to build your application, you can use the symlink task to
create the symbolic link, or use the exec task to run the "ln" command that
creates the symbolic link on Linux. The former task (symlink) is usable if
the user running the build script has write permissions on the directory
where the symlink will be created (we use it for tomcat). While the latter
(exec) is necessary if the user does not have write permissions (we use
this for httpd because httpd conf files are in /etc which requires root
permissions).
We run the above tasks only when the symbolic links are not there. But in
future builds, we just deploy ROOT.xml and ${APP_NAME}.conf to
${APP_HOME}/conf/tomcat and ${APP_HOME}/conf/httpd, respectively.
${user.ROOT_PASSWORD} refers to a property in a property file supplied to
Ant during a build. It can be the root password (not preferrable, I use
this task only on local testing environments), or it can be the password
for a user that has permissions on the target directory (that's if you
don't want to run the whole build script with that user and provided you
reconfigure the task to use that privileged user instead of sudo).
For Windows, I don't think there's a specific task for creating a shortcut.
If it turned out there isn't, you can also use the exec task to run
the SHORTCUT.exe
utility that creates shortcuts on Windows. I never tried this though.
I usually prefer this method for platform-independency because the
application files (whether web or standard application) are all deployed to
a HOME directory for that application (outside tomcat's webapps directory).
So whatever OS (Windows/Linux) and whatever Linux distro (there are
differences between Ubuntu and CentOS for example), everything changed is
just in the APP_HOME, and everything is automated by the Ant build script.
And we do set an environment property specifying APP_HOME property.
Hope this helps.
Regards
Nasry
On Mon, Jul 4, 2016 at 5:42 PM, Philip Hachey
wrote:
> Hello. I am seeking some advice for the best ways to deploy Java web
> applications to different Tomcat environments.
>
> In particular, my application requires that a JNDI resource be defined for
> a database, where the database server address and credentials will vary
> depending on the environment the application is deployed to.
>
> * Tomcat: 8.0.36
> * OS: varies depending on the environment deployed to
>
> If I include in the WAR file, a META-INF/context.xml that includes the
> Resource element, Tomcat will use that to create the file:
> $CATALINA_HOME/conf/engine/host/my-application.xml
>
> The context file my-application.xml can then be modified so that the
> Resource settings are appropriate for the environment.
>
> However, if, for any reason, the application is undeployed and then
> re-deployed, my-application.xml will be recreated with the settings as they
> originally appeared in the WAR file.
>
> The options that seem evident to me are:
>
> 1) Create a different WAR file for each environment. This strikes me as a
> bit onerous.
>
> 2) Use environment variables in my-application.xml such as:
> url="${databaseurl}" and then define those environment variables using the
> Environment element in the GlobalNamingResources of Tomcat's server.xml.
>
> Regarding #2, would it be possible to instead use a properties file to
> define the variables? I assume adding entries to catalina.properties would
> work, but is it possible to define a properties file separate from
> catalina.properties which deals more with system properties rather than
> application properties?
>
> I haven't been able to find a documented standard methodology for Tomcat
> deployments to different environments, but I'm certain there must be some
> common and elegant ways of doing this. I'm interested in hearing what
> others have done.
>
> Thank you,
> Philip
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
ᐧ
