Home/ Questions/Q 7510533
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-29T23:14:59+00:00

Currently, I have a web application, export it with eclipse in a war, copy

  • 0

Currently, I have a web application, export it with eclipse in a war, copy it manually with scp on the server, run a script that extracts the war, uses local configuration files to overwrite the ones in the war, and copies the extracted folder in tomcat/webapps. This sounds easy for a server or two, but not for 100.

How can I improve this, in order to have better control of the versions/configurations installed and to deploy it more easily?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    As this is not a single answer question, depending on the project and, why not, personal taste, I will post some the steps I believe could help the whole process of management/deployment.

    This does not mean that the solutions offered by the other posters are wrong (some of them received my upvote), but that this is what I found will work better for me.

    1) In order to have only one version of war with multiple configurations, I used JNDI. I set up a env variable to the path where I could find the config. This was added to web.xml:

    <env-entry>
<description>path to configuration files</description>
<env-entry-name>appName/pathToConfigFiles</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>/configFolder/appName/</env-entry-value>
</env-entry>

    This has a default value, when the config files are taken from the war, but it can be overriden by context.xml.

    <Environment name="appName/pathToConfigFiles" 
    type="java.lang.String" value="/etc/.."/>

    This way if someone needs for example to change the database connection parameters I will not have to deploy a new war. The admin can change the file in the configuration folder.
    The db config file and log4j file are my only external files. The rest of the configuration is done through the database.

    Main advantage is that the same artifact can be deployed both in testing and production and on any of the 100 servers. I currently use it on Tomcat, but env variables should be available in other app servers.

    2) Changed from an IDE build to a build-tool. I chose maven, but you can use ant/whatever.
    For this I found useful the following sources:

    For this I will also need to install Nexus as a mirror repository.

    3) Install a continuous integration tool like Jenkins/Hudson. It is a wonderful tool, but because of its complex nature, it will take time to configure it and increment it’s functionality. I am currently reading Jenkins: Definitive Guide, and I am trying to obtain the following functionalities:

    • Automated build server
    • Automated junit test server
    • Adding metrics
    • Automated test env deployment and Acceptance Testing
    • Continuous Deployment

    Until this will be accomplished the wars will be deployed through bash scripts. I just scp the war to the server (no exploding/rewarring).

    • 0