Errata

<filter-mapping>
<filter-name>Filter1</filter-name>
<url-pattern>/Recipes/*</url-pattern>
</filter-mapping>

<filter-mapping>
<filter-name>Filter2</filter-name>
<url-pattern>/Recipes/HopsList.do</url-pattern>
</filter-mapping>
...
<filter-mapping>
<filter-name>Filter5</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

Request Path : /Recipes/HopsList.do.
Filter sequence : filter1, filter5, filter2

But when I tried it in my code,
I have a ReceiptServlet.
I have this servlet url-pattern in web.xml

<servlet-mapping>
<servlet-name>ReceipesServlet</servlet-name>
<url-pattern>/Recipes/HopsList.do</url-pattern>
</servlet-mapping>


My Result is filter1, filter2, filter 5.

The first paragraph says:
"The <jsp:useBean> is a way of declaring and initializing the actual bean object you're using in <jsp:getProperty>."
----------------------------------------------------------------------------------

The actual object that is used in <jsp:getProperty> is not always the object declared by <jsp:useBean>.
For example:

A request is made to a servlet which sets the following attribute:

Person p = new Person();
p.setName("person from request");
request.setAttribute("person", p);

The servlet then forwards the request to a jsp in which we have:

<jsp:useBean id="person" scope="session" class="foo.Person"/>
<jsp:getProperty property="name" name="person"/>

What happens is that the <jsp:useBean> creates another instance of foo.Person and puts it in the session scope. But the <jsp:getProperty> actually retrieves the name property of the Person object we put on the request. So it will print "person from request".

This behavior is really unintuitive but apparently is according to the spec, which says that the object used by both <jsp:getProperty> and <jsp:setProperty> is retrieved by the method pageContext.findAttribute("person").

I would say in the last sentence: "The uri does NOT have to be the location of the actual tag handler!" ,
the expression "tag handler" should be replaced with "TLD file", since the the tag handler is only a class as I understood.

that is the corrected version: "The uri does NOT have to be the location of the actual TLD file!"

The sentence "Except that J2SE version 1.4 came with assertions disabled by default." is wrong.

By J2SE version 1.3 was assertion disabled and NOT by version 1.4. (See SCJP-Book by Kathy Sierra and Bert Bates p. 389)

The sentence "Except that J2SE version 1.4 came with assertions disabled by default." is wrong.

By J2SE version 1.3 was assertion disabled and NOT by version 1.4. (See SCJP-Book by Kathy Sierra and Bert Bates p. 389)

In the last paragraph the definition of the method doubleCount():

it is written as follows:

<%! int doubleCount(){
count=count*2;
return count;
}
%>

The name of function implies that the method will return double the number of times the page has been requested. But the method returns exponentially.

The method definition should be :

<%! int doubleCount(){
return 2*count++;
}
%>

Filter Sequence for request paths are incorrect for twho request paths.

They are listed as follows:
/Recipes/HopsReport.do - Filters: 1, 5
/Recipes/HopsList.do - Filters: 1, 5, 2
/Recipes/Modify/ModRecipes.do - Filters: 1, 5, 4
/HopsList.do - Filters: 5
/Recipes/Add/AddRecipes.do - Filters: 1, 3, 5

But they SHOULD BE:
/Recipes/HopsReport.do - Filters: 1, 5
/Recipes/HopsList.do - Filters: 1, 2, 5
/Recipes/Modify/ModRecipes.do - Filters: 1, 4, 5
/HopsList.do - Filters: 5
/Recipes/Add/AddRecipes.do - Filters: 1, 3, 5

Best regards
Tom

The correct answers to the question should be A and B.

This is the Second Edition of the book I am referring to in the PDF format.

A is correct answer because IOException in itself is not a fully qualified class name and most people would recognize the correct name would be java.io.IOException.

B is also right since if the application were to actually throw an IOException (regardless of whether it is the fully qualified one or some custom user defined one) - there isn't any information in the enclosed snippet that will cause the container to pick any of the error pages listed there.

In the answer it is claimed that the EVAL_BODY_BUFFERED is not a valid return of the doAfterBody method. However, if your tag handler extends BodyTagSupport, it is a valid value. This is because in the end you are returning an int. And EVAL_BODY_BUFFERED has the same value as EVAL_BODY_AGAIN, i.e. 2. Despite the fact you probably don't want to do this in real life, it still is a valid return value.

In the second doGet method the "foo" variable does not exist. It should be:
String foo = (String) session.getAttribute("foo");
as in the first method. As it stands now, it would not compile.

Incorrect: Because of number 2 above, the user can't bookmark a form submission if you use POST instead of GET.

Correct: Because of number 2 above, the user can't bookmark a form submission if you use GET instead of POST.

In the catch block, there is this line: 'throw new JspException("IOException- " + ex.toString());'
This is bad, since it uses the JspException(String) constructor rather than JspException([String,] Throwable).
The stacktrace would be like this:
'Exception in thread "<name>" javax.servlet.jsp.JspException: IOException- java.io.IOException: <message>
at ...'

Replace it with this line: 'throw new JspException(ex);'
The stacktrace would be like this:
'Exception in thread "<name>" javax.servlet.jsp.JspException: java.io.IOException: <message>
at ...
Caused by: java.io.IOException: <message>
at ...'

As is, this tag would not be understood because it misses <jsp-config> before line 47 and </jsp-config> after line 50.

Status code for sendRedirect() is 302 instead of 301.

This information is based on description given in Java EE 6 API.

http://download.oracle.com/javaee/6/api/javax/servlet/http/HttpServletResponse.html#sendRedirect%28java.lang.String%29

The book reprint was updated from the errata incorrectly: userName would be surrounded with double (not single!) quotes. (Otherwise, you get the same error as on the first printing....)

Previous errata entry said to delete String foo = ..., which has been done in my reprint. However, line -6 uses foo as a variable, which is now never declared in scope. Opps!

void setMaxInactiveInterval(int interval) takes an int. The method shown in the book takes no arguments. You can also add that a negative argument means no time-out and please include the return types of these methods also.
Same error in previous page.

Minor issue, may even be bordering on pedantic!

Text states "With the changes we just made to the Person class, we're in trouble if the attribute can't be found".

We're actually in trouble full-stop, irrespective of whether the attribute can or can't be found. The container willl generate the code something like this:

if(person == null) {
person = new Person(); // compile error here
pageContext.setAttribute("person", person);
}

which will cause a JSP compile error irrespective of whether a person attribute would have existed at runtime or not.

The book states "These two have the SAME effect" but it doesn't because in the prevous page "668" it states "If an <auth-constraint> does NOT
exist, the Container MUST allow unauthenticated access for these URLs."

So this is the difference:

<role-name>*<role-name> allows any authenticated user

no <auth-constraint> allows any user authenticated or not

Note from the Author or Editor:
I think you are correct. I will have to test this to verify.

The errata for Page 843 Question 30 says to remove checkmark from D and move it to F. This is wrong. If the second auth-constraint tag is removed, it is equivalent to

<auth-constraint>
<role-name>*</role-name>
</auth-constraint>

Thus both student and sensei can access the resource. So the book is actually right and the errata is wrong. Similar behavior has been explained on page 693 the 5th puzzle.

From the provided discussion one is not able to determine that the primary concern is how xml tags
are affected by the escapeXml attribute. This is the primary concern because for the character
entities that require escaping (<, >, &, ', "), with escapeXml set to true or false the entities
display the same way in the
browser. That is, "<" and "&lt;" appear as "<" in the browser. The source
is different but the display is the same.

Tags are the primary concern because of the is a drastic difference in what is displayed. With
"escapeXml='true'" (the default), xml tags are escaped, which means displayed literally by sending
(for example) '&lt;b&gt;' to the browser. This results in the literal display of the tag (for example:
<b>). With the "escapeXml='false'", xml tags as sent as is to the browser, and the browser renders
them based on their value (i.e. by displaying bolded text).

The problem with page 443 and 444 is that one cannot easily discern the above given the information
provided. This conclusion needs to be pieced together from information provided in multiple paragraphs
on the above two pages. In fact, beginning with chapter 7 there appears to have been decrease in the
effort to make things clear.
As a example, page 384 introduces a "pageContent" variable. This variable
is used again on page 442 and 443. However, there is no effort to explain this variable (i.e. '...let
this be a map that contains ....').

Author comment:
NO ERROR. Your criticism has merit and I will keep note of it for a future revision.

--------------------------------------------------------------------