When to use server.xml or web.xml to define my webapp...

[joe]

I'm having trouble really grokking the way Tomcat handles deployment of
webapps. It seems that there are two ways to define your webapps.

First, in server.xml, I can make Context elements inside of my Host
elements. There, I can specify the url path to tie into, the docBase,
the workDir, whether it's reloadable, and, I think, whether to
autoDeploy wars.

Or, I've found that I can just put my webapps (with a web.xml in the
WEB-INF dir) in Tomcat's default webapps directory and they get
automatically deployed to a url path matching the directory.

Are these two pretty much interchangeable, or should I almost always be
using one of these and, in rare cases, using the other?

What are the benefits and shortcomings of each one? For example, I know
that the server.xml Context element lets me specify reloadable=true
(something I want when doing development and need to test changes
without having to restart the server). Can the web.xml method do this?

Also, do either of these methods (or a combination of them) allow me to
load my JSPs and/or other resources (like jpegs, stylesheets, etc) from
one path, while getting the servlet classes and libs (ie, all of the
stuff from WEB-INF) from another path? (Yes, I know I could probably
use symbolic links. I'd like to do it differently).

Thanks in advance....

- Joe

 

[Juha Laiho]

(e-mail address removed) said:

I'm having trouble really grokking the way Tomcat handles deployment of
webapps. It seems that there are two ways to define your webapps.

First, in server.xml, I can make Context elements inside of my Host
elements. There, I can specify the url path to tie into, the docBase,
the workDir, whether it's reloadable, and, I think, whether to
autoDeploy wars.

Or, I've found that I can just put my webapps (with a web.xml in the
WEB-INF dir) in Tomcat's default webapps directory and they get
automatically deployed to a url path matching the directory.

This latter behaviour can be disabled in server.xml.

Server.xml controls how applications are deployed, overall.
This is specific to Tomcat.

Web.xml controls what the application contains and how it behaves.
This comes from Java Servlet Specification, and works the same way
for all servlet containers implementing the same version of the
servlet specification.

So, to some extent you use both. Minimal use of server.xml would be
to set everything to automatic ("development mode", where your
Tomcat spends part of its time checking whether anything in your
applications has changed) -- and the other end would be to
disable all automation, and hard-code deployment strategy for
each application ("no-surprises mode", nothing changes without
explicit configuration change).

Also, do either of these methods (or a combination of them) allow me to
load my JSPs and/or other resources (like jpegs, stylesheets, etc) from
one path, while getting the servlet classes and libs (ie, all of the
stuff from WEB-INF) from another path? (Yes, I know I could probably
use symbolic links. I'd like to do it differently).

Please don't mess with the application deployment directory structure.
It is mandated by the servlet specification. Best would be to
"forget" that you may have an exploded directory somewhere and
consider your applications as .war files.

 

[Chris Smith]

First, in server.xml, I can make Context elements inside of my Host
elements. There, I can specify the url path to tie into, the docBase,
the workDir, whether it's reloadable, and, I think, whether to
autoDeploy wars.

Or, I've found that I can just put my webapps (with a web.xml in the
WEB-INF dir) in Tomcat's default webapps directory and they get
automatically deployed to a url path matching the directory.

Are these two pretty much interchangeable, or should I almost always be
using one of these and, in rare cases, using the other?

If you are developing the application, it's a little kludgy to have the
development tool look in the Tomcat webapps directory for code. For
that reason, I always use a Context element in server.xml for
development. It avoids an extra deployment step.

For deployment on other servers where you aren't developing code, you
can just drop war files into webapps, which is easier than editing
server.xml

Also, do either of these methods (or a combination of them) allow me to
load my JSPs and/or other resources (like jpegs, stylesheets, etc) from
one path, while getting the servlet classes and libs (ie, all of the
stuff from WEB-INF) from another path? (Yes, I know I could probably
use symbolic links. I'd like to do it differently).

Not in a straight-forward way. I'd just put them together in one path.
Unless there's a specific reason you're trying to do this?

 

[joe]

Not in a straight-forward way. I'd just put them together in one path.
Unless there's a specific reason you're trying to do this?

I'm using IntelliJ IDEA to develop some servlets and JSP's, and it
seems to want to put the compiled classes into an "exploded" directory.
So, where my project home is, say "$PROJHOME", I get an arrangement
like:

$PROJHOME/ <- JSP's get put here
$PROJHOME/WEB-INF <- This gets a single web.xml file, and that's it
$PROJHOME/exploded/WEB-INF <- This gets an exact duplicate of the
previous web.xml
$PROJHOME/exploded/WEB-INF/classes <- compiled code goes here

Although IDEA claims to be able to launch a private version of Tomcat
which handles all of this somehow, Tomcat crashes whenever I try to
launch it from IDEA. So, I'm stuck with having to run Tomcat externally
and have it look where IDEA is dumping the files.

The upshot of this is that I can either tell Tomcat that "$PROJHOME/"
is my approot (where it would find the JSP's) or that
"$PROJHOME/exploded" is (where it would find my servlets). Fortunately,
I don't have any JSP's in the project yet... but I'd like to start
incorporating them, but I'll write it off as a lost cause if I can't
remedy this easily.

I'm doing this development on a laptop with less ram than I really
need. This is why I'm loathe to pack the project into a WAR, only to
have Tomcat have to unpack it again just so I can test a few changed
lines of code. It's also why I want to avoid firing up Apache just to
do some proxying magic where it sends all *.JSP requests to one Tomcat
context and all "/mywebapp" requests to another.

I guess I'll try using symbolic links... but it's been my experience
that many server apps consider it dangerous to follow symlinks and just
ignore them. So, we'll see if Tomcat does....

- Joe

 

[Chris Smith]

I'm using IntelliJ IDEA to develop some servlets and JSP's, and it
seems to want to put the compiled classes into an "exploded" directory.
So, where my project home is, say "$PROJHOME", I get an arrangement
like:

$PROJHOME/ <- JSP's get put here
$PROJHOME/WEB-INF <- This gets a single web.xml file, and that's it
$PROJHOME/exploded/WEB-INF <- This gets an exact duplicate of the
previous web.xml
$PROJHOME/exploded/WEB-INF/classes <- compiled code goes here

Although IDEA claims to be able to launch a private version of Tomcat
which handles all of this somehow, Tomcat crashes whenever I try to
launch it from IDEA. So, I'm stuck with having to run Tomcat externally
and have it look where IDEA is dumping the files.

The upshot of this is that I can either tell Tomcat that "$PROJHOME/"
is my approot (where it would find the JSP's) or that
"$PROJHOME/exploded" is (where it would find my servlets). Fortunately,
I don't have any JSP's in the project yet... but I'd like to start
incorporating them, but I'll write it off as a lost cause if I can't
remedy this easily.

I don't use IDEA and I don't know this for sure, but I'm willing to bet
that IntelliJ would copy your JSP files into "exploded" as well. You
should then use Tomcat's server.xml to add $PROJHOME/exploded as the
path for the context.