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 |
| Printed |
Page 1
None |
> I do believe that the book fails to note that when a bean is
> referenced within a jsp, the bean must be contained within a
> package. In other words, "<%@ page import="TestBean1" %>" will
> result in an exception when the "TestBean1.class" is placed in the
> "WEB-INF" folder. But "<%@ page import="foo.TestBean1" %>" will
> succeed when the "TestBean1.class" (with a "package foo;"
> statement) is placed in the "WEB-INF/foo" folder. Although I use a
> bean as an example, this is likely the case for non-bean classes as
> well. This was confirmed by Apache's rejection of my bug report
> (45153).
|
Anonymous |
| Printed |
Page 30
Deployment descriptor |
instead of "ISO-8851-1" it should be "ISO-8859-1"
|
Anonymous |
| Printed |
Page 217
Answer to Question 1 |
There is already an errata for this, saying:
Answer states B and C are correct when associated comment (correctly) states (only) answer B is correct.
Note from the Author or Editor:
Uncheck C
--
For reference: B is "flush" and C is "write".
By experimenting with Tomcat 5.5.28 on Windows XP Pro SP3 I discovered, that write() can also cause the error:
java.lang.IllegalStateException: Cannot forward after response has been committed
And print() too.
It is so, that after a certain amount of data (getBufferSize() ? ) is put either by write() or print(ln)(), the buffer goes to commited state (isCommitted()==true), even if flush() is not called.
So the correct answer is B and C. (and if print(ln) were listed too, that would be a correct answer too).
|
David Balažic |
| 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
Notes from the Author: 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
--------------------------------------------------------------------
|
Anonymous |
| Printed |
Page 221
Answer to Question 11 |
The explanation says A and B are wrong, as the order is determined by the DD.
But that fact is never mentioned before the mock exam. OK, you learn it the "hard" way, but it still gives a weird impression. Was this on purpose?
|
David Balažic |
| Printed |
Page 264
seond row, last column (HttpSessionActivationListener -> Usually implemented by |
The book says that HttpSessionActivationListener is "usually implemented by" both "An attribute class" and "Some other class".
IMHO the latter answer is wrong. The listener must not be registered in the DD - only attribute value classes get notified.
|
Anonymous |
| Printed |
Page 335
Q14 Correct Answer Choice (C) |
javax.servlet.ServletContext
javax.servlet.jsp.JspWriter
javax.servlet.http.HttpServletRequest
javax.servlet.http.HttpServletResponse
javax.servlet.http.HttpSession
instead of:
javax.servlet.ServletContext
javax.servlet.jsp.JspWriter
javax.servlet.ServletRequest
javax.servlet.ServletResponse
javax.servlet.http.HttpSession
|
Anonymous |
| Printed |
Page 392
Last sentence of bullet point 3 |
The last sentence states: "The prefix can be anything you like."
This is not true. The reserved prefixes (like jsp, jspx) are not allowed.
|
Anonymous |
| Printed |
Page 420
Handwritten comment for first question |
JSP standard action
<jsp:usebean id="person" type="foo.employee" scope = "request">
<jsp:setproperty name="person" property="name" value="fred"/>
</jsp:usebean>
name is <jsp:getproperty name="person" property="name"/>
Qn 1) Servlet code:
foo.Person p = new foo.employee();
p.setName("evan");
request.setAttribute("person",p);
And the handwritten answer says "Fails at request time! The person attribute
is stored at request scope,
so the <jsp:usebean> tag won't work since it specifies only a type " But, the <jsp:usebean> tag has the
scope specified as request. Since the scope specified in the tag and the scope where the attribute is
stored as per servlet code is "request" why shouldn't the usebean tag work?
I think this example should work.
Author comment:
Needs more research
--------------------------------------------------------------------
|
Anonymous |
| Printed |
Page 420
Example 1 |
The example does NOT fail as it says in the book.
The problem is that the "scope" is specified and it is "request" instead of being omitted (which would result in the
default scope="page" to be used).
In the first version of this book the example is WITHOUT the "scope":
<jsp:useBean id="person" type="foo.Employee">
[see also page 358]
Author comment:
YES, BUT THAT STILL WON'T FIX THE PROBLEM; NEEDS RESEARCH
--------------------------------------------------------------------
|
Anonymous |
| Printed |
Page 420
the first answer |
I think the first example will run successfully and print the name of the person, it will NOT FAIL at request time, as you can see, "person" is a request-scoped attribute, and the <jsp:usebean> determined the scope="request", not only the type as mentioned in the explanation.
|
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 "<" 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 |
| PDF |
Page 445
first handwritten comment from the top |
This page states that if I try to output a value with an expression, and the value evaluates to null, nothing is printed. This is incorrect, as the null variable is passed to the writer, and the string "null" is printed. I tested this on Tomcat 5.5.26. So, the second example of how the text is rendered should say "Hello null."
Here is the JSP code I tested this with:
<html>
<body>
<%! String user = null; %>
<b> Hello <%= user %>.</b>
</body>
</html>
|
Anonymous |
| Printed |
Page 455
"Bang" box |
On page 455 it states that if you don't specify a scope for <c:set>, it will start looking at page, then request, etc.
On page 457 in the Q&A, the 2nd answer says "If you don't use the optional scope attribute in the tag, then the tag will only look in the page scope space."
These seem to contradict each other - which is correct?
|
John Bruce |
| Printed |
Page 457
last point in "Key Points and gotchas with <c:set>"; |
This is being added to refute a previous errata for page 457 that state null should be returned (as opposed to a exception being thrown). It should also be noted that Section 1.6 ("Operators [] and .") of the JSP spec reveals that if the right operand is a method expression and the method does not exist, a MethodNotFOundException is thrown. The actual exception is likely version dependent.
The following results were obtained using tomcat version 6.0.16. Information on EL handling was added to confirm that the results are consistent.
(1) When a <c:set..> with a target expression that is a bean specifies a nonexistent property named "prop3".
javax.servlet.jsp.JspTagException: Invalid property in <set>: "prop3"
Offending code:
<c:set target="${myBean}" property="prop3" >
${myBean2.prop1}
</c:set>
(2) When EL tries to access nonexistent bean property named "prop3".
javax.el.PropertyNotFoundException: Property 'prop3' not found on type foo.TestBean1
Offending code:
${myBean.prop3}
Notes from the Author: I DON'T UNDERSTAND WHAT THIS ERRATA MEANS
I can only assume that what the reporter is seeing is a situation of incompatible versions of the JSP/EL technology. Tomcat v6 implements Servlet v2.5 and JSP v2.1 and should *not* be used for examples in this book. It is possible that the EL spec changed for JSP v2.1 (which is *not* covered in this book).
|
Anonymous |
| Printed |
Page 475
bottom left, hand written comment |
Last sentence: The comment says "We also didn't cover <c:redirect> and <c:out>..." but in the 2nd edition <c:out> has been covered indeed. Seems that the comment corresponds to the first edition of the book.
|
Anonymous |
| Other Digital Version |
475
bottom left, hand written comment |
Last sentence: The comment says "We also didn't cover <c:redirect> and <c:out>..." but in the 2nd edition <c:out> has been covered indeed. Seems that the comment corresponds to the first edition of the book.
|
Anonymous |
| PDF |
Page 490
diagram |
The arrow from "<rtexprvalue>true</rtexprvalue>" should point to "${foo}", not "/>"
|
pcchee |
| Printed |
Page 497
Question 6 |
Option -D- is check as being valid *custom* tag usage.
This is misleading. The JSTL spec designates <c:out/> as a general purpose action of the *core* tag library.
The question should be either rephrased as "...which are examples of valid tag usage?" (note: drop the word 'custom') or option -D- should be left unchecked.
|
Anonymous |
| Printed |
Page 583
Mock Exam, Questions 08 and 18. |
Chapter 10 - Mock Exam - Printed version.
Question 08 - Option B.
Question 18 - Option E.
It was never mentioned in the aforementioned chapter (Please correct me if I'm wrong) that the tag files could also have a *.tagx extension, for which reason any reader would have considered option B (Question 08) and option E (Question 18) as wrong (unless you previously read the specs before answering both questions). This is only briefly mentioned in the next chapter, pages 634 y 636.
My suggestion would be for page 502 to be modified to include the previously mentioned annotation where it says: "Take an included file (like "Header.jsp") and rename it with a .tag extension". This way, the questions can remain the same.
Best regards and thank you in advance.
|
Josnel Maraver |
| PDF |
Page 597
question 15, option e, handwritten answer |
The tip states there is no such method JspContext.getAttributesScope(String), but there actually is. It is not a correct anwer anyways.
|
Anonymous |
| Printed |
Page 628
hand written text |
The 2nd paragraph on page 628 says that a "non negative value for <load-on-startup>" does something, the hand-written text on the same page makes this "greater than zero", should be greater than or equal to zero according to Sun spec.
OTOH Bea documentation refers to "positive" values
|
Anonymous |
| Printed |
Page 632
Bottom half + bang box |
The bang box states that the env-entries do not need to be primitives. This who explicit clarification is required because the example uses...primitives!
If the example where to use non-primitives, the whole clarification would become superfluous.
Consider:
<env-entry>
<env-entry-name>kennel/dogs</env-entry-name>
<env-entry-type>pets.Dog</env-entry-type>
<env-entry-value>Brutus</env-entry-value>
</env-entry>
|
Anonymous |
| Printed |
Page 725
code for getOutputStream and getWriter |
the if-statements in the accessors check whether streamUsed is already initialized.
Now if either method is called a second time an IllegalStateException will be thrown. From the description it seems that should only happen if both methods are called and it should be ok to call the same method several times.
If you change the if statement in getOutputStream to
"if (streamUsed != null) && (streamUsed == pw) {
throw ..."
the behavior will be as described
|
Anonymous |
| Printed |
Page 735
Question 5 |
Answer -E- is said to be incorrect. The handwritten comment says: "Option E is incorrect because calling doFilter() is not necessary if a filter wishes to block further request processing." Althoug this is true in general, the sentence part "...in order to ensure that all filters have a chance to execute" clearly indicates the goal to execute the rest of the filters. Hence the handwritten comment is inaccurate en answer -E- should be marked valid.
|
Anonymous |
| Printed |
Page 824
Answers |
There aren't answer for question 66 in Final Mock Exam.
|
Anonymous |
| Printed |
Page 834
Question 14 |
According to the servlet spec (7.1.3 URL rewriting), it is almost impossible to disregard URL as a container requirement. The spec states: "The session ID must be encoded as a path parameter in the URL string. The name of the parameter must be jsessionid."
Hence answer -B- should be accepted as true.
|
Anonymous |
| Printed |
Page 843
Question 30 |
In your final mock exam in question 30, the correct answer should be F, not D!
Regards,
Miroslaw Begier
|
Anonymous |
| Printed |
Page 843
Question 30 |
In the confirmed errata you changed the answer for Q30 from D to F. The book presents a similar example on page 671, item 4 in the table. This scenario is the same one in Q30 but two different answers are given. Which one is correct? In my opinion, everybody should have access to the constrained resource if you remove the second auth-constraint in Q30, that is, the original answer D is correct (and your correction is wrong).
|
Emir Basic |
| 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 |
| PDF |
Page 844
question 33 |
I think E is not correct.. As long as you call super() at the end of the method, you can do some general stuff in there.
Besides, if the 'servlet' is not an HttpServlet, but a GenericServlet, it even has to!
|
Anonymous |
| Printed |
Page 849
Answer C for Question 43 |
Answers c isn't correct:
c)Each time that doPost() is invoked, it runs in its own thread.
Because this means that there is one more extra thread for doPost, extra than thread for service method
|
Anonymous |
| Printed |
Page 849
2nd block |
The answer on Question 43 states that A is incorrect. It states that init() method is invoked first for a new request that is received.
If you look at page 97 it is clearly stated that init is called ONCE. And that service is called on every request.
Thus: Or A seems to be correct, or page 97 gives wrong information.
|
i-am-will |
| Safari Books Online |
850
question 45 |
Q45:
Given this fragment from a valid doGet() method:
12. OutputStream os = response.getOutputStream();
13. byte[] ba = {1,2,3};
14. os.write(ba);
15. RequestDispatcher rd = request.RequestDispatcher("my.jsp");
16. rd.forward(request, response);
Assuming that "my.jsp" adds the bytes 4, 5, and 6 to the response, what is the result?
A. 123
B. 456
C. 123456
D. 456123
E. An exception is thrown
Answer according to HF is B: - because os.flush() wasn’t called, the uncommitted output (123), is cleared, and forward is invoked without exception. If os.flush() had been called before forward, an IllegalStateException would have been thrown.
This is not true. The above code will always cause an IllegalArgumentException, flushed or not. The implementation class of the JSP page will create a PageContext object, which in turn will call getWriter() on the response object (to set its out property). Because the response object already called getOutputStream(), it will throw an exception.
|
Anonymous |
| PDF |
Page 854
Question 54 |
Line 63 could be valid. The question does not say that if IOException is user defined exception or standard Java IO Exception (also that's what all the answer options are, not java.io.IOException). IOException in could be assumed from the default package and could be a user defined exception. Therefore the correct answer should be D.
|
Riken Shah |
| Printed |
Page 859
Question 64 |
Question states that the compatibilityProfile attribute is session scoped. However the answer D marked as correct doesn't specify scope attribute in the c:set therefore operates in the page scope. As a result none of the answers is correct.
[CH7 to CH10]Comment about failure to include working example of JSP
> accessing Javabean. ;
> I am using version 6.0.16 of tomcat and the problem may be version
> dependent. The problem I experienced is, if a bean is not contained
> within a package, the bean is not accessible from a JSP. The
> solution was arrived at by noting that all of your (poor) examples
> use the "foo" package even though there was no reason for using a
> package. I believe this is a but and should be submitted to Sun.
>
> Without a package specified and with the bean class file in the
> classes folder, the following exceptions occurred. The condition
> was not resolved until the package statement was added to the bean
> class and the class file was placed in the "classes/foo" folder. In
> the future I hope shortcuts, like failing to provide a complete
> example through chapters 7 through 10, can be avoided:
>
>
> This is the error when the useBean standard action was used:
> SEVERE: Servlet.service() for servlet jsp threw exception
> org.apache.jasper.JasperException: /testJSTL3.jsp(12,0) The value for
> the useBean class attribute TestBean1 is invalid.
> at
>
org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
> ...
>
> This is the error when a scriptlet was used:
> SEVERE: Servlet.service() for servlet jsp threw exception
> org.apache.jasper.JasperException: Unable to compile class for JSP:
>
> An error occurred at line: 7 in the jsp file: /testJSTL3.jsp
> TestBean1 cannot be resolved to a type
> 4: <%
> 5: String [] movieList = {"Amelie", "Returrn of the King", "Mean
> Girls"};
> 6: request.setAttribute("movieList", movieList);
> 7: TestBean1 myBean = new TestBean1();
>
>
> This is the error when the page directive and import attribute were
> used in the jsp.
> SEVERE: Servlet.service() for servlet jsp threw exception
> org.apache.jasper.JasperException: Unable to compile class for JSP:
>
> An error occurred at line: 6 in the generated java file
> The import TestBean1 cannot be resolved
--------------------------------------------------------------------
|
Anonymous |
| Printed |
Page 859
Question 64 |
Question states that the compatibilityProfile attribute is session scoped. However the answer D marked as correct doesn't specify scope attribute in the c:set therefore operates in the page scope. As a result non e of the answers is correct.
|
Anonymous |
