Forum:

Servlets

Servlet Path and Context Path Differences

Ranch Hand

Posts: 52

posted 1 year ago

Number of slices to send:

Optional 'thank-you' note:

Send

Hi,

i am trying to understand what is a servlet path and context path. whether both would differ and looking for an example to understand

can someone through some insight on this subject

thanks

Stephan van Hulst

Saloon Keeper

Posts: 15625

366

posted 1 year ago

1
Number of slices to send:

Optional 'thank-you' note:

Send

Right now I'm too lazy to find out if "servlet path" has a well defined meaning, so my explanation below stems from what I know from the top of my head.

"Context path" refers to the path of the URL that refers to the root of your application. Usually, this path is equal to the name of your WAR file.

"Servlet path" refers to a path that refers a specific servlet within your application. These paths are usually configured in the web.xml file of your application.

Here is an example:

/myapplication is the context path, and /myservlet is the (relative) servlet path.

Tim Holloway

Saloon Keeper

Posts: 27871

196

I like...

posted 1 year ago

Number of slices to send:

Optional 'thank-you' note:

Send

"Servlet path" is a Spring thing and offhand, I cannot remember what is is good for. I DON'T thing it is related to "servlet mapping", which is how a given context URL path is mapped to a servlet class, but like Stephan, I'm too lazy to check.

For beginners who deploy by simply dumping a WAR into the TOMCAT_HOME/webapps directory, the context path will be the same as the WAR name. If you put a Context file in the TOMCAT_HOME/conf/Catalina/localhost* directory, the context path will be the name of that Context file (less the "xml" extension).

There is also a contextPath attribute for Context, but it gets overridden by file naming. I'm not actually sure when it gets used, in fact, and I am also too lazy for that.

Plus Ian is due here in about 4 hours and power is getting to be a bit unpredictable.

---
*This assumes you aren't using a VirtualHost, since the hostname determines the actual directory path.

The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.

You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.

Bear Bibeault

Sheriff

Posts: 67748

173

I like...

posted 1 year ago

Number of slices to send:

Optional 'thank-you' note:

Send

Tim Holloway wrote:"Servlet path" is a Spring thing

Not correct, servlet path is part of the Servlet Spec.

And Stefan is correct in that it is the portion of the URL that maps the request to a specific servlet.

[Asking smart questions] [About Bear] [Books by Bear]

Joseph Sam

Ranch Hand

Posts: 52

posted 1 year ago

Number of slices to send:

Optional 'thank-you' note:

Send

Thanks for all the replies.

Tim Holloway

Saloon Keeper

Posts: 27871

196

I like...

posted 1 year ago

Number of slices to send:

Optional 'thank-you' note:

Send

Bear Bibeault wrote:

Tim Holloway wrote:"Servlet path" is a Spring thing

Not correct, servlet path is part of the Servlet Spec.

OK. The issue there is that I think there's a Spring/Spring Boot "servlet.path" config property that doesn't seem to fit that usage and it's currently under discussion in another thread. So I've got my wires crossed.

I tend to simply call the "servlet-mapping" web.xml element the "servlet URL mapping" and its associated logical servlet name/class itself. The term "servlet path" may be in the spec, but isn't literally used in web.xml.

Stephan van Hulst

Saloon Keeper

Posts: 15625

366

posted 1 year ago

Number of slices to send:

Optional 'thank-you' note:

Send

Tim Holloway wrote:There is also a contextPath attribute for Context, but it gets overridden by file naming. I'm not actually sure when it gets used, in fact, and I am also too lazy for that.

That would be the 'path' attribute. Within Tomcat, you would only use it when you're defining a static context in the server.xml configuration file. I can't think of any good use cases for that.

However, when you add the path attribute to a context.xml file of an application, NetBeans will use it to determine how to deploy the application to Tomcat, which can be useful if you want your context path to be different from the name of the WAR file that is being deployed.

Tim Holloway

Saloon Keeper

Posts: 27871

196

I like...

posted 1 year ago

Number of slices to send:

Optional 'thank-you' note:

