JavaBeat » Apache Tomcat

Tomcat Interview Questions

krishnas — Thu, 05 Aug 2010 00:42:03 +0000

Tomcat Interview Questions – 1

How do you create multiple virtual hosts?

If you want tomcat to accept requests for different hosts e.g., www.myhostname.com then you must 0. create ${catalina.home}/www/appBase , ${catalina.home}/www/deploy, and ${catalina.home}/conf/Catalina/www.myhostname.com

1. add a host entry in the server.xml file

2. Create the the following file under conf/Catalina/www.myhostname.com/ROOT.xml

Add any parameters specific to this hosts webapp to this context file

3. put your war file in ${catalina.home}/www/deploy

When tomcat starts, it finds the host entry, then looks for any context files and will start any apps with a context

To add more sites just repeat and rinse, all webapps can share the same war file location and appbase

How will you load properties file?

* Use a ResourceBundle. See the Java docs for the specifics of how the ResourceBundle class works. Using this method, the properties file must go into the WEB-INF/classes directory or in a jar file contained in the WEB-INF/lib directory.

* Another way is to use the method getResourceAsStream() from the ServletContext class. This allows you update the file without having to reload the webapp as required by the first method. Here is an example code snippet, without any error trapping:

// Assuming you are in a Servlet extending HttpServlet
                    // This will look for a file called "/more/cowbell.properties" relative
                    // to your servlet Root Context
                   InputStream is = getServletContext().getResourceAsStream("/more/cowbell.properties");
                   Properties  p  = new Properties();
                   p.load(is);
                 is.close();

Can I set Java system properties differently for each webapp?

No. If you can edit Tomcat’s startup scripts, you can add “-D” options to Java. But there is no way to add such properties in web.xml or the webapp’s context.

How do I configure Tomcat to work with IIS and NTLM?

Follow the standard instructions for when the isapi_redirector.dll Configure IIS to use “integrated windows security”

In server.xml, make sure you disable tomcat authentication:

How can I access members of a custom Realm or Principal?

When you create a custom subclass of RealmBase or GenericPrincipal and attempt to use those classes in your webapp code, you’ll probably have problems with ClassCastException. This is because the instance returned by request.getUserPrincipal() is of a class loaded by the server’s classloader, and you are trying to access it through you webapp’s classloader. While the classes maybe otherwise exactly the same, different (sibling) classloaders makes them different classes.

This assumes you created a My“Principal class, and put in Tomcat’s server/classes (or lib) directory, as well as in your webapp’s webinf/classes (or lib) directory. Normally, you would put custom realm and principal classes in the server directory because they depend on other classes there.

Here’s what you would like to do, but it throws ClassCastException:

1 2	MyPrincipal p = request.getUserPrincipal(); String emailAddress = p.getEmailAddress();

Here are 4 ways you might get around the classloader boundary:

1) Reflection

1 2	Principal p = request.getUserPrincipal(); String emailAddress = p.getClass().getMethod("getEmailAddress", null).invoke(p, null);

2) Move classes to a common classloader

You could put your custom classes in a classloader that is common to both the server and your webapp – e.g., either the “common” or bootstrap classloaders. To do this, however, you would also need to move the classes that your custom classes depend on up to the common classloader, and that seems like a bad idea, because there a many of them and they a core server classes.

3) Common Interfaces

Rather than move the implementing custom classes up, you could define interfaces for your customs classes, and put the interfaces in the common directory. You’re code would look like this:

public interface MyPrincipalInterface extends java.security.Principal {
  public String getEmailAddress();
}
 
public class MyPrincipal implements MyPrincipalInterface {
...
  public String getEmailAddress() {
    return emailAddress;
  }
}
 
public class MyServlet implements Servlet {
  protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
    MyPrincipalInterface p = (MyPrincipalInterface)request.getUserPrincipal();
    String emailAddress = p.getEmailAddress();
...
}

Notice that this method gives you pretty much the webapp code you wanted in the first place

4) Serializing / Deserializing

You might want to try serializing the response of ‘request.getUserPrincipal()’ and deserialize it to an instance of [webapp]MyPrincipal.

How do I override the default home page loaded by Tomcat?

