Head First Servlets and JSP

Errata for Head First Servlets and JSP

Submit your own errata for this product.


The errata list is a list of errors and their corrections that were found after the product was released.

The following errata were submitted by our customers and have not yet been approved or disproved by the author or editor. They solely represent the opinion of the customer.


Color Key: Serious Technical Mistake Minor Technical Mistake Language or formatting error Typo Question Note Update



Version Location Description Submitted By Date Submitted
PDF Page 849
Question 44

According to page 283, JSP has the next lifecycle: - Developer writes JSP - JSP translated to *.java - *.java compiled to *.class - *.class loaded by class loader. and so on.. When application is in deployment phase, JSP get translated to java. And it's right. But when user do the first request, it's too late for translation. So, I think that C is wrong.

Evgeny Mironenko  Nov 23, 2014 
, PDF, Safari Books Online Page 2rand[0,1,1]
New York

cOBztN <a href="http://eetfzmcunalg.com/">eetfzmcunalg</a>, [url=http://rovificcpeks.com/]rovificcpeks[/url], [link=http://kpfabqilxzfm.com/]kpfabqilxzfm[/link], http://qlilidhesvwc.com/

Anonymous  Nov 22, 2014 
Printed, PDF Page 445
2nd sub-heading

Printed: A JSP expression tag prints nothing if the user is null <b>Hello <%= user %>.</b> Rendered as <b>Hello .</b> Error: The JSP which consists of such an expression will not even compile as 'user' can't be resolved to a variable. Correction: <b>Hello <%= request.getAttribute("user") %>

Rajasekhar  Feb 25, 2014 
Printed Page 344
Objective 7.3

aritmetic operators I think it should be arithmetic operators

Anonymous  Jan 16, 2014 
Printed Page 123
The first answer of the first question

...possible to create a servlet that proceses think it should be ...possible to create a servlet that processes

Anonymous  Jan 16, 2014 
Printed Page 100
n Thread "C" column

In Thread "C" column -- [finds a another] I think it should be [finds another]

Anonymous  Jan 16, 2014 
PDF Page 349
1st paragraph

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").

Ioan Bota  Jan 02, 2014 
PDF Page 357
1st paragraph

<jsp:getProperty /> can not have a "scope" attribute. The spec says that the value of the name attribute in jsp:getProperty will refer to an object that is obtained from the pageContext object through its findAttribute method. It wouldn't make sense anyway to have a scope attribute because you can not have two <jsp:useBean/> elements with the same id and different scopes.

Ioan Bota  Jan 01, 2014 
Printed Page 222
Question 15 Answer E

Although an IllegalStateException will rise on forward, the response will have already been sent using flush. So E is true.

Anonymous  Apr 11, 2013 
PDF, Mobi Page 645
Question 7

The answer key says that Option A is incorrect because line 10 would be invalid in a JSP Document however, option A specifies that Lines 10 and 12 are equivalent in any type of JSP page. It would be misleading to say this, since earlier in the chapter, you go out of your way to make the point that normal JSPs are pages, and XML JSPs are documents (pg. 629). Therefore, it would seem fitting to either say this option is correct, since any JSP pages (as defined by the text earlier in the chapter) would be equally valid with line 10 and 12, or say that these lines are equivalent in a JSP page or document and is wrong.

Mike Li  Jan 15, 2013 
PDF Page 455
BANG! box

In the BANG! box about <c:set> it says that if value evaluates to null then the attribute will be removed, and if scope isn't specified it will look at page, then request, etc. Which makes one think that it only removes the first attribute it finds, but it removes attributes with the same name from all scopes.

Anonymous  Nov 13, 2012 
Printed, PDF Page 484
the text in the black block

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!"

Anonymous  Oct 07, 2012 
Printed, PDF Page 322
second paragraph

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)

Anonymous  Sep 25, 2012 
Printed, PDF Page 322
second paragraph

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)

Peyman  Sep 25, 2012 
Safari Books Online 599
Question 19, answer

Found a typo in the answer to question 19. Option B (getAncestor) is checked, although in the comment it says "- Option A is correct". Option A is a getParent() method, and it IS the correct answer.

Levan Kekelidze  Aug 20, 2012 
Printed Page 295
last paragraph

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++; } %>

VIJAY VERMA  Aug 18, 2012 
Printed Page 400
Last bullet point

There is nonresistance between the example of page 393-394 and the directive shown on this bullet point. The example place the <uri> from the TLD file in the uri of the directive where here the path of the file is written instead.

Anonymous  Aug 18, 2012 
PDF Page 727
'Filter Sequence' list

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

Tom  May 17, 2012 
PDF Page 854
Question 54

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.

None  Apr 14, 2012 
Printed Page 843
Answer of question 30