Send

Ah, I am enlightened. Hadn't thought of that, since, after all, putting Context elements in the server.xml file these days can get you shunned from polite society.

Is your Netbeans quirk using the META-INF/context.xml file of a Tomcat project, or is it using a file from somewhere else in the project? I'm accustomed to manually copying my context file to the server's Catalina/localhost directory. If Eclipse can do that it's probably part of the plugin that I avoid.

Stephan van Hulst

Saloon Keeper

Posts: 15625

366

posted 1 year ago

Number of slices to send:

Optional 'thank-you' note:

Send

Tim Holloway wrote:Is your Netbeans quirk using the META-INF/context.xml file of a Tomcat project, or is it using a file from somewhere else in the project?

It uses META-INF/context.xml.

When NetBeans deploys the application to Tomcat, it doesn't actually copy the WAR to the webapps folder, it only copies the META-INF/context.xml file to the conf/Catalina/localhost/ directory and renames it so that its name matches the context path attribute. It also sets the docBase attribute so that it refers to the (exploded) WAR in your project's build directory.

Tim Holloway

Saloon Keeper

Posts: 27871

196

I like...

posted 1 year ago

Number of slices to send:

Optional 'thank-you' note:

Send

Hmmm. Dangit, you made me RTFM!

tomcat.apache.org wrote:
Individual Context elements may be explicitly defined:
In an individual file at /META-INF/context.xml inside the application files. Optionally (based on the Host's copyXML attribute) this may be copied to $CATALINA_BASE/conf/[enginename]/[hostname]/ and renamed to application's base file name plus a ".xml" extension.
In individual files (with a ".xml" extension) in the $CATALINA_BASE/conf/[enginename]/[hostname]/ directory. The context path and version will be derived from the base name of the file (the file name less the .xml extension). This file will always take precedence over any context.xml file packaged in the web application's META-INF directory.
Inside a Host element in the main conf/server.xml.

So it's not Netbeans doing this, It's Tomcat itself. Note that both the exploding/non-exploding of WARs and the copyXML feature are configurable server options. I have often chosen to put my WAR in a non-traditional read-only location (such as /opt/com/mousetech/webapps/app001.war) and not explode them, in fact. Although if performance is critical, I've been lead to suspect that explosion may be more performant. Have no hard numbers on that, though.

Stephan van Hulst

Saloon Keeper

Posts: 15625

366

posted 1 year ago

Number of slices to send:

Optional 'thank-you' note:

Send

Huh, I always assumed it was NetBeans doing that. So it could be that NetBeans calls a Tomcat command that deploys the context.xml file?

Tim Holloway

Saloon Keeper

Posts: 27871

196

I like...

posted 1 year ago

Number of slices to send:

Optional 'thank-you' note:

Send

Essentially. I've not used NetBeans like that, but if it's anything like IntelliJ, the IDE launches a Tomcat instance and deploys the project WAR into it, whereupon Tomcat will handle the context.xml file in the normal (documented) way as part of standard deployment.

I live a different life, where while developing I manually create a Context xml file, dump it under the desired context path name manually into a copy of TOMCAT_HOME/conf/Catalina/localhost, and the docBase points to the WAR being built in my Eclipse/Maven target directory. But that's me and I hate WTP because it doesn't accurately reflect my entire runtime configuration. I'm using the plugin Once Known As "sysdeo" to run my Tomcat, instead.

One of the reasons I generally use Eclipse is, in fact, because I can launch one Tomcat running multiple webapps and debug them as they talk to each other and I'm into evil things like that. IntelliJ, last time I looked assumed that the project would be the sole running webapp, and that's fine for most people. I just happen to be extra devious.

Stephan van Hulst

Saloon Keeper

Posts: 15625

366

posted 1 year ago

Number of slices to send:

Optional 'thank-you' note:

Send

Yeah, NetBeans also allows debugging multiple webapps in the same web server instance simultaneously. If it hadn't, I would have considered switching to a different IDE a while ago when I was working on maintenance of a collection of web services for one of our customers.