After successfully installing Tomcat, you usually test it by loading http://localhost:8080 . The contents of that page are compiled into the index_jsp servlet. The page even warns against modifying the index.jsp files for this reason. Luckily, it is quite easy to override that page. Inside $TOMCAT_HOME/conf/web.xml there is a section called and it looks like this:


        index.html
        index.htm
        index.jsp

The default servlet attempts to load the index.* files in the order listed. You may easily override the index.jsp file by creating an index.html file at $TOMCAT_HOME/webapps/ROOT. It’s somewhat common for that file to contain a new static home page or a redirect to a servlet’s main page. A redirect would look
like:

This change takes effect immediately and does not require a restart of Tomcat.

How do I enable Server Side Includes (SSI)?

Two things have to be done for tomcat to aknowledge SSI scripts:

1. Rename $CATALINA_BASE/server/lib/servlets-ssi.renametojar to $CATALINA_BASE/server/lib/servlets-ssi.jar.

2. Uncomment the section of web.xml found in $CATALINA_BASE/conf/web.xml that deals with SSI. it looks like this when it is uncommented:


        ssi
        
          org.apache.catalina.ssi.SSIServlet
        
        
          buffered
          1
        
        
          debug
          0
        
        
          expires
          666
        
        
          isVirtualWebappRelative
          0
        
        4

How do I use DataSources with Tomcat?

When developing J2EE web applications, the task of database connection management can be daunting. Best practice involves using a J2EE DataSource to provide connection pooling, but configuring DataSources in web application servers and connecting your application to them is often a cumbersome process and poorly documented.

The usual procedure requires the application developer to set up a DataSource in the web application server, specifying the driver class, JDBC URL (connect string), username, password, and various pooling options. Then, the developer must reference the DataSource in his application’s web.xml configuration file, and then access it properly in his servlet or JSP. Particularly during
development, setting all of this up is tedious and error-prone.

With Tomcat 5.5, the process is vastly simplified. Tomcat allows you to configure DataSources for your J2EE web application in a context.xml file that is stored in your web application project. You don’t have to mess with configuring the DataSource separately in the Tomcat server.xml, or referencing it in your application’s web.xml file. Here’s how:

Install the JDBC Driver

Install the .jar file(s) containing the JDBC driver in Tomcat’s common/lib folder. You do not need to put them in your application’s WEB-INF/lib folder. When working with J2EE DataSources, the web application server manages connections for your application.

Create META-INF/context.xml

In the root of your web app directory structure, create a folder named META-INF (all caps). Inside that folder, create a file named context.xml that contains a Resource like this:

This example shows how to configure a DataSource for a SQL Server database named mytest located on the development machine. Simply edit the Resource name, driverClassName, username, password, and url to provide values appropriate for your JDBC driver.

Access the DataSource in Your Application

From a Servlet

Here’s how you might access the data in a servlet:

InitialContext ic = new InitialContext();
  DataSource ds = (DataSource) ic.lookup("java:comp/env/jdbc/WallyDB");
  Connection c = ds.getConnection();
  ...
  c.close();

Notice that, when doing the DataSource lookup, you must prefix the JNDI name of the resource with java:comp/env/

Tomcat 6.0 Servlet Container Overview

krishnas — Sun, 20 Jun 2010 00:10:52 +0000

Connect to us ( @twitter | @facebook )

Tomcat 6.0 Developer’s Guide

Current books on Tomcat are primarily focused on the application deployer
or administrator. As a result, they invariably focus on the issues related to
managing a Tomcat installation, configuring the runtime environment, and on
deploying web applications.

On the other hand, while books on servlet programming are targeted at Java web
developers, they often provide a container-agnostic view of the servlet specification.
Tomcat is often a bit player in these books and has very few speaking lines.

This book fills the void between these two approaches.

It will take you on a guided tour of a living implementation of an industrial-strength
servlet container.

Along the way, you will learn how various elements of the Servlet 2.5 specification as
well as how the HTTP RFCs are implemented.

By the end of your journey, you will have acquired specialist grade skills in a range of
technologies that contribute to the arena of Java server-side development.

This book intended to provide Tomcat administrators, deployers, and developers an
introduction into the internal workings of the Tomcat servlet container.

At the same time, it provides Java web programmers with a deep appreciation of the
Servlet APiby exploring its reference implementation—the Tomcat container.

While this book provides you with the conceptual background of all that is necessary to
take your skills to the next level, it assumes that the reader has a general understanding of
the Java programming language and Java web programming.

