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

install apache tomcat on your server, use a sql database and use json for communication. For the rest: Do you know google? Its a nice search engine. You find it at google.com

I like this book for beginning with servlets / tomcat:

http://www.amazon.de/Head-First-Servlets-Bryan-Basham/dp/0596516681/ref=sr_1_2?ie=UTF8&qid=1353091543&sr=8-2

Head First Servlets and JSP covers the topic very comprehensively and gently. The 2nd edition was published in 2008 and AFAIK there have been little or no changes to the JSP spec since then.

Although this book covers both Servlets and JSPs, in most environments where JSPs are being used, Servlets (or something similar like Struts actions) are also used. Because JSPs are Servlets at runtime, it could be argued that understanding Servlets is a pre-requisite for understanding JSPs.

I'm supposing here that you have a good understand of java programming.

Fisrtly, I think you should understand java for web. I recommend this book:

Head First Servlets and JSP http://www.amazon.com/Head-First-Servlets-JSP-Certified/dp/0596516681/

Then you can learn web services with java:

Java Web Services: Up and Running http://www.amazon.com/Java-Web-Services-Up-Running/dp/1449365116

Of course, there are many tutorials over the internet as well, but books give you a lot of background information.

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.

Example:

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
                        http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
    version="3.0">

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

    <!-- This is a context init parameter -->
    <context-param>
        <param-name>email</param-name>
        <param-value>admin@example.com</param-value>
    </context-param>

    <servlet>
        <servlet-name>Info Servlet</servlet-name>
        <servlet-class>com.example.InfoServlet</servlet-class>
        <!-- This is a servlet init parameter -->
        <init-param>
            <param-name>name</param-name>
            <param-value>John Doe</param-value>
        </init-param>
    </servlet>
    <servlet-mapping>
        <servlet-name>Info Servlet</servlet-name>
        <url-pattern>/test/ShowInfo.do</url-pattern>
    </servlet-mapping>

</web-app>

• Accessing context init parameter in a servlet:
  getServletContext().getInitParameter(“email”);
• Accessing servlet init parameter in a servlet for which it was defined in the deployment descriptor:
  getServletConfig().getInitParameter("name");

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.

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.

• Difference between include directive and include action in JSP

• JSP tricks to make templating easier

• Very informative and easy to understand tutorial from coreservlet.com with beautiful explanations that include <jsp:include> VS. <%@ include %> comparison table:
  Including Files and Applets in JSP Pages

• Another nice tutorial from coreservlets.com related to tag libraries and tag files:
  Creating Custom JSP Tag Libraries: The Basics

• The official Java EE 5 Tutorial with examples:
  Encapsulating Reusable Content Using Tag Files.

• This page from the official Java EE 5 tutorial should give you even more understanding:
  Reusing Content in JSP Pages.

• This excerpt from the book "Pro JSP 2" also discuses why do you need a Tag File instead of using static include:
  Reusing Content with Tag Files

Conclusion

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.

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):

• Murach Servlets and JSP
• Head First Servlets & JSP
• Core Servlets and JSP

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

• Beginning and intermediate JSP/Servlet tutorials
• Advanced JSP/Servlet tutorials
• Core Servlets and JSP ebook

See also:

• Java EE web development, what skills do I need?
• Servlet lifecycle and multithreading

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.

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

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.

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">
    <head>
        <title>SO question 2690671</title>
    </head>
    <body>
        <form>
            Cols: 
            <select name="cols">
                <option>3</option><option>4</option><option>6</option>
            </select><br>
            Rows:
            <select name="rows">
                <option>3</option><option>4</option><option>6</option>
            </select><br>
            <input type="submit">
        </form>
        <c:if test="${param.cols > 0 && param.rows > 0}">
            <p>Here is a table with ${param.cols} cols and ${param.rows} rows.
            <table>
                <c:forEach begin="1" end="${param.rows}">
                    <tr>
                        <c:forEach begin="1" end="${param.cols}">
                            <td>cell</td>
                        </c:forEach>
                    </tr>
                </c:forEach>
            </table>
        </c:if>
    </body>
</html>

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.