Win a copy of Android Programming: The Big Nerd Ranch Guide this week in the Android forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Hosting a web application at root of tomcat without placing context inside server.xml  RSS feed

 
Aurelia Soni
Greenhorn
Posts: 8
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Ranchers,

I am in need of your help. I have a web application that I am migrating to new servers.Currently this application is hosted at the root of tomcat. so I have this in my server.xml :

This application's static content is hosted by Apache web server and dynamic requests are passed to tomcat.

This is apache configuration:



The first page loaded when one enters https://myservername is landing.html, here depending on the option user selects, he is forwarded to sso/authentication-authorization site and when the login is successful he is forwarded back to
https://myservername/home page. I cannot change this url since other parties are using it and might have bookmarked it.

New migration rule is to keep tomcat configuration generalized so it can be managed by system engineers automatically. so my custom change in server.xml

will not be managed anymore. I need to find other way to keep it hosted at root of tomcat.

I followed tomcat documentation and found that

Individual context can be defined in individual files (with a ".xml" extension) in the $CATALINA_HOME/conf/[enginename]/[hostname]/ directory. The name of the file (less the .xml) extension will be used as the context path. Multi-level context paths may be defined using #, e.g. foo#bar.xml for a context path of /foo/bar. The default web application may be defined by using a file called ROOT.xml.

so I configured my context in a file called ROOT.xml at $CATALINA_HOME/conf/[enginename]/[hostname]/ but it still didnt deploy mywebapp at root. I tried another way by renaming context xml to mywebapp.xml too. No different result.
Though in the catalina logs I see something like ,

WARNING [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDescriptor A docBase /usr/local/tomcat/webapps/mywebapp inside the host appBase has been specified, and will be ignored

Note I havent deleted or altered ROOT folder in webapps at all.

My webapp is available at servername/mywebapp but static content is not loaded because the static content is at doc root and the browser page source shows that it expects it at /mywebapp/css/ or mywebapp/img/ etc . So I think somehow the apache config ProxyPass /img ! etc is also not working in this case. This is not the problem when mywebapp is hosted at tomcat root though.

Can anyone help in identifying why my context config in $CATALINA_HOME/conf/[enginename]/[hostname]/ROOT.xml is not deploying mywebapp at root ? Or is there any other way I can achieve this?

 
Tim Holloway
Bartender
Posts: 18608
68
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You shouldn't ever place Context elements in the server.xml file. That behavior has been discouraged since Tomcat version 3 at least.

The TOMCAT_HOME/conf/Catalina/localhost directory is one of the recommended places to put Context xml files, but the problem with the root context is that normally the context file's name determines what the Tomcat webapp context path will be. And that, incidentally, overrides the context path defined within the context XML file. One of Tomcat's quirks.

Your best bet to get what you want would be do delete the TOMCAT_HOME/webapps/ROOT directory contents and replace it with your own webapp, but personally, I don't much like doing that. You can get the same net effect by defining the Apache proxy path to be an ordinary context, since Apache will translate everything for you very nicely.

If you're using mod_proxy instead of mod_jk as your proxy mechanism - and it appears you are, you'd typically make your webapp be a VirtualHost (although a path within a non-J2EE app is fine, too), define your Java webapp under the context path "mywebapp" and code like this:



The path "/mywebapp" would never be visible to the outside world - it's strictly for intra-server proxy routing.

The static items are probably best handled by mod_rewrite, not by contortions in ProxyPass directives, and I should note that any static items specific to the Java webapp should be part of the Java webapp. Having Apache serve them separately stopped being more efficient about 15 years ago.
 
Aurelia Soni
Greenhorn
Posts: 8
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks a lot Tim.


The TOMCAT_HOME/conf/Catalina/localhost directory is one of the recommended places to put Context xml files, but the problem with the root context is that normally the context file's name determines what the Tomcat webapp context path will be. And that, incidentally, overrides the context path defined within the context XML file. One of Tomcat's quirks

Explains why mywebapp is not going at the root of tomcat. So obviously this will not work for me.


Your best bet to get what you want would be do delete the TOMCAT_HOME/webapps/ROOT directory contents and replace it with your own webapp

I cannot do this. I am migrating this app from one production server to other. This doesnt seem the Standard.



I tried this long back and the requests expected the static content at tomcat side, something like /mywebapp/css/ , /mywebapp/img/ etc while the static content is hosted at /docroot/css etc on Apache side. So the screen source showed 404 for all static content.


I should note that any static items specific to the Java webapp should be part of the Java webapp. Having Apache serve them separately stopped being more efficient about 15 years ago.


I think this app was designed around a decade ago so no surprise they decided to host static content at Apache layer.

I am thinking to define a separate CATALINA_BASE and manage my application there. This way no future upgrade will disturb my custom set up of CATALINA_BASE and the generic set up model of standard software will remain intact.
Please let me know your thoughts.
 
Tim Holloway
Bartender
Posts: 18608
68
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The problem with being the root context webapp in Tomcat is that normally the name of the WAR is what determines the URL context path. But "/" isn't a valid file or directory name, it's a path separator/delimiiter. So the authors of Tomcat adopted the convention that "ROOT" would stand in for "/". Or actually, "", since all contexts are relative to the post-server segment of the URL. And, of course, an empty directory name isn't valid for most filesystems, either, so same difference.

When Tomcat is distributed, it comes with a default root webapp, but a lot of shops delete it for security or resource reasons, since it's not essential for Tomcat. And quite a few shops do simply replace it with their own webapps, although I'm not a big proponent of that myself. Strictly speaking, none of the standard webapps that come with Tomcat are essential and you can freely delete any of them. Some Tomcat distros have even made a point of distributing the Tomcat webapps separately from the Tomcat server. Even the admin apps are optional, and can be deleted depending on how paranoid you might happen to be.

I'm doing a sloppy read here, but it sounds like stuff like CSS need mod_rewrite rules so that for example /mywebapp/css/ items would be rewritten to /docroot/css/ . That should take care of Apache serving static content and it's a little more straightforward than inverting a proxy definition even though you'd need a rule for css, js, img and whatever other static content Apache serves. Truth be told, I've often maintained a separate server for static content if I want to share certain CSS. JavaScript and/or images between multiple webapps. Reduces the size of the individual apps and allows one-stop updating of the files to keep the shop consistent. Whether that shared-content server is Apache, Tomcat, or something entirely different mostly depends on the shop requirements.

CATALINA_HOME and CATALINA_BASE are shipped merged into each other, since that makes for the simplest Tomcat deployments when you don't need multiple Tomcat instances. I cannot guarantee that separating them merely for content purposes will make much difference, but if you feel more comfortable that way, go ahead. The bigger offense is when people make their webapps write into the WAR's WEB-INF or other directories. A WAR should be treated as read-only Failure to observe that precaution can and will cause Bad Things to happen.

Oh, a brief editorial:

Some people think that "Software doesn't wear out" and that they can continue to run the same code forever - a single payment up front to get the app written, and then the rest is all free.

That way lies danger. Software usually rots from the outside in. OS's change. Hardware changes. Languages and libraries change - although thankfully Java goes to a great deal of effort to minimize that last part. As time goes by, the technological debt from not keeping apps up to date mounts higher and higher until it becomes prohibitive and instead of small, relatively painless tweaks along the way, everything has to be handled in one massive go. And Murphy's Law predicts that that point will occur at a time when it's most embarrassing and expensive to have the system collapse. And when I say "embarrassing", I mean to the company and to the CEO, not just the IT department.

So if you've been trying to patch a decades-old app through one more band-aid, I suggest that you - and your superiors - take that into consideration.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!