What This Book Covers

Chapter 1—Introduction to Tomcat introduces you to the Tomcat container and provides
you with the tools necessary to begin to take it apart. The key objective of this chapter is
to allow you to make a current source distribution of Tomcat active in a development
environment (Eclipse Galileo) so that you can trace the path that a request takes through
the container’s code.

Chapter 2—Servlet APiOverview provides the prerequisite information necessary to
navigate the remainder of the book. It describes the Java Enterprise Edition Platform, the
HTTP protocol, and the Servlet API, and serves as a refresher for those who are already
familiar with Java EE web development.

Chapter 3—Servlet Container Overview introduces the reader to the Tomcat container.
This is the 10,000 foot overview of the container that provides a backdrop to the chapters
that follow. All the components of Tomcat are described with just enough detail, so as
not to overwhelm the reader with too much information, too early in the process.

Chapter 4—Starting up Tomcat takes a closer look at the startup process for Tomcat. This
is also where you will be first introduced to the Apache Digester project—a key
component that we will revisit in later chapters. The chapter ends with an example that
demonstrates how a web application can be deployed to a dissected Tomcat container
living within an Integrated Development Environment.

Chapter 5—The Server and Service Components discusses the Server component and
investigates one of its key services—an implementation of the Java Naming and
Directory Interface (JNDI) API. We are also introduced to the Lifecycle interface
that almost every component within Tomcat implements in order to participate in a
standardized event based listener mechanism. To show JNDiin action, our example
considers connecting to a MySQL database to retrieve data.

Chapter 6—The Connector Component introduces our first Tomcat luminary, the Coyote
Connector. We take a closer look at the standard Java I/O implementation of an HTTP
connector. In this chapter, we get a closer look at socket programming, advanced
elements of the HTTP protocol, and the internals of the request processing mechanism.

Chapter 7—The Engine Component describes the first request processing ‘Container’
within Tomcat and gives us an inkling of things to come. We are also introduced to the
Pipeline and its Valves, which are the standard request processing mechanism for
Tomcat components.

Chapter 8—The Host Component discusses the Tomcat implementation of a Virtual Host.
This is the key component responsible for the deployment of web application contexts, as
well as for the error page mechanism.

Chapter 9—The Context Component is at the central core of this book. You get an upclose-
and-personal look at how a Context is configured, how it accesses its resources,
and how it implements its class loading magic.

Chapter 10—The Wrapper Component takes us to the workhorse of the Tomcat
component hierarchy. This component wraps an actual servlet, and as a result is close
to a web developer’s heart. In addition to reviewing the mapping rules dictated by the
Servlet API, we also look at the implementation of servlet filters and the request
dispatcher mechanism.

Chapter 11—The Session Component discusses how sessions are implemented in Tomcat
to enable stateful behavior over the stateless HTTP protocol. In addition to looking at
some core concepts, such as Java serialization and entropy gathering for random number
generation, we look at the standard memory based session implementation, as well as an
implementation that uses files to persist sessions.

Servlet Container Overview

In the last chapter, we noted that the Java Enterprise Edition can be considered to be
nothing more than a set of specifications, or interfaces, for which service providers
are required to provide implementations.

While it is the actual implementation that does all the work, these specifications
ensure that each implementation can assume that all its other collaborating
pieces work as described by their interfaces. In theory, this allows complex
software platforms (such as application servers) to be assembled from
constituent implementations, each of which is sourced from a different vendor.

In practice, it is highly unlikely that you will interface an EJB container from
WebSphere and a JMS implementation from WebLogic, with the Tomcat servlet
container from the Apache foundation, but it is at least theoretically possible.

Note that the term ‘interface’, as it is used here, also encompasses abstract classes.
The specification’s APimight provide a template implementation whose operations
are defined in terms of some basic set of primitives that are kept abstract for the
service provider to implement. For instance, in Chapter 2, we noted that the servlet
hierarchy is made up of the Servlet interface, and the GenericServlet and
HttpServlet abstract classes within the javax.servlet package.

A service provider is required to make available concrete implementations of
these interfaces and abstract classes. For example, the HttpSession interface
is implemented by Tomcat in the form of org.apache.catalina.session.
StandardSession.

Let’s return to the image of the Tomcat container that we saw in Chapter 1.