The followint snipet is from the question. 234. <auth-constraint> 235. <role-name>student</role-name> 236. </auth-constraint> And the second security constraint contains: 251. <auth-constraint/> The answer says that option F is the right one (If the second <auth-constraint> tag is removed, the constrained resource can be accessed only by students). Option F is WRONG. In fact, OPTION "D" IS THE CORRECT ONE (refer to table in page 669 of the book). I've also tested this scenario in Tomcat 7 and observed that when removing the second <auth-constraint> tag ANY user can access the constrained resource.

Adriano Nobre Oliveira  Apr 12, 2012 
PDF Page 592
Question 5

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.

Remko de Jong  Apr 09, 2012 
Printed Page 247
2nd doGet method

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.

Ernesto Reig  Mar 29, 2012 
Printed Page 14
List item 3

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.

Anonymous  Mar 15, 2012 
PDF Page 674
isUserInRole() paragraph

Last phrase: "[...] based on wheher the user is in a particular role." "wheher" -> "whether" Corrected: "[...] based on whether the user is in a particular role."

xehpuk  Feb 27, 2012 
PDF Page 639
4th question, answer B.

It says "begining" but should be "beginning". Same on page 644.

xehpuk  Feb 24, 2012 
PDF Page 626
Last paragraph

The left upper corner of the "BANG!" box overlaps the "us" of "status".

xehpuk  Feb 24, 2012 
PDF Page 555
3rd paragraph, 1st sentence

Sentence is: "We could apply an design principle:" Should be: "We could apply a design principle:"

xehpuk  Feb 24, 2012 
PDF Page 544
Second to last code line

The comment is: "// // END of doTag() method" (two redundant slashes) Should be: "// END of doTag() method"

xehpuk  Feb 24, 2012 
PDF Page 531
The Classic tag handler, try-catch

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 ...'

xehpuk  Feb 05, 2012 
PDF Page 511
Exercises 1 and 2

Delete the "would" in both sentences: Before: "Fill in what would you must put […]" After: "Fill in what you must put […]"

xehpuk  Jan 31, 2012 
PDF Page 428
16th question, answer A.

The font in this answer seems to be a bit wider than usual. This is irritating.

xehpuk  Jan 21, 2012 
PDF Page 399
1st remark

« If you say "The value is: ${foo}." You'll just see "The value is." » The output is wrong. It should be: "The value is: ."

xehpuk  Jan 21, 2012 
PDF Page 344
7.3

"aritmetic" --> "arithmetic"

xehpuk  Jan 21, 2012 
PDF Page 336
1st question

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

xehpuk  Jan 17, 2012 
PDF Page 275
5th question, answer B.

This (correct) answer talks about SSL. To this point, there hasn't been any occurrence of SSL in the book, though.

xehpuk  Jan 14, 2012 
PDF Page 278
12th question, answer C.

"implmenting" --> "implementing" (same as on page 271)

xehpuk  Jan 14, 2012 
PDF Page 271
12th question, answer C.

"implmenting" --> "implementing"

xehpuk  Jan 14, 2012 
PDF Page 509
Sharpen your pencil section

In pg. 509 the question was asked "What is the result if the thingsDontWork test is false. The answer should be that the SkipPageException exception will not be thrown therefore the JSP that invoked the <myTags:simple6> tag should continue executing after the doTag() method in the Tag Handler class finishes executing since it depends on the thingsDontWork test to evaluate to true for it to be thrown. Instead the answer in pg 510 gives the answer as if the thingsDontWork test evaluated to true, and the SkipPageException was actually thrown thereby making it impossible the JSP that invoked the <myTags:simple6> tag to continue execution after the doTag() in Tag Handler class finishes executing.

Kenneth  Dec 15, 2011 
Printed Page 76
DD Code

xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" version="2.4" no longer returns valid document xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee/web-app_2_5.xsd" version="2.5" works, but is this most current?

Anonymous  Oct 21, 2011 
Printed Page 134
Step 5 and 6

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

Abhinav Shukla  Oct 20, 2011 
PDF Page 607
3 answer

I am concerned about the 3rd question: "which statement about WAR files are true?" and the correct answer is (according to you): "a valid WAR file must contain a deployment descriptor" I think it should contain the descriptor but it is possible to have a valid WAR file without any descriptors you don´t even need to have WEB-INF,moreover the servlet spec doesn´t mention that the web.xml file is obligatory I deployed and correctly run a WAR file that contained only JSP file and it worked well please let me know if you think that my reasoning is correct

Anonymous  Sep 07, 2011 
Printed Page 359
Last bold code snippit

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

Anonymous  Aug 15, 2011 
Printed Page 249
Line -6

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!

Anonymous  Aug 12, 2011 
Printed Page 598
Question 17

