• Post Reply Bookmark Topic Watch Topic
  • New Topic

Change of Context Path of stopped applications on Tomcat 8  RSS feed

 
Jan Mortensen
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Im working on a Tomcat application. I just updated from Tomcat 7 to Tomcat 8 using the migration guide.
After I did this, I recognized that the context path of the applications deployed on the server behaves different now.

I am requesting the context path in a jsp. deployed in the ROOT directory using:

The result is the context path of the application: /app
The context path is always the same, if the application is running or stopped.

After upgrading to Tomcat 8.0.33 the behavior is different.
When the application is stoped, the context path that I get is an empty path (which results in pointing to ROOT).
The context path of the runnnig application is still the same: /app

I studied the migration guide and change log but I did not find any change which explains the different behavior.
I also googles a lot and have no clue what explains this behavior.

Can anybody help me finding out what the problem is?
 
Tim Holloway
Bartender
Posts: 18554
61
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the JavaRanch, Jan!

Tomcat is not a file server. It does not serve up files or directories and URLs are not file/directory paths, despite having a similar syntax and sometimes a similar behavior. So expecting file-like behavior from URLs is a dangerous thing to do.

Tomcat, like all J2EE and JEE servers deploys WARs, which are packaged webapps. In Tomcat, a WAR can either be a single archive (.war file) or an unzipped archive ("exploded" WAR).

When a web application is deployed in Tomcat, it is assigned a context path and any incoming URL that matches that path is routed to that web application. If you take a WAR file and simply copy it into the TOMCAT_HOME/webapps/ directory, Tomcat automatically deploys that webapp using default rules, which include exploding the WAR, if it's a war file and constructing/mapping a context path whose name matches the name of the WAR. And, incidentally, if you replace a WAR file with a newer WAR file, Tomcat will ignore the newer file and continue to use the exploded old WAR.

There is one exception to the WAR-name equals directory name rule and that is the root context ("/"). Because "/" refers, in Unix/Linux terms to the root of the filesystem tree, it's not a valid directory name, so Tomcat maps context path "/" to the WAR in the TOMCAT_HOME/ROOT directory.

Therefore the context path for any URL dispatched to the ROOT war properly has the context path "/". How you were ever getting "/app" I do not know, but the proper way to get a JSP's context path is via request.getContextPath().
 
Jan Mortensen
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Tim,

thank you for your reply.

As much as I know there is factualy no difference if I creating a war file and let tomcat deploy the application or copy the expanded directory into the webapp folder. Both results in an application accessible under context path /app.

But I think this is not the point here, because my application is running fine. I also think I did not clear enough explain what I am doing. I do not want the current context path.

On the Tomcat are various numbers of applications deployed (let the names be /app1, /app2, ..., /app10). Inside the jsp, deployed in ROOT, I want the to find out which applications are actually deployed on the server. I am doing this by asking for the ServletContext of the other applications:

When I then asking for the context path of the application it is either empty (application is not deployed) or I get the actual path (e.g. /app1) for a deployed application (started or stopped):

Thats how I create a list of deployed applications.
But now on Tomcat 8 I get an empty context path not only for applications which are not deployed, but also for applications which are deployed but stopped. This is a different behavior as it was on Tomcat 7.

I hope I could make clearer now what´s my problem.
 
Tim Holloway
Bartender
Posts: 18554
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I hope you won't be offended that I tend to be skeptical when people tell me "It works fine for me" when they've just posted a question asking why it doesn't work.

Rather than poking around in the innards of other apps, may I suggest actually asking Tomcat what is and isn't deployed, where it's deployed and whether it's running? Tomcat has a number of standards-sanctioned services that can do that for you.

First and foremost, you might want to research Tomcat's Management EJB (MEJB). Although it seems to be downplayed these days.

Then there are the ReST services that Tomcat offers. See https://tomcat.apache.org/tomcat-7.0-doc/manager-howto.html#List_Currently_Deployed_Applications

And the JSR-defined dervices. If memory server, the ones that deal with webapp management and deployment are JSR-176 and JSR-188.

And I've probably forgotted 2 or 3 other standard channels, but you get the idea.

The problem with hack solutions is that they tend to work fine right up until the moment that they don't. And according to Murphy's Law, that will often be the most inconvenient moment possible.
 
Jan Mortensen
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Tim,

again thanks for your reply.

I totally understand your skepticism. The point is that this application is a legacy application which is running for almost 15 year now with many customers, and it did work until now. I do not know how old this code is, because our git history goes only back for 7 year, and this was years before my time at the company .

I did also think about rewriting the jsp and removing such hacks (this is only one of many). But it would be nice to know what causes this issue, because I want to make shure that no other parts of the project are affected. Such kind of hacks are all around in a legacy application and to remove them all I would be busy for the next few years ;-)

Meanwhile I studied the Servlet API Specification to find out if the different behavior is caused by the servlet api update from 3.0 to 3.1 in Tomcat 8. But here I was also disappointed and did nothing which explains the behavior :-/
 
Jan Mortensen
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
unfortunately I could not find out what´s the issue. Instead I rewrote the JSP to use the manager endpoints.

Jan
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!