As was stated in Chapter 1, the objective of this book is to cover the primary request
processing components that are present in this image. Advanced topics, such as
clustering and security, are shown as shaded in this image and are not covered.

In this image, the ‘+’ symbol after the Service, Host, Context, and Wrapper
instances indicate that there can be one or more of these elements. For instance, a
Service may have a single Engine, but an Engine can contain one or more Hosts.
In addition, the whirling circle represents a pool of request processor threads.

In this chapter, we will fl y over the architecture of Tomcat from a 10,000-foot
perspective taking in the sights as we go.

Component taxonomy

Tomcat’s architecture follows the construction of a Matrushka doll from Russia. In
other words, it is all about containment where one entity contains another, and that
entity in turn contains yet another.

In Tomcat, a ‘container’ is a generic term that refers to any component that can
contain another, such as a Server, Service, Engine, Host, or Context.

Of these, the Server and Service components are special containers, designated as
Top Level Elements as they represent aspects of the running Tomcat instance. All
the other Tomcat components are subordinate to these top level elements.

The Engine, Host, and Context components are officially termed Containers, and
refer to components that process incoming requests and generate an appropriate
outgoing response.

Nested Components can be thought of as sub-elements that can be nested inside
either Top Level Elements or other Containers to configure how they function.
Examples of n ested components include the Valve, which represents a reusable unit
of work; the Pipeline, which represents a chain of Valves strung together; and a
Realm which helps set up container-managed security for a particular container.

Other nested components include the Loader which is used to enforce the
specification’s guidelines for servlet class loading; th e Manager that supports session
management for each web application; the R esources component that represents the
web application’s static resources and a mechanism to access these resources; and
the Listener th at allows you to insert custom processing at important points in a
container’s life cycle, such as when a component is being started or stopped.



	Not all nested components can be nested within every container.

A final major component, which falls into its own category, is the Connector. It
represents the connection end point that an external client (such as a web browser)
can use to connect to the Tomcat container.

Before we go on to examine these components, let’s take a quick look at how they are
organized structurally.

Note that this diagram only shows the key properties of each container.

When Tomcat is started, the Java Virtual Machine (JVM) instance in which it
runs will contain a singleton Server top level element, which represents the entire
Tomcat server. A Server will usually containjust one Service object, which is a
structural element that combines one or more Connectors (for example, an HTTP
and an HTTPS connector) that funnel incoming requests through to a single
Catalina servlet Engine.

The Engine represents the core request processing code within Tomcat and supports
the definition of multiple Virtual Hosts within it. A virtual host allows a single
running Tomcat engine to make it seem to the outside world that there are multiple
separate domains (for example, www.my-site.com and www.your-site.com) being
hosted on a single machine.

Each virtual host can, in turn, support multiple web applications known as
Contexts that are deployed to it. A context is represented using the web application
format specified by the servlet specification, either as a single compressed WAR
(Web Application Archive) file or as an uncompressed directory. In addition, a
context is configured using a web.xml file, as defined by the servlet specification.

A context can, in turn, contain multiple servlets that are deployed into it, each of
which is wrapped in a Wrapper component.

The Server, Service, Connector, Engine, Host, and Context elements that
will be present in a particular running Tomcat instance are configured using the
server.xml configuration file.



	Things are a bit more complicated than this. However, we’ll defer the

	complexity until later chapters when we deal with each component in a

	lot more detail.

Architectural benefits

This architecture has a couple of useful features. It not only makes it easy to manage
component life cycles (each component manages the life cycle notifications for its
children), but also to dynamically assemble a running Tomcat server instance that
is based on the information that has been read from configuration files at startup.
In particular, the server.xml file is parsed at startup, and its contents are used to
instantiate and configure the defined elements, which are then assembled into a
running Tomcat instance.



	The server.xml file is read only once, and edits to it will not be picked

	up until Tomcat is restarted.

This architecture also eases the configuration burden by allowing child containers
to inherit the configuration of their parent containers. For instance, a Realm defines
a data store that can be used for authentication and authorization of users who
are attempting to access protected resources within a web application. For ease of
configuration, a realm that is defined for an engine applies to all its children hosts
and contexts. At the same time, a particular child, such as a given context, may
override its inherited realm by specifying its own realm to be used in place of its
parent’s realm.