In question description it's clearly mentioned that both tags should be non-empty. But in option A classic tag is empty and still its given as one of correct answers. Please correct me if i am wrong.

Anonymous  Aug 07, 2011 
Printed Page 221
answers to Question 12

This is in the printed and PDF versions. The book lists options A and E as correct answers. I knew A was correct, but couldn't find where E was covered. I was able to verify it online. Where in the book was the material on answer E covered? I haven't been able to find it.

Anonymous  Jul 24, 2011 
Printed Page 114
Answer at the bottom of the page

The answer on a question concerning non-idempotent/idempotent contains on the second line of the answer: ".. even though you CAN write a non-idemtotent doGet() method..." where it should read: ".. even though you CAN write a non-idempotent dGet() method..."

Anonymous  Jun 07, 2011 
Printed Page 244
3rd row , 1st column

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.

Rahul B  May 24, 2011 
Printed Page 355
1st paragraph

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.

Daire  Apr 21, 2011 
Printed Page 437
Quesion 17

The Answer for Question number 17 is specified as A and errata says A & C. But how come A is correct? i.e Anywhere the .(dot) operator is used, the [] could be instead. Since .(dot) cant be used in all places like array and List like []. Its used only in Map and Bean. So the word 'anywhere' could be changed to 'whereever'. i.e Wherever the .(dot) operator is used, the [] could be instead. Then we can choose the option A. Otherwise the it should be unchecked.

Angeline  Apr 18, 2011 
Printed Page 217
Question 1

Answers given in book are B and C. In the errata there is already an entry to say that only B is correct. However, in my opinion, B, C and D are all correct. The question states "the use of which methods can often <b>lead to</b> an IllegalStateException". Any method that attempts to do something with the output can "lead to" such an error as is the case with write() or getOutputStream(). If you're not going to use these methods to write ot the response and flush them then why are you calling them? I suggest both C and D are included as correct answers OR the wording of the question is amended to say something like "the use of which methods could directly cause an IllegalStateException to be thrown".

Daire  Apr 07, 2011 
Safari Books Online 669
4 and 5 paragraph

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.

Anonymous  Feb 24, 2011 
Safari Books Online 470
Declaration for catch-all error page and declaration for explicit exception

I agree that this will catch everything,it works OK with Tomcat 5.5: <error-page> <exception-type>java.lang.Throwable</exception-type> <location>/errorPage.jsp</location> </error-page> Anyway, let's say that I add this one now to the same DD: <error-page> <exception-type>java.lang.ArithmeticException</exception-type> <location>/arithmeticError.jsp</location> </error-page> I have a JSP throwing an ArithmeticException that is being send to the errorPage.jsp, when according to the book I would expect to see the exception being handled in the /arithmeticError.jsp but that's not happening, errorPage.jsp is still receiving the error. If I remove the Throwable handler (the catch-all error page) from the DD, the next time I execute the JSP that throws ArithmeticException then this time the error is actually being sent to arithmeticError.jsp. What's happening here? Shouldn't the exception go to the most specific handler?

Abel Morelos  Feb 01, 2010 
Other Digital Version 843
This is an errata of the errata

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.

Ankit Garg  Nov 16, 2009 
Printed Page 221
Answer D of question 12

The text indicates answer D (which refers to HttpServletREquest.getQueryString) is not correct and answer E (which refers to javax.servlet.forward.query_string) is correct. However, according to page of 62 of version 2.5 (MR6) of the Servlet Spec "servlet-2_5-mrel2-spec.pdf": " ... javax.servlet.forward.query_string The values of these attributes must be equal to the return values of the HttpServletRequest methods ..., getQueryString, respectively, invoked on the request object passed to the first servlet object in the call chain that received the request from the client. ..." Therefore, either D and E are both correct or they are both incorrect, and it is clear from the spec that they are

Note from the Author or Editor:
Needs more research

Anonymous   
Printed Page 221
Answer D of question 12.

The text indicates answer D (which refers to HttpServletREquest.getQueryString) is not correct and answer E (which refers to javax.servlet.forward.query_string) is correct. However, according to page of 62 of version 2.5 (MR6) of the Servlet Spec "servlet-2_5-mrel2-spec.pdf": " ... javax.servlet.forward.query_string The values of these attributes must be equal to the return values of the HttpServletRequest methods ..., getQueryString, respectively, invoked on the request object passed to the first servlet object in the call chain that received the request from the client. ..." Therefore, either D and E are both correct or they are both incorrect, and it is clear from the spec that they are Author comment: Needs more research --------------------------------------------------------------------

Note from the Author or Editor:
Needs more research

Anonymous   
Printed Page 443
Discussion of escapeXml and character conversion on pages 443 and 444.

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. --------------------------------------------------------------------

Anonymous