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.
Version |
Location |
Description |
Submitted by |
Date submitted |
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 |
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 100
n Thread "C" column |
In Thread "C" column --
[finds a another]
I think it should be
[finds another]
|
Anonymous |
Jan 16, 2014 |
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 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 123
Bang! box |
Text from the book reads:
ask what getLocalPort() means. So let’s do the easy one first: getRemotePort(). First you should ask,
The difference between getLocalPort() and getServerPort() is more subtle—getServerPort()
says, “to which port was the request originally SENT?” while getLocalPort() says, “on which port did the request END UP?” Yes, there’s a difference, because although the requests are sent to a single port (where the server is listening), the server turns around and finds a different local port for each thread so that the app can handle multiple clients at the same time.
But when I try printing as follows:
final int localPort = req.getLocalPort();
final int serverPort = req.getServerPort();
System.out.println("Local port is: " + localPort);
System.out.println("Server port is: " + serverPort);
I will get:
Local port is: 8080
Server port is: 8080
|
Koray Tugay |
Jan 19, 2016 |
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 |
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 |
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 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 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 |
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 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 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 |
PDF |
Page 271
12th question, answer C. |
"implmenting" --> "implementing"
|
xehpuk |
Jan 14, 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 |
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, 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 |
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 |
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 344
7.3 |
"aritmetic" --> "arithmetic"
|
xehpuk |
Jan 21, 2012 |
Printed |
Page 344
Objective 7.3 |
aritmetic operators
I think it should be
arithmetic operators
|
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 |
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 |
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 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 |
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 |
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 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 |
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 |
PDF |
Page 442
Chapter 9 |
The helper method must be static.
public static String getConvertedCurrentTip() {
return HTML.convEntity(getCurrentTip());
}
|
Javid Azimli |
Feb 17, 2016 |
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 "<" 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) '<b>' 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 |
|
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 |
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 |
|
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 |
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 |
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 |
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 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 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 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 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 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 |
|
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 |
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 |
PDF |
Page 626
Last paragraph |
The left upper corner of the "BANG!" box overlaps the "us" of "status".
|
xehpuk |
Feb 24, 2012 |
PDF |
Page 639
4th question, answer B. |
It says "begining" but should be "beginning". Same on page 644.
|
xehpuk |
Feb 24, 2012 |
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 |
|
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 |
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 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 |
Printed |
Page 727
whole page |
<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.
|
Anonymous |
Oct 01, 2015 |
PDF |
Page 735
Question 5, answer E |
Answer E says "A filter's doFilter() method must call doFilther() on the input FilterChain object in order to ensure that all filters have a chance to execute."
For my surprise it was wrong, and the explanation says: " - Option E is incorrect because calling doFilter() is not necessary if a filter wishes to block further request processing."
Indeed, I agree with this explanation, but what I understood from what option E were thrying to say is that: yes, a filter may block further request processing, but, in order to ensure that all filters have a chance to execute, you actually must call doFilter() on FilterChain object.
|
Anonymous |
Dec 07, 2014 |
PDF |
Page 763
763 1st paragraph |
Coming from page 57 way back in chapter two in "Flex your mind" exercise section about potential problems with the Dating App MVC Architecture. In page 763 never answer the question about if does Keanu Reeves really know Kung Fu!?
Best Regards.
Litium
|
Litium |
Sep 11, 2015 |
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 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 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 |
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.
|
JavaGuy1122 |
Apr 14, 2012 |