blogger templates blogger widgets
This is part of a list of blog posts.
To browse the contents go to

Tomcat and context.xml

We have web.xml. Why then context.xml? Wait... there is server.xml too.

Let me take the approach used in tomcat's documentation itself.

What defines a web application?

Servlet Specification (version 2.2 or later) states that anything that follows the folder structure as specified in the spec and comes (optional) bundled as Web Application Archive (WAR) file.

For every web application, a context is defined by the container.

For eg:
When I deployed a web application project named "Sample" on tomcat (using eclipse).
I see

<context 
docBase="Sample" 
path="/Sample" 
reloadable="true" 
source="org.eclipse.jst.jee.server:Sample"
/>
in server.xml.


By default, the context path takes the same values as the project name. So to hit the servlet we have been using the following URL
http://localhost:8081/Sample/SampleServlet
which is of the form
http://{host}:{port}/{context path to application}/{resource}

The container checks the incoming HTTP request and maps the request URI against the context path of each defined context.
For eg: Changing it to

<context 
docBase="Sample" 
path="/MyApp" 
reloadable="true" 
source="org.eclipse.jst.jee.server:Sample"
/>
and restarting the server. Now, http://localhost:8081/MyApp/SampleServlet works.

You may define as many Context elements as you wish.


<context 
docBase="Sample" 
path="/Sample" 
reloadable="true" 
source="org.eclipse.jst.jee.server:Sample"
/>
<context 
docBase="Sample" 
path="/SampleApp" 
reloadable="true" 
source="org.eclipse.jst.jee.server:Sample"
/>

Note: Changing it using the project settings of Eclipse didn't work for me. Not sure why.


It is NOT recommended to place elements directly in the server.xml file.

This is because it makes modifying the Context configuration more invasive since the main conf/server.xml file cannot be reloaded without restarting Tomcat.

Individual Context elements may be explicitly defined:

  • In an individual file at /META-INF/context.xml inside the application files.
  • In individual files (with a ".xml" extension) in the $CATALINA_BASE/conf/[enginename]/[hostname]/ directory. The context path and version will be derived from the base name of the file (the file name less the .xml extension). This file will always take precedence over any context.xml file packaged in the web application's META-INF directory.
  • Inside a Host element in the main conf/server.xml.

Let's experiment.

Create context.xml in WebContent/WEB-INF.
Add the same entry we saw in server.xml. (remove from server.xml)

<?xml version="1.0" encoding="UTF-8"?>
<context docBase="Sample" path="/Sample" reloadable="true"
 source="org.eclipse.jst.jee.server:Sample" />
Restart server. (No more restarts when you change contexts)

You can configure named values that will be made visible to the web application as servlet context initialization parameters by nesting elements inside this element.

For example, In my server.xml,


<context 
 docBase="Sample" 
 path="/Sample" 
 reloadable="true" 
 source="org.eclipse.jst.jee.server:Sample"
>
<parameter name="foo" value="bar" override="false"/>
</Context>

And then in my servlet code,

System.out.println(getServletContext().getInitParameter("foo"));

This is equivalent to the inclusion of the following element in the web application deployment descriptor (/WEB-INF/web.xml)


<context-param>
<param-name>foo</param-name><param-value>bar</param-value>
</context-param>

Only use of these seems to define a default value and control permission of the web application to override it.

You can configure named values that will be made visible to the web application as environment entry resources, by nesting entries inside this element.
For example:

<context 
     docBase="Sample" 
     path="/Sample" 
     reloadable="true" 
     source="org.eclipse.jst.jee.server:Sample"
    >
<environment name="isConnected" value="true" type="java.lang.Boolean" override="false"/>
</Context>

And in servlet (like always):

Context initCxt =  new InitialContext();
Boolean isConn =  (Boolean)initCxt.lookup("java:comp/env/isConnected");
System.out.println(isConn.toString());

Since this is not a tutorial on tomcat and rather on JNDI, so I wouldn't go into the details of what can be done inside context. Check out tomcat-doc

Continue reading: Using JNDI lookup for DataSource using resource-ref (tomcat)

No comments:

Post a Comment