Lucy Newman has done the same for PostgreSQL, and Masako Onishi has contributed inststructions for InstantDB.

The second edition of the book uses the JSP Standard Tag Library (JSTL) actions for all database access. The data source used by the JSTL actions is configured in the web.xmlfile for the application, to make it easier to switch between databases.

I have also included a script with all SQL statements needed to create the example tables, located in WEB-INF/examples.sql. You can use this script to create the tables in a MySQL database, and it should work fine for most other database engines as well.

I want to implement your Action Object design and get confused as to what files I need to look at. Where do I find what files belong to what example?

The PBControllerServlet class corresponds to examples 14-1 through 14-3. It contains the logic for all actions as private methods.

The PBDispatcherServlet class, the Action interface, all XXXAction classes and the ActionUtils class correspond to the example described in “A More Modular Design Using Action Objects”.

<!-- Normal HTTP -->
<Connector className="org.apache.tomcat.service.PoolTcpConnector">
<Parameter name="handler"
  value="org.apache.tomcat.service.http.HttpConnectionHandler"/>
<Parameter name="port"
  value="80"/>
</Connector>

After you make this change and restart Tomcat, you can use a URL like http://localhost/ instead. Note that if you try this on a Unix/Linux system, you must start Tomcat as “root”, which may be a security risk. On Windows, however, you can use port 80 from any login account.

The only reason for running Tomcat behind IIS that I can think of is if you need to serve both JSP pages and dynamic content based on other non-Java technologies (ASP, CGI, etc). You can read more about how to use Tomcat with IIS in doc/tomcat-iis-howto.html.

<Context path="/myapp"
  docBase="C:/websites/myapp"
  crossContext="false"
  debug="0"
  reloadable="true" >
</Context>

Note, however, that the directory you specify as docBase must contain the complete web application directory structure, i.e. the WEB-INF directories as well as the JSP pages (see Chapter 2, 4 and Appendix D in the book for more info).

You need to restart Tomcat for this change to take effect.

HttpSession session = request.getSession();
String foo = (String) session.getAttribute("foo");

For more information about how to share objects between JSP pages and servlets, see Chapter 14 in the book.

A scenario when you do need to call clearBody() is in an iterating tag handler class, if you push the processed body content to the parent’s “out” in doAfterBody(), i.e. for each pass through the body. In the iteration example in my book (Chapter 16), it’s not needed since I let the evaluation of the body for each pass accumulate and process all of it after the last pass in the doEndTag() method.

2000-12-29 10:18:37 - Ctx(  ): IOException in: R(  + 
  /tomcat-power.gif + null) socket write error (code=10053)
2000-12-29 10:18:37 - Ctx(  ): IOException in: R(  + 
  /index.html + null) socket write error (code=10053)

Do I have an install problem?

Rumor has it that this problem can be fixed with the latest patches for IE, at least on some Windows platforms. You can also reduce the log level for the Tomcat server so it doesn’t print these error messages. See the Tomcat configuration documents for details.

If you use Netscape instead, you’ll notice that it behaves according to the HTTP spec, so you don’t get this message.

   <jsp:useBean id="user" class="User" />

This doesn’t work. I get a message about class User not being found. Just to test, I replaced my class name with “java.util.Date”, and then the page was accepted.

Do I have to put the class in a package?

http://java.oreilly.com/news/jsptips_1100.html

6. Using Packages for Bean Classes

When you develop a bean to be used in a JSP page, I recommend that you make it part of a named package. A Java class that does not use a package statement ends up in the so-called unnamed package. The servlet class generated from the JSP page is, however, typically assigned to a named package. If you try to refer to a class in the unnamed package from a class in a named package, Java cannot find the class unless you use an import statement to import it. In a JSP page that means you must use both a page directive to import the class, and the <jsp:useBean> action to make it available:

   <%@ page import="UserInfoBean" %>
   <jsp:useBean id="userInfo" class="UserInfoBean" />

If the bean is part of a named packed, the action is all you need:

   <jsp:useBean id="userInfo"
     class="com.mycompany.UserInfoBean" />

There are other tips in this article that you may find useful, so please read it when you get a chance.

package com.mycomp;
public class TestBean {
  private String firstName;
  private String lastName;

  public String getFirstName() {
    return firstName;
  }

  public void setFirstName(String v) {
    firstName = v;
  }

  public String getLastName() {
    return lastName;
  }

  public void setLastName(String v) {
    lastName = v;
  }
}

I have compiled it and placed the class file in the WEB-INF/classes/com/mycomp directory for the application, as described in the book.

Still, when I use a <jsp:setProperty> or <jsp:getProperty> action and specify the property names FirstName or LastName, I get a compilation error for the page like this:

Error: 500 Location: /test/jsp/test.jsp 
Internal Servlet Error: org.apache.jasper.JasperException: 
Cannot find any information on property 'FirstName' 
  in a bean of type 'com.mycomp.TestBean'.

What’s going on here?

getFirstName()/setFirstName()
getLastName()/setLastName()

correspond to properties named “firstName” and “lastName”. The property name is the method name minus the get/set prefix, with the first character changed from upper to lower case.

That’s why the container can’t find a property named “FirstName”, since it starts with an uppercase “F” instead of a lowercase “f”.

This naming rule is followed in all examples in the book, but it’s not explicitely described anywhere. I’ll put it on my list of things to be improved in the next edition of the book.

If you need to be able to use different default values per application, I suggest you use a servlet context init parameter, defined in the web.xml file, and read it in the tag handler.

Example web.xml:

<web-app>
  ...
  <context-param>
    <param-name>
      com.mycompany.taglib.foo
    </param-name>
    <param-value>
      bar
    </param-value>
  </context-param>
  ...
</web-app>

Example tag handler class:

...
String optAttribute = getOptionalAttribute();
if (optAttribute == null) {
  ServletContext sc = pageContext.getServletContext();
  optAttribute = sc.getInitParameter("com.mycompany.taglib.foo");
}
...

I recommend that you use a parameter name that is guaranteed to be unique by following the naming convention used in this example (“com.mycompany.taglib.foo”) if you use this approach, so that you avoid possible name clashes with other tag libraries that may be used in the same application.

If you have many default values you need to define, you may consider using a special servlet (marked as “load-at-startup”) to initialize all defaults and use servlet init parameters instead of context init parameters. The servlet can then set context attributes for all default values, and the tag handlers can retrieve them exactly as above. One advantage with this approach is that the servlet can verify that all default values have been set to okay values when the application starts, so you don’t have to do that in all tag handlers. It also allows you to use short init param value names without risking name clashes with other parts of the application (you should still use the unique names for the context attributes though).

Another benefit of using a servlet to initialize the tag library like this is that it can also create other resources used by multiple tag handlers. In the book, I describe in detail an example of a servlet that makes a JDBC connection pool available to a set of tag handlers.