Head First Servlets and JSP: Passing the Sun Certified Web Component Developer Exam

Author: Bryan Basham, Kathy Sierra, Bert Bates
All Stack Overflow 17
This Year Stack Overflow 1
This Month Stack Overflow 1

Head First Servlets and JSP: Passing the Sun Certified Web Component Developer Exam


Review Date:


by anonymous   2019-01-13

The answer is - Yes, you can.

OK, besides the JB Nizet's comment here are a few suggestions.

1) Have you added your init parameters while the Web Container / Application Server was running?

Quote from "Head First Servlets & JSP: Passing the Sun Certified Web Component Developer Exam":

The servlet init parameters are read only ONCE - when the Container initializes the servlet. ...
When the Container makes a servlet, it reads the DD and creates the name/value pairs for the ServletConfig. The Container never reads the init parameters again! Once the parameters are in the ServletConfig, they won’t be read again until/unless you redeploy the servlet.

2) There are two types of init parameters available. Another quote from "Head First Servlets and JSP" (emphasis mine):

There are context init parameters (defined in <context-param> element) and servlet init parameters (defined in <init-param> element). They are both referred to as init parameters, although defined in different elements.

  • Context init parameters are available to any servlet or JSP that are part of the current web app.

  • Servlet init parameters are available to only the servlet for which the <init-param> was configured.

  • Context init parameters are defined within the <web-app> element.

  • Servlet init parameters are defined within the <servlet> element for each specific servlet.


<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"

    <display-name>Servlet testing app</display-name>

    <!-- This is a context init parameter -->

        <servlet-name>Info Servlet</servlet-name>
        <!-- This is a servlet init parameter -->
            <param-value>John Doe</param-value>
        <servlet-name>Info Servlet</servlet-name>


  • Accessing context init parameter in a servlet:
  • Accessing servlet init parameter in a servlet for which it was defined in the deployment descriptor:

An alternative way of getting servlet init parameter is using a method defined in the abstract class GenericServlet:
public String getInitParameter(String name);
This method is supplied for convenience. It gets the value of the named parameter from the servlet's ServletConfig object.

And there is also Enumeration<String> getInitParameterNames() method for both ServletContext and ServletConfig to get all init parameters.

by anonymous   2017-08-20

There are several mechanisms for reusing content in a JSP page.

The following 4 mechanisms to include content in JSP can be categorized as direct reuse:
(for the first 3 mechanisms quoting from "Head First Servlets and JSP")

1) The include directive:

<%@ include file="header.html" %>

Static: adds the content from the value of the file attribute to the current page at translation time. The directive was originally intended for static layout templates, like HTML headers.

2) The <jsp:include> standard action:

<jsp:include page="header.jsp" />

Dynamic: adds the content from the value of the page attribute to the current page at request time. Was intended more for dynamic content coming from JSPs.

3) The <c:import> JSTL tag:

<c:import url=”http://www.example.com/foo/bar.html” />

Dynamic: adds the content from the value of the URL attribute to the current page, at request time. It works a lot like <jsp:include>, but it’s more powerful and flexible: unlike the other two includes, the <c:import> url can be from outside the web Container!

4) Preludes and codas:

Static: preludes and codas can be applied only to the beginnings and ends of pages.
You can implicitly include preludes (also called headers) and codas (also called footers) for a group of JSP pages by adding <include-prelude> and <include-coda> elements respectively within a <jsp-property-group> element in the Web application web.xml deployment descriptor. Read more here:
Configuring Implicit Includes at the Beginning and End of JSPs
Defining implicit includes

Tag File is an indirect method of content reuse, the way of encapsulating reusable content. A Tag File is a source file that contains a fragment of JSP code that is reusable as a custom tag.

The PURPOSE of includes and Tag Files is different.

Tag file (a concept introduced with JSP 2.0) is one of the options for creating custom tags. It's a faster and easier way to build custom tags. Custom tags, also known as tag extensions, are JSP elements that allow custom logic and output provided by other Java components to be inserted into JSP pages. The logic provided through a custom tag is implemented by a Java object known as a tag handler.

Some examples of tasks that can be performed by custom tags include operating on implicit objects, processing forms, accessing databases and other enterprise services such as email and directories, and implementing flow control.

Regarding your Edit

Maybe in your example (in your Edit), there is no difference between using direct include and a Tag File. But custom tags have a rich set of features. They can

  • Be customized by means of attributes passed from the calling page.

  • Pass variables back to the calling page.

  • Access all the objects available to JSP pages.

  • Communicate with each other. You can create and initialize a JavaBeans component, create a public EL variable that refers to that bean in one tag, and then use the bean in another tag.

  • Be nested within one another and communicate by means of private variables.

Also read this from "Pro JSP 2": Understanding JSP Custom Tags.

Useful reading.


Use the right instruments for the concrete task.

