There are many articles on the Internet about how to change the servlet context path.

Today, while examining the codes in a legacy project, I saw that the following definition was made in the application.yaml

server:
  servlet:
    context-path: /v1

Frankly, I was wondering. Why would we want to change the servlet context path?

CodePudding user response：

One reason I can think of is when you want to make the application available behind a reverse proxy that routes incoming traffic via path prefixes, e.g.:

https://example.com                   --> Web App
https://example.com/v1/something      --> V1 App
https://example.com/v2/something-else --> V2 App

CodePudding user response：

Here is my real situation.

We have an dev server which is deployed with below context path:

/dev-context

QA or tester have different server and dev can't deploy without permissions and we only able to deploy after important bugs were fixed, if not , we only able to deploy at Friday with approval of managers to avoid regression test (regression test take so long).

/tester-context

To avoid conflicting on dev server, so our team decide to have more context path to test real data of test server sometimes... due to many complicated situations

/dev-connect-with-tester-sever-db

CodePudding user response：

First you need to understand, that:

context, in terms of web applications, is a way to differentiate between different (more than one) web applications on the same host; i.e. one context is one web-application, and another - is another, both served on the host.

Context is usually identified by the context address/name, that immediately follows that / after the host (and optionally - port) name.

Hence, different contexts on the same host will constitute different/disparate web-applications, or different instances/versions of the same web application (that is effectively, again - different applications).

Root context, for example, is the case if your application (its index.html, in some cases) is available and accessible on hostname:port/.

Having different contexts can be useful for:

1. Having different applications on the same host;
2. Having different versions of the same application;
3. Having different instances of the same application (dev, test, prod, etc.)
4. etc.