We had all our URL's (except our login form) stored in the web.xml file as
input parameters to out servlets, so I created a new context,altered the
URL's to include the context name, and started the tomcat server. It now
appears to be working fine under the new context.
I noticed that the defaultServlet, etc. were being loaded prior to my new
context, and I am able to run with the new context only defining my
servlets. Are the default servlets, and mime-types, etc being loaded
through an XML file, or by some other means?
Thanks,
Helge Osmundsen
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 04, 2000 2:19 PM
To: [EMAIL PROTECTED]
Subject: Re: Tomcat 3.2 - Default web.xml not being read
We have been running tomcat 3.1 for a while, and just downloaded 3.2 final
to our test Unix server. We have our servlets defined in the home +
"/conf/web.xml" file. This has not changed. 3.1 still works fine. 3.2
does not load the servlets in the default context, and does not load the
default web.xml file. I turned debugging to level "30".
I added one to the servlets to the home + "/webapps/examples/web.xml", and
the servlet now loads (it shows in the displays + I can access) , but only
under the "examples" container (or directory). Is there something
different
I need to do to have the default web.xml file to be read/processed?
web.xml is no longer used/supported in 3.2.
The main reason - the code that merged the "default" web.xml with the
application web.xml was very bad, slow and hard to maintain. It was
commented out until someone wants to fix it.
A second reason - probably more important from a user perspective - is
that it direct user to un-portable web applications. If you want your
application to be portable ( i.e. to be able to take it and deploy it on a
different container ) you need to have all the mappings, etc in your
application web.xml file. As long as you use the "default" web.xml your
application can't be portable.
In addition, there was no rule about the interaction between setting in
the application web.xml and the server web.xml - it just happen based on
hacks in the code.
A third reason is the fact that tomcat already has a configuration file -
server.xml, and it's confusing to use 2 different styles, and server.xml
has far more options on setting the server.
To add another argument here, one idea in tomcat is that the server
shouldn't depend on any particular cofiguration file format - it should be
possible to embed tomcat in an application using JNDI or windows registry
for configuration, and tomcat shouldn't require any special configuration
file. Web.xml was a big obstacle for this. ( if you look at EmbededTomcat,
it is possible to start tomcat without any configuration file at all,
using only API calls. If we would use web.xml then this will become
much harder or impossible )
Costin
