Head First Servlets and JSP, Second Edition By Bryan Basham, Kathy Sierra, Bert Bates The unconfirmed error reports are from readers. They have not yet been approved or disproved by the author or editor and represent solely the opinion of the reader. Here's a key to the markup: [page-number]: serious technical mistake {page-number}: minor technical mistake : important language/formatting problem (page-number): language change or minor formatting problem ?page-number?: reader question or request for clarification This page was updated June 13, 2008. UNCONFIRMED errors and comments from readers: {186} Attributes are not Parameters - 4th row 3rd column; Method to get should mention getParameter(String name) for getting request parameters. It has mentioned only getInitParameter(String name) which is applicable only for getting context and servlet init params. {217} Answer to Question 1.; Answer states B and C are correct when associated comment (correctly) states (only) answer B is correct. (220) top of page; the correction reads (emphasis added): this option is worded poorly. I would rephrase it as: "If the servlet implements javax.servlet.SingleThreadModel, the container may use one instance for *each* simultaneous request." In other words, the current wording seems to suggest that there is one *different* instance for *every* request. This is still inaccurate or misleading. My suggestion (emphasis added): "If the servlet implements javax.servlet.SingleThreadModel, the container may use one instance for *all* simultaneous request*s*." [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 both correct. (222) Answer C; Answer C implies that if I use a ServletRequest and ServletContext obtain a RequestDispatcher for a resource, then the path to the resource will be different (i.e. will change). This is not correct if the argument to both getRequestDispatcher calls begins with a forward slash, which means relative to the context root in both cases. It is correct to say the paths can be different, but it is not a mandatory condition. (239) Answer to "Is URL rewriting handled in a vendor-sepcific way?"; In the 4th sentence of your answer you state, "...another vendor might append only the session ID itself...", then on page 275 you indicate for question 5, answer D is correct. Answer D states that JSESSIONID must be the name of the session tracking cookie. However, according to page of 53 (SRV.7.1.1) and page 54 (SRV.7.1.3) of version 2.5 (MR6) of the Servlet Spec "servlet-2_5-mrel2-spec.pdf", the name of the cookie and the name of the parameter (respectively) is mandatory. What this really means is that to be within the spec, vendors must adhere to the above rules. As you indicate on page 239 (for jsessionid), vendors can deviate from those rules as account for it in their implementation. The problem is in one instance (page 239) you indicate deviation from the spec is ok, but then in another instance it is not ok (page 275). The real problem is, it possible the exam one receives has a question similar to question 5 on page 275, but instead of JESSIONID, jessionid is used. I believe an associated caveat should have been added to the indicated page 239 answer. {249} Second comment on code block (2) and "Result" statement and end of code block.; Both statements suggest that the session.isNew() call will results in the InvalidStateException. However, since the first comment indicates the session times out immediately, it is the session.getAttribute() call that will result in the above exception. It appears the getAttribute call should have been placed immediately after the if/else statement. [256] Bang box titled "You do NOT configure session binding listeners in the DD!; Bang box reads: "You do NOT configure session binding listeners in the DD! ... But this is NOT true for the other session related listeners on the previous page. HttpSessionListener and HttpSessionActivationListener must be registered in the DD, since they're related to the session itself, rather than an individual attribute placed in the session." Should read: "You do NOT configure session binding listeners OR SESSION ACTIVATION LISTENERS in the DD! ... But this is NOT true for the other session related listeners on the previous page. HttpSessionListener and *HttpSessionAttributeListener* must be registered in the DD, since they're related to the session itself, rather than an individual attribute placed in the session." (310)url-pattern tag; The jst-file tag contains "TestInit.jsp" but the url-pattern tag contains "TestInif.jsp", which appears to be a typo. (355)last paragraph; The final sentence states, "...the class must be a subclass...". I know this is splitting hairs, but since were are talking about types (e.g. interface), I believe, "...the class must be a subtype...", would be semantically (more) correct. (358)first paragraph; The second sentence states there are 3 code examples but only 2 examples are provided. (368)End; This is more of a comment. By page 368 we have gone through 25 pages without any coding exercises to reinforce the material. I realize the material is near the point of being obsolete with the new way of doing things (i.e. jstl). However, the number of pages processed without reinforcement makes the end of chapter exercises more about how much to you remember as opposed to what did you learn. [420] Handwritten comment for first question; JSP standard action name is 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 tag won't work since it specifies only a type " But, the 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. {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": [see also page 358] [437] Question 17; Regarding the usage of the dot "." operator, the last comment on page 370 states, "If the object is a bean but the named property doesn't exist, then as exception is thrown? However, the answer to question 17 on page 437 does not reflect this as being true as 17-C is not checked. {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: ). 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 ....'). [457] last point in "Key Points and gotchas with "; Last statement in the point says "Remember that the EL expression ${bean.notAProperty}" will also throw an exception" I think EL expressions return null if the property doesn't exist. (457)last point in "Key Points and gotchas with ";; 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 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: ${myBean2.prop1} (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} (485) 2nd line; The answer of the question 1: A. TLD files may be placed in any subdirectory of WEB-INF. The spec said: -------------------------------------------------------------------- When deployed directly into a web application, the tag library descriptor files must always be in the WEB-INF directory, or some subdirectory of it. TLD files should not be placed in /WEB-INF/classes or / WEB-INF/lib. -------------------------------------------------------------------- The error is that not in any subdirectory. "TLD files should not be placed in /WEB-INF/classes or /WEB-INF/lib." As the spec said. [497] Answer 6; Answer 6D suggests is an example of custom tag usage. The paragraphs that follow suggests this is false. I also believe the book results in confusion in understanding what are standard and custom tags: On page 2 of the spec (jstl-1_2-mrel2-spec.pdf), at the end of section 1.1 the spec states, "The other key aspect of JSTL is that it provides standard actions and standard EL functions...". The spec then goes on to list the 5 associated libraries. Furthermore, on page 31 in Section 5.2 is one of the few instances the spec refers to "custom" as a subject. Here is speaks of a custom action of the form "", which is clearly not part of jstl. Other reference suggest "custom" implies "programmer supplied/constructed". Based on this information I am lead to believe the JSTL supplied tags are standard tags and programmer supplied tags, which are tags not defined by the jstl spec, are custom tags. This is in fact the subject of Chapter 10, which states in the opening page, "Sometimes JSTL and standard actions aren't enough. When you need something custom...". However, the opening page of Chapter 9, which is titled, "Using JSTL", states, "Custom tags are powerful". Based on the spec I believe there are JSP standard actions/tags, and JSTL standard action/tags. An action/tag that is not a member of the above groups if therefore considered a custom action/tag. {510}Tag file TLD example that begins the second column on the page.; The text states the example is the TLD for a tag file. However, according to page 1-175 of the JSP 2.1 spec, there is no uri sub-element. Instead, a short-name element is used, and it is a concatenation of the path from the WEB-INF folder to the tag file (with "/" replaced with "-"). Since this is not likely to be on the test, one could consider it a minor error. Note that the JSP 2.0 spec provides the same information. {570} 3rd paragraph - In the SimpleInner tag handler; In a JSP In the SimpleInner tag handler public void doTag() throws JspException,IOException { MyClassicParent parent = (MyClassicParent) getParent(); getJspContext().getOut().print("Parent attribute is: " +parent.getName()); ) The getParent() return value should be casted to ClassicParent instead of MyClassicParent [830]Quesiton 4; The sample code in question, set the attribute in request scope. And equivalent code snippet answers are given as C & D. But those two answers create the attribute in page scope (default scope), but not in request scope. scope = 'request' is missing in those two answers. {831} Question 6; Qn6 .When creating session listeners which are true? (Choose all that apply) A. They are all declared in the DD B. Not all of them must be declared in the DD C. The DD tag used to declare them is . D. The DD tag used to declare them is . E. The DD tag used to declare them is placed within the tag. F. The DD tag used to declare them is placed within the tag. Answers are B and E. Option c is also correct, but it's not selected as an answer. [833] Question 11; Answers given are A,B,D,E,F But, options B and F should not be correct. - Only one instance of will exist within one tag. The deployment descriptor DTD has the following definition for as per servlet spec is - This tag implies that authorization, data integrity and confidentiality security features are all declared for the wen application. And not authentication. Authentication is declared using the tag. As per the servlet spec - The login-config element is used to configure the authentication method that should be used, the realm name that should be used for this application, and the attributes that are needed by the form login mechanism. {841} Question 26; The options marked are B and D. Clearly, those two will not satisfy empty operators and will execute the code inside the tag. Shouldn't the answers be C and E which staisfies the empty operator and hence will execute the code inside tag? the hand written comments correctly mentions that E will satisfy empty operator. {845} Question 34; Answers given are B and D. I agree structure is valid with index.html being under WEB-INF directory.But, since the question also asks about changes necessary to make resources accessible, shouldn't option C also be an answer? {850}Question 47; The answers currently referenced are B and E. For E to be correct, ServletOutputStream needs to be in the javax.servlet package (not java.io). I would think answer C is also correct because the question asks which types "can be used" and a ServletOutputStream is-an java.io.OutputStream. (851) Question 49; Answer given is C. Whereas the answer should be D.Hand written comment agrees with this statement. {863} Question 69; Answer is D, which is wrong because that allows the BEGINNERs to access resources in directory2. B should be the answer.