Re: Suggestions for deploying context.xml for different environments?
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
>
>
ᐧ
Re: Suggestions for deploying context.xml for different environments?
> >> 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?
> >>
> > We set such system properties in setenv.sh, e.g.:
> >
> > JAVA_OPTS="$JAVA_OPTS -Ddatabase.password=$DATABASE_PASSWORD"
> >
> >
> > The environment variable $DATABASE_PASSWORD is used because we wrap
our
> > applications along with tomcat and jvm in docker images. Operations
> > specify environment specific parameters (as database passwords) when
they
> > launch the docker container with -e switch, e.g.:
> >
> > docker run -d -e DATABASE_PASSWORD=secret .
> >
> >
> > Due to docker we don't need context.xml files inside WARs. Instead we
have
> > application specific tomcat config files in our source trees. Our
build
> > process includes them in the docker image as top level tomcat config.
As
> > we build application specific images there is just one app per image
and
> > thus per tomcat instance.
> >
> >
> > Of course that is linux only.
>
> I don't believe docker is an option for me. At least, not at this
> time. I do like the idea of setting environment-specific variables as
> system properties in the setenv.sh. However, setting passwords there
> gives me pause for security reasons since it would be visible to
> anything running within the Tomcat environment, should there be some way
> to exploit a vulnerability and access Tomcat's system properties or
> environment variables remotely.
>
> Thank you for sharing,
> Philip
>
Well, having passwords in config files does not add much security ;)
Regards,
Christoph
This Email was scanned by Sophos Anti Virus
Re: Suggestions for deploying context.xml for different environments?
Thank you for the reply, Christoph.
On 16-07-05 03:32 AM, Christoph Nenning 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?
We set such system properties in setenv.sh, e.g.:
JAVA_OPTS="$JAVA_OPTS -Ddatabase.password=$DATABASE_PASSWORD"
The environment variable $DATABASE_PASSWORD is used because we wrap our
applications along with tomcat and jvm in docker images. Operations
specify environment specific parameters (as database passwords) when they
launch the docker container with -e switch, e.g.:
docker run -d -e DATABASE_PASSWORD=secret .
Due to docker we don't need context.xml files inside WARs. Instead we have
application specific tomcat config files in our source trees. Our build
process includes them in the docker image as top level tomcat config. As
we build application specific images there is just one app per image and
thus per tomcat instance.
Of course that is linux only.
I don't believe docker is an option for me. At least, not at this
time. I do like the idea of setting environment-specific variables as
system properties in the setenv.sh. However, setting passwords there
gives me pause for security reasons since it would be visible to
anything running within the Tomcat environment, should there be some way
to exploit a vulnerability and access Tomcat's system properties or
environment variables remotely.
Thank you for sharing,
Philip
regards,
Christoph
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
This Email was scanned by Sophos Anti Virus
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Suggestions for deploying context.xml for different environments?
Will the context.xml file meet your requirement?
http://javabeat.net/tomcat-jndi/
On 7/4/2016 10:42 AM, 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
>
--
The people that bring you Usque
Re: Suggestions for deploying context.xml for different environments?
> 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?
>
We set such system properties in setenv.sh, e.g.:
JAVA_OPTS="$JAVA_OPTS -Ddatabase.password=$DATABASE_PASSWORD"
The environment variable $DATABASE_PASSWORD is used because we wrap our
applications along with tomcat and jvm in docker images. Operations
specify environment specific parameters (as database passwords) when they
launch the docker container with -e switch, e.g.:
docker run -d -e DATABASE_PASSWORD=secret .
Due to docker we don't need context.xml files inside WARs. Instead we have
application specific tomcat config files in our source trees. Our build
process includes them in the docker image as top level tomcat config. As
we build application specific images there is just one app per image and
thus per tomcat instance.
Of course that is linux only.
regards,
Christoph
> 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
>
This Email was scanned by Sophos Anti Virus
Suggestions for deploying context.xml for different environments?
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