Use Tag Files as a quick and easy way of creating custom tags.

As for the including content in JSP (quote from here):

  • Use the include directive if the file changes rarely. It’s the fastest mechanism. If your container doesn’t automatically detect changes, you can force the changes to take effect by deleting the main page class file.

  • Use the include action only for content that changes often, and if which page to include cannot be decided until the main page is requested.

by anonymous   2017-08-20

Just create one yourself. Any folder which you create in Tomcat/webapps will become a standalone webapplication. You don't even need to name it explicitly /examples. You can even name it /beer. You then just have to change the URL from http://localhost:8080/examples to http://localhost:8080/beer.

That said, I think it's better to look for a more recent book than the one mentioning Tomcat 4.0 which is already over a decade old. There might be more old fashioned advices/practices in the book which really can't be done anymore nowadays (for example, cough, scriptlets). Those books are more recent (in order from newest to older):

To learn JSP/Servlets online, I can recommend the tutorials and ebook at coreservlets.com:

See also:

by anonymous   2017-08-20

I don't really understand the web.xml and context.xml files.

The web.xml file is just a configuration file which instructs the application server under each which filters/servlets to load and instantiate and on which url-patterns those should be invoked.

The context.xml is just another configuration file which instructs the application under each where the webapp is located at the local storage system and on which domain/URL context it should listen.

The appserver parses both files on startup and takes actions accordingly.

I'm not sure what constitutes a Java EE application as opposed to a generic Java web application.

It's unclear what your own definitions of "Java EE application" and "Generic Java Web application" are. To answer such a question (even though yourself), you'll need to lookup and/or redefine the definitions. But in general, there are two kinds of Java EE applications: web applications (usually to be deployed in flavor of WAR's) and enterprise applications (usually to be deployed in flavor of EAR's). The major difference is that the second involves EJB's and thus require to be run on an application which supports EJB's (e.g. Tomcat doesn't).

I can't figure out how a bean is different from an ordinary Java class (POJO?) and how that differs from an Enterprise Java Bean (EJB). These are just the first few questions I could think of, but there are many more.

Those are just terms which are been applied dependent on the purpose (and history) of the class in question. The term "POJO" is a (generally negative) term representing a Javabean which is just a value object (totally no business logic, pure bean with only getter/setter methods) and is generally a model object which is part of a "legacy" program which uses EJB/Hibernate. Some call it VO (Value Object), others call it DTO (Data Transfer Object), again others just stick to "javabeans".

What is a good way to learn how Java web applications function from the top down rather than simply how to develop an application with a specific framework? (Is there a book for this sort of thing?) Ultimately, I would like to understand Java web applications well enough to write my own framework.

Start with Head First Servlets & JSP. Read the Servlet API and try to implement one yourself. Knowledge of HTTP is however mandatory as well. Read/debug/play/hack the source of existing open source Servlet API implementations (e.g. Tomcat). Read/debug/play/hack the source of existing open source (MVC) frameworks (e.g. JSF). Try to understand how they works and then try to do it better. For the learning path ("What skills do I need?") I've posted a similar answer before here.

by anonymous   2017-08-20

I would start by taking a look at servlets and JSP. I found this book helpful when I read it: Head First Servlets and JSP

by Vinegar   2017-08-20

After reading the official tutorial. Think of getting a copy of Head First Servlet and JSP. Servlet and related techs would become handy after reading this.

by anonymous   2017-08-20

You shouldn't construct HTML in the servlet. Do it in the JSP. You can use JSTL to control the page flow in JSP page. Just drop jstl-1.2.jar in /WEB-INF/lib and declare the taglibs as per the aforelinked TLD documentation.

You can use the <c:if> or <c:choose> tag to introduce a condition in the page flow. You can use the <c:forEach> tag to iterate over an array or a collection in JSP. Your functional requirement is pretty vague, but here's a kickoff example:

<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>

<!doctype html>
<html lang="en">
        <title>SO question 2690671</title>
            <select name="cols">
            <select name="rows">
            <input type="submit">
        <c:if test="${param.cols > 0 && param.rows > 0}">
            <p>Here is a table with ${param.cols} cols and ${param.rows} rows.
                <c:forEach begin="1" end="${param.rows}">
                        <c:forEach begin="1" end="${param.cols}">

Pretty straightforward, isn't it? You actually don't need a servlet here, unless you want to preprocess the rows/cols and implement some validation/business logic. Just change the form action to the servlet URL and let the servlet forward the request to the JSP using requestdispatcher which was already explained to you in several answers before. Don't process the HTML in Servlet. There's no need to do that.

After all, you really need get yourself through some basic JSP/Servlet tutorials/books first instead of stabbing around in the dark. You can find excellent online JSP/Servlet tutorials here and you can find good books here and here. Leave your project aside and concentrate you on actually learning the stuff.