Separating war application name from war file name

2020-01-30 12:47发布

问题:

Currently if i deploy a war file on tomcat named say myapp.war, I can access its url by http://localhost/myapp/MyServlet.

However what I want is to deploy a war with a version number in the war file name and still have the same url. For eg, I want to deploy myapp-1.1.0.war and still have the url be http://localhost/myapp/MyServlet

Of course I need to keep updating the war and the version number will keep changing, so I cant hardcode the war filename anywhere. Is there any setting in web.xml I can use to keep the same url for the app regardless of the war filename?

回答1:

The solution is to stop using the automatic deployment feature of Tomcat, which takes the shortcut of setting the "context name" (the /myapp part of the URL) to the portion of the WAR filename before ".war".

Instead, extract the WAR contents to the filesystem yourself and setup an XML file at TOMCAT_HOME/conf/[enginename]/[hostname]/[contextname].xml which points the desired context path (such as /myapp) to the location of the application on disk (such as /opt/webapps/myapp-1.1.0/).

The Tomcat reference docs provide a good explanation of how Tomcat deploys applications automatically, and how you can configure customized logic for the mapping of context path to application file location (there are a handful of alternate ways to set this up other than the one I suggest above).



回答2:

You can use YOUR_WAR/META-INF/context.xml for this. Here is a sample:

<?xml version="1.0" encoding="UTF-8"?>
<Context antiJARLocking="true" path="/MyServlet"/>


回答3:

When using Maven you can control your deployment's path by doing the followings:

Tomcat's conf/tomcat-users.xml:

<tomcat-users>
  <role rolename="manager-gui"/>
  <role rolename="manager-script"/>
  <role rolename="manager-jmx"/>
  <role rolename="manager-status"/>
  <role rolename="admin-gui"/>
  <role rolename="admin-script"/>

  <user username="root" password="root" roles="manager-gui,manager-script,manager-jmx,manager-status,admin-gui,admin-script"/>

</tomcat-users>

~/.m2/settings.xml :

...
<server>
  <id>tomcat</id>
  <username>root</username>
  <password>root</password>
</server>
...

pom.xml :

...
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.example</groupId>
  <artifactId>myapp</artifactId>
  <version>1.1.0</version>
  <packaging>war</packaging>
...
  <build>
    <plugins>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>tomcat-maven-plugin</artifactId>
        <configuration>
          <!-- neglect /html below Tomcat7: -->
          <url>http://server:8080/manager/html</url>
          <!-- Refer to the server settings in your ~/.m2/settings.xml -->
          <server>tomcat</server>
          <path>/myWebApp</path>
        </configuration>
      </plugin>
      ....
    </plugins>
  </build>
...

Start your tomcat first Then build and deploy your application..

mvn clean install tomcat:deploy

..it will be accessible under http://server:8080/myWebApp



回答4:

I prefer to use "##" symbols for noting version of *.war files in the tomcat.
For example:
myapp.war -> URL: http://localhost:8080/myapp/MyServlet
myapp##1.1.0 -> URL: http://localhost:8080/myapp/MyServlet (still the same, because all symbols after "##" are ignoring by tomcat)



回答5:

There is no setting in web.xml for this. I do not believe that it is possible to set this inside the war file in a cross-container way - there is no mention of it in the spec anyway - so each container does it differently. jboss-web.xml, sun-web.xml, context.xml etc.



回答6:

I run into the same issue, and indeed, as @matt mentioned, the Tomcat reference docs provide a good explanation of how Tomcat deploys applications automatically, and how you can configure customized logic for the mapping of context path to application file location.

In my case, I used this advice (in 'path' explanation):

Even when statically defining a Context in server.xml, this attribute (/path) must not be set unless either the docBase is not located under the Host's appBase or both deployOnStartup and autoDeploy are false. If this rule is not followed, double deployment is likely to result.

so in my case, I switched both deployOnStartup and autoDeploy to false, so my WAR (e.g. a.WAR) was not auto-exploded to 'a' directory under webapps, but instead into 'b' directory, due to these settings:

<Host name="localhost"  appBase="webapps"
            autoDeploy="false" deployOnStartup="false" 
            unpackWARs="true" deployIgnore="${ignore.context}">

   <Context docBase="a" path="/b" />

</Host>