tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Eggers <>
Subject Re: Context.xml ignored.
Date Sun, 03 Mar 2013 17:42:22 GMT
On 3/3/2013 8:22 AM, James Green wrote:
> On 3 March 2013 15:51, Mark Thomas <> wrote:
>> On 03/03/2013 15:29, James Green wrote:
>>> On 3 March 2013 14:32, Mark Thomas <> wrote:
>>>> On 03/03/2013 14:24, James Green wrote:
>>>>> On 3 March 2013 11:34, Konstantin Kolinko <>
>>>> wrote:
>>>>>> 2013/3/3 James Green <>:
>>>>> So now I have a war deployed. Easy enough. Now to set the URL path.
>>>> There a
>>>>> lot of talk about Context Descriptors on that page, and at the top one
>>>>> seems to be read from webapps/[my-war-file]/META-INF/context.xml.
>>>> Perfect,
>>>>> but what goes in it?
>>>>> Elsewhere, I find Config, and in there we find Context. Aha! Parallel
>>>>> Deployment? Nope don't want that. Naming? I read that several times,
>> and
>>>> I
>>>>> have no idea still what is trying to be expressed. Does it even apply
>> to
>>>>> me? Not sure, let's move on
>>>> Stop here. The naming section is exactly the bit you need to understand.
>>>> I'm sure there is scope to improve the docs so if you explain where you
>>>> start to get lost we can look at improving the wording / adding
>>>> additional explanation as required.
>>>>   <>
>>> Diving straight into the Naming section then we describe a relationship
>>> involving these elements:
>>> - Context Name
>>> - Context Version
>>> - Context Path
>>> - Base file name
>>> Is the base file name the name of the war file built?
>>> Are the context elements name, version and path, supposed to come from
>> the
>>> context.xml file? Other than path, they are not listed in the attributes
>>> further down the page.
>> OK. Lets address the above. Once you are happy you understand what is
>> going on, I'll suggest an update to the docs that you can review.
>> Context path is as defined in the Servlet specification.
>> Context name is the unique identifier for a context within a host. If no
>> version is specified (none is needed unless parallel deployment is being
>> used) then context name is identical the the context path. If a version
>> is specified then ##ContextVersion is appended to the context path to
>> create the context name.
>> Context version is a version identifier that is used under parallel
>> deployment when multiple versions of the same application are deployed
>> with the same context path.
>> Base file name is the common part of the file named used for the WAR
>> (baseFileName.war) directory (baseFileName) or context.xml file
>> (baseFileName.xml) from which the application is deployed.
>> Context name is derived from base file name by:
>> - replacing any single '#' characters with '/'
>> - if the base file name starts with "ROOT", replacing "ROOT" with the
>> empty string
>> - if the base file name does not start with "ROOT", pre-pending a
>> leading '/'
>> The base file name controls the context path. If you want to change the
>> context path, the simplest solution is to change the base file name.
> Fine. But this is not as described on this page:
> Here, again, i'm told that META-INF/context.xml provides the context
> descriptor. It also states that dropping the war into webapps/ will consume
> the web application.
> Again, in the FAQ, there holds a reference to this file for deployment
> purposes.
> I seem not to be alone in thinking this is the case. A simple Google
> revealed:
> If you are suggesting that META-INF/context.xml is not used for the
> purposes of defining the context path, then quite a few references need to
> be removed. If you are not suggesting this, then I am still missing the
> reason why my context.xml does not deploy the application to the path I
> supply.
> Thanks for providing your time on this matter so far.
> James

Here are my thoughts as to how all this works. I use NetBeans, but I'm 
more of a systems person than a developer, so your mileage may vary.

I've used UNIX conventions below for environment variables since you've 
not stated what your development platform runs on.

If you've not changed the default Tomcat server.xml, then the following 
is true:

[engine-name]  = Catalina
[host-name]    = localhost
[context-name] = name of the context
appBase        = $CATALINA_BASE/webapps (%CATALINA_BASE%\webapps)

$CATALINA_BASE is where Tomcat is being run from. If you have a single 
Tomcat (see RUNNING.txt for other configurations), then most likely this 
value is the same as $CATALINA_HOME (where Tomcat is installed).

NetBeans runs a servlet project not by copying a WAR file to the appBase 
directory, but by creating a [project-name].xml context file and copying 
that to $CATALINA_BASE/conf/[engine-name]/[host-name].

I think the steps are as follows:

1. Read a project's [project-name]web/META-INF/context.xml file if any
2. Merge that information with and add the following attributes:
    a. antiJARLocking="true"
    b. docBase="[absolute-path-to-project]/build/web"
    c. path="[context-path"]
3. Copy the resulting [project-name].xml to

I'm a little fuzzy on the [project-name].xml name, since I've only ever 
put together projects with names that reflect my actual desired context.

In my opinion, NetBeans should read the project properties and use the 
Context Path property (in the Run category of Properties) to name the 
context file. This would remove the need for 2.c above (which is almost 
always incorrect).

When you build a WAR for deployment, the default WAR file name reflects 
the project name. This means that when you drop the WAR file into a 
Tomcat, the resulting context may be different than what you intended it 
to be.

You have several choices.

1. Run the WAR file (or exploded directory) outside of the Host's 
appBase and modify server.xml

This is not recommended, so I'm not detailing the configuration changes 
and deployment steps you need to do this. It's documented on the Tomcat 
web site, but discouraged.

2. Run the WAR file (or exploded directory) outside of the Host's 
appBase and create


You do this by creating your WAR file (or exploded directory), and then 
copying a suitably crafted [context-name].xml to the directory mentioned 

This is sort of, almost exactly like, but not quite what NetBeans does 
(apologies to Douglas Adams). Again, see my explanation above as to what 
I think NetBeans does.

3. Rename your WAR file to be [desired-context-name].war and drop it 
into the right appBase.

This is the easiest of the three cases to accomplish.

If you're using NetBeans and its standard build script, you can change 
the name of the built war in Properties->Build->Packaging. The field is 
(obviously enough) called WAR File:.

If you're using Maven as your build environment, you can use the 
finalName element to achieve the same thing. I do this since otherwise 
Maven will append the version element value to the WAR file name. In 
most cases this is not what I want.

Hopefully this is helpful.

. . . . just my 2 cents

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message