Errata

Head First Servlets and JSP

Errata for Head First Servlets and JSP, Second Edition

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. If the error was corrected in a later version or reprint the date of the correction will be displayed in the column titled "Date Corrected".

The following errata were submitted by our customers and approved as valid errors by the author or editor.

Color key: Serious technical mistake Minor technical mistake Language or formatting error Typo Question Note Update

Version Location Description Submitted By Date submitted Date corrected
Printed
Page 30
Deployment descriptor

instead of "ISO-8851-1" it should be "ISO-8859-1"

Note from the Author or Editor:
Correct.

Anonymous  Jul 09, 2008  Mar 01, 2011
Printed
Page 122
last line

InputStream input = request.getInputStream();
but in the java doc is :
getInputStream() returns ServletInputStream

Note from the Author or Editor:
While the book is technically correct because the ServletInputStream is a subclass of InputStream, it would be best to use the more specific class in the text. So please change the last line of code to:

ServletInputStream input = getInputStream();

Anonymous  Oct 03, 2010  Mar 01, 2011
Printed
Page 123
First paragraph 5th line

It says: "possible to create a servlet that proceses a..."

It should says "processes" instead.

Note from the Author or Editor:
Change "process" to "handles" like this:

It is also possible to create a servlet that handles a...

German Gonzalez-Morris  Jan 13, 2010  Mar 01, 2011
Printed
Page 186
Attributes are not Parameters - 4th row 3rd column

Replace the existing text in the 4th/3rd cell with:

ServletContext.getInitParameter(String name)
ServletConfig.getInitParameter(String name)
ServletRequest.getParameter(String name)

Also, for consistency replace the existing text in the 4th/2nd cell with:

ServletContext.getAttribute(String name)
HttpSession.getAttribute(String name)
ServletRequest.getAttribute(String name)

Anonymous    Jul 01, 2008
Printed
Page 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.

Replaced the existing text in the 4th/3rd cell with:

ServletContext.getInitParameter(String name)
ServletConfig.getInitParameter(String name)
ServletRequest.getParameter(String name)

Also, for consistency replaced the existing text in the 4th/2nd cell with:

ServletContext.getAttribute(String name)
HttpSession.getAttribute(String name)
ServletRequest.getAttribute(String name)

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

Anonymous    Jul 01, 2008
Printed
Page 217
Answer to Question 1

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

Anonymous    Jul 01, 2008
Printed
Page 217
Answer to Question 1.

Answer states B and C are correct when associated comment (correctly) states (only) answer B is correct.

Unchecked C

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

Anonymous    Jul 01, 2008
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).

Note from the Author or Editor:
Already fixed in the 2nd Edition.

David Bala?ic  Aug 21, 2009  Jul 01, 2008
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?

Note from the Author or Editor:
We never intend to create questions that depended knowledge external to the book's content. If this content did not make it into the book, please accept my apologies. A fix for the lack of content must wait until the next edition.

David Bala?ic  Aug 21, 2009 
Printed
Page 222
Question 15, 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.

Note from the Author or Editor:
Change option C text from "to will change" to "to may change"

Anonymous    Jul 01, 2008
Printed
Page 222
Question 15, 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.

Changed option C text from "to will change" to "to may change"

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

Anonymous    Jul 01, 2008
Printed
Page 222
Question 14 Answer for ServletContext

HFSJ 2nd Edition Third Indian Reprint 2008

I downloaded the Servlet 2.4 api's. Navigate to ServletContext, it doesn't list getContextPath() as one of the methods for ServletContext.

So getContextPath should not be listed against ServletContext.

Note from the Author or Editor:
VALID

Remove "getContextPath" from the center cell of this grid.

Kamal Tripathi  Feb 19, 2009  Oct 01, 2009
Printed
Page 222
answer to question 14, written "note"

"At this point this shouldn't really about memorization..."
should be
"At this point this shouldn't really be about memorization..."

Note from the Author or Editor:
Correct

Michael Angstadt  Jan 17, 2010  Mar 01, 2011
Printed
Page 239
last question

The answer to question "Is URL rewriting handled in a vendor-specif c way?" claims, that the use of ; as a separator is not mandated and that the presence of the "jsessionid=" is optional. This appear to contradict the servlet spec v2.4 chapter 7.1.3. There is says, I quote:

The session ID must be encoded as a path parameter in the URL string. The name of the parameter must be jsessionid.
(end quote)

Path parameters in URL's are encoded by ";" followed by parameter.
So there is not much choice left, besides <classicURL>;jsessionid=<the_id>

On the other hand, the URL/URI RFCs (1738, 2396, 3986) are bit hard to read and one can't be sure if the ";pname=pvalue" parameter format is actual defined standard or not.

Regards,
David

Note from the Author or Editor:
Remove the fourth line "And while Tomcat adds..." from the last paragraph on pg 239.

David Bala?ic  Aug 31, 2009  Mar 01, 2011
Printed
Page 240
"Bang" box, 2nd written "note"

"Don't do this! It's supposed to be a header!"
should be
"Don't do this! It's supposed to be a cookie!"

Note from the Author or Editor:
Correct

Michael Angstadt  Jan 17, 2010  Mar 01, 2011
PDF
Page 249
2nd Answer's Result (Last paragraph) of Chapter 6

IllegalStateException is thrown before it reach the isNew() method on session. Since session.setMaxInactiveInterval(0) will cause the session invalidated immediately, the next line of code session.getAttribute("foo") method will throw IllegalStateException before it reach session.isNew() method.

Note from the Author or Editor:
VALID

Remove the line of code that reads "String foo = (String) session.getAttribute("foo");

On pg 249: also remove that line

Lee Kian Giap  Dec 31, 2008  Oct 01, 2009
PDF
Page 255
The last line of the page is incomplete, seems incomplete, like this 'The se'

The last line in my PDF version of this book is
'chance to get themselves ready for access. The se'

I check the next page (pg.256), there's no continuation for the last line in pg. 255, so it seems to me, that there's incomplete sentence in the last line of pg. 255.

Thank you in advance for checking and correcting this small typo (or formatting issue ?).

Note from the Author or Editor:
Drop the last sentence fragment: "The se"

Anonymous  Mar 16, 2009  Oct 01, 2009
Printed
Page 256
Bang box titled "You do NOT configure session binding listeners in the DD!

Change the title to "You do NOT configure ALL session listeners in the DD!"

Change the "HttpSessionActivationListener" to "HttpSessionAttributeListener" in the text.

Anonymous    Jul 01, 2008
Printed
Page 256
Bang box titled "You do NOT configure session binding listeners in the DD!

Changed the title to "You do NOT configure ALL session listeners in the DD!"

Changed the "HttpSessionActivationListener" to "HttpSessionAttributeListener" in the text.

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

Anonymous    Jul 01, 2008
PDF
Page 261
BeerSessionCounter class example

This class, as written, isn't thread safe. So, the question is whether or not it should be thread safe or whether the container provides the guarantee that listeners aren't called concurrently. Seems like the example/text needs to be augmented either way.

Note from the Author or Editor:
Correct. Add the keyword 'synchronized' to both methods; like this:

public synchronized void sessionCreated(...
public synchronized void sessionDestroyed(...

Anonymous  Feb 22, 2010  Mar 01, 2011
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.

Note from the Author or Editor:
I agree.

O'Reilly: Remove the "cross icon" on the "Some other class" box in the second row / last column.

Anonymous  Sep 26, 2008  Mar 01, 2011
Printed
Page 265
Bottom "handwritten" note

"It returns the old value, not the new one."

I can't find any definite statement in the spec regarding the result of HttpSessionBindingEvent.getValue() for each of the events.

But I tested on Tomcat 5.5.27, Tomcat 6.0.18 and Glassfish V2 UR2 Final Build.

The result are consistent for these containers and the statement "returns the old value" is mostly WRONG:

attributeAdded(): value is new value (rather than old value == null)
attributeReplaced(): value is always the NEW value
valueUnbound(): "this" is always the old value. event's value is null iff the attribute has been replaced, or the old value if the attribute has been removed.
attributeRemoved(): indeed the event's value is the OLD value (rather than null)

Who the heck should memorize that?

Here's the sequence that I tested (set/removeAttribute statement plus generated events):

session.setAttribute("dog", new Dog(1)):
Dog{no=1}.valueBound: event.getValue()=Dog{no=1}
AttributeListener.attributeAdded: event.getValue()=Dog{no=1}

session.setAttribute("dog", new Dog(2)):
Dog{no=2}.valueBound: event.getValue()=Dog{no=2}
Dog{no=1}.valueUnbound: event.getValue()=null
AttributeListener.attributeReplaced: event.getValue()=Dog{no=2}

session.removeAttribute("dog"):
Dog{no=2}.valueUnbound: event.getValue()=Dog{no=2}
AttributeListener.attributeRemoved: event.getValue()=Dog{no=2}

Note from the Author or Editor:
VALID

The spec says "Returns the value of the attribute that has been added, removed or replaced. If the attribute was added (or bound), this is the value of the attribute. If the attribute was removed (or unbound), this is the value of the removed attribute. If the attribute was replaced, this is the old value of the attribute."

This is about as succinct as I think it could be said. So...
The complete handwritten note should be rewritten as: "The getValue() returns the object value of the attribute that triggered the event. If the attribute was added (or bound), this is the value of the attribute. If the attribute was removed (or unbound), this is the value of the removed attribute. If the attribute was replaced, this is the old value of the attribute."

Anonymous  Sep 26, 2008  Oct 01, 2009
279
15 th question

For the question no 15, you people have given 'A' and 'C' are the correct answers. But in the reality when we try to implement this scenario(like creating a class which extends HttpSessionAttributeListener and another class which extends HttpSessionBindingListener.Declared session time out in DD then we added logs in each Listener class, once session invalidated after the time specified in DD, the log is showing clearly that it has called the sessionDestroyed(), valueUnbound() and also attributeRemoved() methods).

This states that option 'E' also correct answer. Please check this.

Sorry if i'm wrong.

Note from the Author or Editor:
This is a little tricky. Yes, it is true that all attributes are removed when a session is terminated (and thus the attributeRemoved() method is called); it is not the intent of the question. Likewise, option C should not be selected.

uday kumar maddigatla  Mar 04, 2009  Mar 01, 2011
Printed
Page 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.

Note from the Author or Editor:
VALID

Change the 12th line of the first code example to:
<url-pattern>/TestInit.jsp</url-pattern>

Anonymous  May 19, 2008  Jul 01, 2008
Printed
Page 310
url-pattern tag

Line 12 of code

the url-pattern tag contains "TestInif.jsp", which appears to be a typo.

Changed "TestInif.jsp" to "TestInit.jsp"

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

Anonymous    Jul 01, 2008
Printed
Page 310
Declaration code example at the bottom, 5th line

This is invalid code in a JSP:
ServletContext ctx = getServletContext();
The spec only guarantees that the JSP implementation class implements JspPage which extends Servlet, but _not_ GenericServlet (which implements ServletConfig and contains the implementation of getServletContext())."

So the correct line would be
ServletContext ctx = sConfig.getServletContext();

(The original code does indeed work on Tomcat, but that's merely an implementation side effect.)

Note from the Author or Editor:
VALID

Make the recommended change.

Anonymous  Oct 03, 2008  Oct 01, 2009
PDF
Page 337
Question 4

Does jspInit() have direct acces to the ServletContext? The spec it says "When method is called all the methods in servlet, including get-
ServletConfig are available". I'm guesing option C should not be correct based on what the spec says

Note from the Author or Editor:
This method is only meant to be called by the container. But I suppose that some other method in the JSP *could* call this method, although that would contradict the contract of that method. From a cert-exam perspective Option-C is not "always correct under all conditions."

Rewrite Option-C as "It is only called once by the Container."

Anonymous  Sep 03, 2009  Mar 01, 2011
Printed
Page 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.

Note from the Author or Editor:
MOSTLY VALID, BUT SUBTYPE MIGHT BE A SUB-INTERFACE WHICH IS *NOT* VALID IN THIS CONTEXT.

Change last sentence to "So that means that /class/ must be a concrete implementation of the /type/."

Anonymous  May 21, 2008  Jul 01, 2008
Printed
Page 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.

MOSTLY VALID, BUT SUBTYPE MIGHT BE A SUB-INTERFACE WHICH IS *NOT* VALID IN THIS CONTEXT.

Changed last sentence to "So that means that /class/ must be a concrete implementation of the /type/."
--------------------------------------------------------------------

Anonymous    Jul 01, 2008
Printed
Page 358
first paragraph

The second sentence states there are 3 code examples but only 2 examples are provided.

Note from the Author or Editor:
VALID

Change "three" to "two" in the fourth line.

Anonymous  May 21, 2008  Jul 01, 2008
Printed
Page 358
first paragraph

The second sentence states there are 3 code examples but only 2 examples are provided.

Changed "three" to "two"

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

Anonymous    Jul 01, 2008
Printed,
Page 359
Code example at the bottom of the page using scripting inside a standard action

When testing in Eclipse the following JSP piece:
<jsp:useBean id="person" type="foo.Person" class="foo.Employee">
<jsp:setProperty name="person" property="name"
value="<%= request.getParameter("userName") %>" />
</jsp:useBean>

I get the following error in the console output: org.apache.jasper.JasperException: /TestBean.jsp(12,58) Attribute value request.getParameter("username") is quoted with " which must be escaped when used within the value

In order to fix the error, you need to escape the "username" parameter name, so the previous code should be:
<jsp:useBean id="person" type="foo.Person" class="foo.Employee">
<jsp:setProperty name="person" property="name"
value="<%= request.getParameter(\"userName\") %>" />
</jsp:useBean>

Note from the Author or Editor:
Rewrite the setProperty code like this:

<jsp:setProperty name='person' property='name'
value='<%= request.getParameter("userName") %>' />

Abel Morelos  Jan 22, 2010  Mar 01, 2011
Printed
Page 383
JSP code, EL expression

I think the line

${pageContent.currentTip}

should be

${pageContext.currentTip}. Also 3 occurences on page 384

Note from the Author or Editor:
The 'pageContent' was meant to be a wrapper object, but the text never made that clear.

Rewrite the third line of code as:
${currentTip}

Anonymous  Aug 15, 2010  Mar 01, 2011
Printed
Page 397
paragraph at the top of the page

It states that the answers to the questions are printed upside down at the bottom of the page. They are not. The answers are listed on the next page.

Note from the Author or Editor:
Right. Remove the last two sentences in this paragraph.

Michael Angstadt  Jan 17, 2010  Mar 01, 2011
Printed
Page 412
Subheader "The included header that USES (...)"

The page shows a code that uses a jsp standard action to include a file named "Header.jsp", but "Header.jspf" is mentioned in the following subtitle:

"The included header that USES the new param ("Header.jspf")"

Remove the trailing "f" from "Header.jspf".

Note from the Author or Editor:
VALID

Delete the 'f' character on the end of "Header.jspf"

Anonymous  Nov 26, 2008  Oct 01, 2009
PDF
Page 420
Answer for the number 1 exercise

"<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? />

Look at this standard action:
What happens if the servlet code looks like: 1
foo.Person p = new foo.Employee();
p.setName(?Evan?);
request.setAttribute(?person?, p);

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

The answer is wrong since the attribute scope is defined as request in the <jsp:useBean>. The correct would be "Prints Name is Evan."

Note from the Author or Editor:
VALID

This exercise has dogged us from the beginning. It will be complete replaced in the next edition.

Anonymous  Nov 16, 2008 
Printed
Page 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.

Note from the Author or Editor:
Add a checkmark on Option C

Anonymous    Jul 01, 2008
Printed
Page 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.

Added a checkmark on Option C

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

Anonymous    Jul 01, 2008
Printed
Page 443
Last paragraph

Two references are made to escapeXML. The correct parameter name is escapeXml.

Note from the Author or Editor:
Yes, replace "escapeXML" with "escapeXml"

Anonymous  Feb 25, 2009  Oct 01, 2009
PDF
Page 445
First Paragrah, second example

Hello,

On page 445 that discusses how null values are rendered, there is a problem with the second example. The example indicates that for JSP expressions if the variable is null, the output will contain nothing:

Quote:
"A JSP expression tag prints nothing if user is null:
<b>Hello <%= user %>.</b>

Renders as <b>Hello .</b>"

Although this is true for ELs, it is not this way for JSP expressions. For the given example, the output will be "Hello null."

Best Regards,

Horatiu

Note from the Author or Editor:
VALID

The second box should contain the text "<b>Hello null.</b>"

Anonymous  Oct 13, 2008  Oct 01, 2009
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>

Note from the Author or Editor:
This should have been fixed in the previous re-print; but if not...

O'Reilly: the text in the middle box should read "<b>Hello null.</b>"

Anonymous  Aug 17, 2008  Sep 01, 2010
Printed
Page 463

"The JSP with the <jsp:import>" should be
"The JSP with the <c:import>"

Note from the Author or Editor:
Change title of step 1 as described.

Anonymous  Nov 09, 2009  Mar 01, 2011
Printed
Page 475
written "note" at the bottom of the page

It states that the book doesn't cover <c:out>. This is false. <c:out> is covered on p.443-5.

Note from the Author or Editor:
Right you are. We didn't cover the c:out tag in the 1st Edition but added it in the 2nd Edition.

Rewrite the last statement in the hand-written note as:
We also didn't cover <c:redirect> but that...

Michael Angstadt  Jan 17, 2010  Mar 01, 2011
Printed
Page 484
3rd Paragraph

The fourth sentence states "The Container could care less...". While I understand this atrocious grammar has become commonplace with lazy-speak, it should be written correctly.

This should be corrected to "The Container couldn't care less...".

Note from the Author or Editor:
OK

Start the fourth sentence as "The Container couldn't care less..."

Anonymous  Feb 16, 2009  Oct 01, 2009
Printed
Page 484
3rd paragraph, 6th-7th lines

"Su could have named the JSTL..."
should be
"Sun could have named the JSTL..."

Note from the Author or Editor:
Correct. Also remove the extraneous space character on the next line before the word "could"

Michael Angstadt  Jan 17, 2010  Mar 01, 2011
PDF
Page 490
diagram

The arrow from "<rtexprvalue>true</rtexprvalue>" should point to "${foo}", not "/>"

Note from the Author or Editor:
Correct.

O'Reilly: Move the <mine:advice ... /> code about 1/8 inch to the right. Make sure the move the hand-drawn underlines as well.

pcchee  Apr 16, 2009  Mar 01, 2011
Printed
Page 491 & 495
Question 1, option D

Option D references tag files which aren't mentioned until the next chapter and the role of TLDs in Tag files isn't explored until page 509.

Note from the Author or Editor:
VALID

Drop Option D here and on pg 495.

Anonymous  Feb 22, 2009  Oct 01, 2009
Printed
Page 508
Paragraphs 2 & 3

The discussion on scripting in Tag files is very confusing. The first sentence of the third paragraph reads "In fact, Tag File bodies are never allowed to have scripting, so it's not an option."

Using the term 'Tag File bodies' makes it sound like you mean you can not use scripting in the *.tag file, instead of the body of the tag reference in the JSP that uses the tag.



Note from the Author or Editor:
OK

For clarification the first sentence in the third paragraph should start with "In fact, the bodies of Tag File tags are never..."

Anonymous  Feb 22, 2009  Oct 01, 2009
Printed
Page 533
second line

(also in PDF)
The second line begins with: areevaluated when

A space is missing: are evaluated

David Bala?ic  Aug 27, 2009  Oct 01, 2009
Printed
Page 533
1st paragraph, 2nd line

"areevaluated"
should be
"are evaluated"

Note from the Author or Editor:
Correct - this was fixed in the second edition.

Michael Angstadt  Jan 17, 2010  Sep 01, 2010
Printed
Page 565
Top of Page

The chart is labeled "Lifecycle METHODS for Classic tag methods". I found this very confusing and the instructions were not helpful.

It all became very clear when I turned the page and the answer chart was labeled "Lifecycle RETURN VALUES for Classic tag methods".

Note from the Author or Editor:
Agreed. In the next printing we should provide the answers for a few of the cells in the chart as a starting point.

Anonymous  Feb 22, 2009 
Printed
Page 579 & 590
Question 2 Option E.

jsp:invoke is Option E for Question 2. I can not find where jsp:invoke is mentioned in the book, especially in Chapter 10, which is the chapter this test is covering.

If it is in the book and I just missed it, sorry.

Note from the Author or Editor:
VALID

The jsp:invoke std action is not mentioned in the book so no question should refer to it.

Drop Option E on this page and pg 590.

Anonymous  Feb 22, 2009  Oct 01, 2009
Printed
Page 580
Line 11 in code of question no 3

The line 11 in the code in self test question 3 of chapter 10 shows int as the return type of doTag method while it is void. Same mistake on page 591

Note from the Author or Editor:
Change on these two pages the "int" into "void" like this:

11. public void doTag() throws JspException, IOException {

Ankit Garg  Nov 08, 2009  Mar 01, 2011
Printed
Page 582
Chapter 10, Question 6

Chapter 10 - Question 6 - findAncessorWithClass().

This method is just barely touched on on page 574, without giving too much more than a signature and a brief description of what it does.

Furthermore, the last sentence on page 574 states "You will not be tested on any details of using findAncessorWithClass(). All you need to know for the exam is that it exists!".

Given this, question 6 is pretty detailed.

Maybe this question was a leftover from the first edition.

Note from the Author or Editor:
VALID, the book does not cover this method in the level of detail needed for this question.

Drop this item here and on pg 593.

Anonymous  Feb 22, 2009  Mar 01, 2011
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.

Note from the Author or Editor:
Good point.

O'Reilly: if it will fit (in the upper-right corner on pg 502) add a hand-written note: "You could also use the tagx file extension; if the content is valid XML." and include a hand-drawn arrow pointing to the "Header.tag" labeled file icon.

Josnel Maraver  Jun 03, 2009  Mar 01, 2011
Printed
Page 586 & 597
Question 14 Option E

Chapter 10 - Question 14 - Option E.

getAttributesScope("key") is not mentioned in the book. Chapter 8 does have a note to visit the API to see the getters for PageContext, but does not state that all of the getters should be memorized.

In short, the questions in this book should only cover information presented in this book. The exam is a different animal, but book questions should only test on book information.

Note from the Author or Editor:
VALID

Remove Option E from this question here and on pg 597.

Anonymous  Feb 22, 2009  Oct 01, 2009
Printed
Page 588
Question 19, answers B and D

(also PDF version)

Answer B uses the jsp:invoke, the author already said for page 579: "The jsp:invoke std action is not mentioned in the book so no question should refer to it."

Answer D uses the <%@ variable %> tag, which is also not mentioned in the book.

Note from the Author or Editor:
Right. We will rewrite this question in a future revision.

David Bala?ic  Aug 28, 2009 
Printed
Page 597
Question 15

Question 15 on Page 597 has option E not checked because it is not the correct answer. However, it says option E is invalid because getAttributesScope("key") does not exist in JspContext. This is WRONG. JspContext does have getAttributesScope("key"). Although it is an abstract method, the nature of the question implies a JspContext implementer. Only in the previous question it says PageContext contains getAttributesScope("key"). And PageContext is a subclass of JspContext

Note from the Author or Editor:
Correct.

Change the comment on OPtion E to "Option E is invalid because this method retrieves the attribute; it only tells you which scope it resides."

Suhas Wadadekar  Jan 28, 2010  Mar 01, 2011
Printed
Page 622
2rd paragraph, line 3

(and PDF)

The third line in the second paragraph and with: configur

It should be : configure

David Bala?ic  Aug 28, 2009  Oct 01, 2009
Printed
Page 622
2nd paragraph, 3rd line

"You configur"
should be
"You configure"

Note from the Author or Editor:
Corrrect

Michael Angstadt  Jan 17, 2010  Sep 01, 2010
Printed
Page 624
last answer

The book says :
Container choice:
When no files from the <welcome-file-list> are found, the
behavior is vendor-specific. Tomcat shows a directory list-
ing for the newMember directory (which shows "foo.txt").
Another Container might show a 404 Not Found error.

That does not seem to be true. Tomcat 5.5.28 returns a 404 error in this case. (at least on Windows XP Pro SP3)

Note from the Author or Editor:
OK.

Let's flip the last two statements as: "Tomcat shows a 404 Not Found error. Another container could show a directory listing for the newMember directory, which would show the 'foo.txt' file."

David Bala?ic  Aug 28, 2009  Mar 01, 2011
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

Note from the Author or Editor:
Agreed

O'Reilly: Change text to "Any non-negative number means..."

Anonymous  Sep 15, 2008  Mar 01, 2011
Printed
Page 628
BANG section

You can read:

"(...)And what if there's more than one servlet with a <load-on-startup> of 4? The Container loads servlets with the same value in the order in which the servlets are declared in the DD."

The specs for Servlets 2.4 and 3.0 says in sections 13.4 (10 - servlet Element) and 14.4 (10 - servlet Element) respectively that:

"(...)The container may choose the order of loading of servlets with the same load-on-startup value."

Note from the Author or Editor:
Replace the last statement in the "BANG" box from "The Container loads servlets..." to "The Container may choose the order of loading of servlets with the same load-on-startup value."

Piotr Nowicki  Jan 16, 2011  Mar 01, 2011
Printed
Page 664
handwritten note adjacent to "SERVLET-SPECIFICATION:"

The note says "When it's time for authorization... information to whatever <role-name>'s it find in your DD's <security-role> elements."

This note misuses the apostrophe. Actually, it uses the apostrophe correctly, then incorrectly, then correctly again. The plural of <role-name> is <role-name>s.

Note from the Author or Editor:
OK

Rewrite like this: "will map it's vendor-specific "role" information to whatever <role-name> elements it finds in the DD's <security-role> elements."

Thomas Kennedy  Apr 05, 2010  Mar 01, 2011
Printed
Page 684
Bottom

Bottom of page 684:

"NOTE: although not guaranteed by the spec, in practice virtually every Container uses SSL for guaranteed transport, which means that both INTEGRAL and CONFIDENTIAL do the same thing?either one gives you
both confidentiality and integrity. Since you can have only one <user-data-constraint> per <security-constraint>, some people recommend you use CONFIDENTIAL, but again, it will probably never matter in practice, unless you move to a new (and unusual) Container that doesn't use SSL."

The last sentence should be changed to more clearly indicate that you are talking about a container that doesn't use SSL for guaranteed transport, not a container that doesn't use SSL at all.

SSL is required by the spec, although you don't mention that specifically anywhere but test on it in question 14 on page 834.

Note from the Author or Editor:
SURE

Change the end of the last sentence to "to a new Container that doesn't use SSL for guaranteed transport."

Anonymous  Feb 23, 2009  Mar 01, 2011
Printed
Page 719
BANG section

In the first sentence you can read:

"(...)an example of using a Decorator pattern (although it is also sometimes called Wrapper) pattern"

The word pattern is written twice or the second one is not within the parentheses. I think it should be more like:

"(...)an example of using a Decorator pattern (although it is also sometimes called Wrapper pattern)"

or

"(...)an example of using a Decorator pattern (although it is also sometimes called Wrapper)"

Note from the Author or Editor:
Agreed; please put the last "pattern" within the parenthesis.

Pedro Kowalski  Jan 16, 2011  Mar 01, 2011
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

Note from the Author or Editor:
Correct

O'Reilly: This requires two changes. First change the first if statement to:
if ( (streamUsed != null) && (streamUsed == pw) ) {
Second, change the third if-statement (in the getWriter method) to:
if ( (streamUsed != null) && (streamUsed == servletGzipOS) ) {

Anonymous  Sep 15, 2008  Mar 01, 2011
Printed
Page 759
Code example in middle

The code example handles a caught RemoteExeption by throwing a new CustomerException instead. The "handwritten" comment states that the code is supposed to WRAP the caught exception in the higher level one. If that is the case, the RemoteException should probably passed as the constructor parameter of the CustomerException.

Note from the Author or Editor:
Correct.

Rewrite the fourth line of code as:
throw new CustomerException(re);

Anonymous  Jan 28, 2010  Mar 01, 2011
Printed
Page 784
Question 3

The correct answer to question 3 is C - "Composite Delegate".
But "Composite Delegate" is not mentioned anywhere in the book.

Similar for question 2.

Note from the Author or Editor:
Right, we should not have a question that relies on information outside of the book. We will replace this question with a new one in the future.

David Bala?ic  Aug 31, 2009 
Printed
Page 793 & 829
Question 3, answer A

Answer A is not correct because the class does not need to have a size member. Is does need to have a setter method.

Note from the Author or Editor:
VALID

Rewrite Option A as "The class should have a setter method called setSize." With 'setSize' in bold Courier.

Make the same change on pg 829.

Anonymous  Oct 10, 2008  Mar 01, 2011
Printed
Page 794, 830
Question 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.

Note from the Author or Editor:
This is correct. The text [scope="request"] must be added to the open jsp:useBean tag for *all* options (not just C&D, because this is really an invariant to the question). Make this change on pg 794 as well.

Anonymous  May 20, 2008  Jul 01, 2008
Printed
Page 794

This is correct. The text [scope="request"] must be added to the open jsp:useBean tag for *all* options (not just C&D, because this is really an invariant to the question). Make this change on pg 794 as well.

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

Anonymous    Jul 01, 2008
Printed
Page 794 & 830
Final Mock Exam, question 4, answer A

The '/' character should be placed at the very end of the tag.

<jsp:useBean id="user" type="foo.User"/ scope="request">
should be
<jsp:useBean id="user" type="foo.User" scope="request"/>

Also applies to p.830.

Note from the Author or Editor:
Correct; please make this change.

Michael Angstadt  Jan 17, 2010  Mar 01, 2011
Printed
Page 810 & 846
Final Mock Exam, question 36

The first line of the question is confusingly worded.

"Given in a JSP page, the line:"
should be something like
"Given the following line of code from a JSP page:"

Note from the Author or Editor:
OK, rewrite the first line as:


Given the following line of code in a JSP page:

Michael Angstadt  Jan 17, 2010  Mar 01, 2011
Printed
Page 814
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.

Note from the Author or Editor:
Change option C to "javax.servlet.OutputStream" and change option E to "javax.servlet.ServletOutputStream".

These changes make option E valid and option C invalid, as it should be.

Anonymous  Jan 21, 2009  Jul 01, 2008
Printed
Page 814
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.

Change option C to "javax.servlet.OutputStream" and change option E to "javax.servlet.ServletOutputStream". These changes make option E valid and option C invalid, as it should be.

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

Anonymous    Jul 01, 2008
Printed
Page 819, 855
Q55, line 02.

HFSJ 2nd Ed., printed March 2008

At page 819 and 855 the lines

02. String TITLE = "Welcome to my page";

are wrong, correct are

02. String GREETING = "Welcome to my page";

Note from the Author or Editor:
VALID

Change all occurrences of "TITLE" with "GREETING"
Also on pg 855.

Anonymous  Nov 25, 2008  Mar 01, 2011
Printed
Page 824
Answers

There aren't answer for question 66 in Final Mock Exam.

Note from the Author or Editor:
This should have been fixed in the previous re-print. But if not...

O'Reilly: Copy the "options content" on pg 861 and paste it at the bottom of pg 824. DO NOT COPY the checkmark and hand-write note about the answer.

Anonymous  Aug 25, 2008  Mar 01, 2011
Printed
Page 824
Question 66

There are no answers given.

Note from the Author or Editor:
VALID

Copy the Options on pg 860 but remove the checkmarks and hand-written comments to the empty space at the bottom of pg 824.

Anonymous  Oct 12, 2008  Mar 01, 2011
Printed
Page 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.

This is correct. The text [scope="request"] must be added to the open jsp:useBean tag for *all* options (not just C&D, because this is really an invariant to the question). Make this change on pg 794 as well.

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

Anonymous    Jul 01, 2008
Printed
Page 831
Question 6

Answers are B and E.
Option C is also correct, but it's not selected as an answer.

Note from the Author or Editor:
Add a checkmark to option C

Anonymous    Jul 01, 2008
Printed
Page 831
Question 6

Answers are B and E.
Option C is also correct, but it's not selected as an answer.

Added a checkmark to option C

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

Anonymous    Jul 01, 2008
Printed
Page 832
Ques. 8

the question 8 asks which implicit object can access attributes from ServletContext

the answer given is only application

but option C request can also access its attributes in this way-

request.getSession().getServletContext().getAttribute("name");

So answer shall be C,D

Note from the Author or Editor:
Correct. Please check option C and rewrite the note as: "Option C is correct because you can access the ServletContext using the HttpSession."

Parth Tiwari  Aug 19, 2010  Mar 01, 2011
Printed
Page 833
Question 11

Answers given are A,B,D,E,F
But, options B and F should not be correct.
- Only one instance of <auth-constraint> will exist within one <security-constraint> tag. The deployment descriptor DTD has the following definition for <security-constraint> as per servlet spec is <!ELEMENT security-constraint (web-resource-collection+, auth-constraint?, user-data-constraint?)> - 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 <login-config> 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. <!ELEMENT login-config (auth-method?, realm-name?, form-loginconfig?)>

Note from the Author or Editor:
Remove the checkmark from options B and F

Anonymous    Jul 01, 2008
Printed
Page 833
Question 11

Answers given are A,B,D,E,F
But, options B and F should not be correct.
- Only one instance of <auth-constraint> will exist within one <security-constraint> tag. The deployment descriptor DTD has the following definition for <security-constraint> as per servlet spec is <!ELEMENT security-constraint (web-resource-collection+, auth-constraint?, user-data-constraint?)> - 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 <login-config> 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. <!ELEMENT login-config (auth-method?, realm-name?, form-loginconfig?)>

Removed the checkmark from options B and F

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

Anonymous    Jul 01, 2008
Printed
Page 833
Question 11, answer B

Answer B states that multiple instances of <auth constraint> can exist within <security constraint>. This is not true.

Note from the Author or Editor:
VALID

Option B is incorrect and should not be checked.

Anonymous  Oct 10, 2008  Sep 01, 2010
Printed
Page 834
Question 14

I could not find that:
- The book states that a Java EE container must support HTTP cookies.
- The book states that a Java EE container must support SSL.

Note from the Author or Editor:
VALID

This question is based on information that is not presented in the book nor is on the SCWCD exam. It should be rewritten.

Anonymous  Oct 12, 2008 
Printed
Page 834 & 798
Question 14 Option C

Option B: "Java EE containers must support URL rewriting." This option is shown as being false and the following note "-Option B URL rewriting is almost always used as the fallback when cookies are not available, but it's NOT a requirement for containers."

From the text:
Page 237
URL rewriting: something to fall back on
"If the client won?t take cookies, you can use URL rewriting as a backup. Assuming you do your part correctly, URL rewriting will always
work..."

Page 239
Q: Is URL rewriting handled in a vendor-specific way?
A: Yes, URL rewriting is handled in a vendor-specific way. Tomcat
uses a semicolon ?;? to append the extra info to the URL. Another
vendor might use a comma or something else."

Servlet Spec 2.4:
SRV.7.1.3 URL Rewriting
URL rewriting is the lowest common denominator of session tracking. When a client will not accept a cookie, URL rewriting may be used by the server as the basis for session tracking. URL rewriting involves adding data, a session ID, to the URL path that is interpreted by the container to associate the request with a session. The session ID must be encoded as a path parameter in the URL string. The name of the parameter must be jsessionid. Here is an example of a URL containing encoded path information:

http://www.myserver.com/catalog/index.html;jsessionid=1234

Conclusion: Option B is correct.

Note from the Author or Editor:
The mock exam question 14 on pg 834 is formally correct because the Servlet spec says "URL rewriting may be used by the server". The use of the word "may" means that URL rewriting is not required by the spec.

The content on pg 237 should be rewritten to make it clear that URL rewriting "will NOT always work" if the Container does not support it. This is unfortunately because most modern Containers *do* support it; so I would rather not muddy the message of this section of the book.

Instead, i would recommend that we change to the wording of Option B to read "Java EE container may support URL rewriting" and check it. Likewise on pg 798.

Anonymous  Feb 23, 2009  Mar 01, 2011
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.

Note from the Author or Editor:
OK

Check Option B and edit the note as "...is always available as the fallback..."

Anonymous  Aug 13, 2009  Mar 01, 2011
Printed
Page 839
Question 22

Option A is "Only HTTP GET is idempotent." The answer note states "-Option A: if a form doesn't explicitly declare a method, GET is assumed." This note actually applies to Option B.

Note from the Author or Editor:
VALID

Change "Option A" to "Option B" in the note and move it down to point to Opt B.

Anonymous  Feb 23, 2009  Mar 01, 2011
Printed
Page 841
Question 26

Only books.clear(); and books = null; will cause the text within the c:otherwise tag to display.
Therefore answers C and E are correct instead of answers B and D.

Note from the Author or Editor:
VALID

Instead of B and D, C and E should be checked.

Anonymous  Oct 12, 2008  Jul 01, 2008
Printed
Page 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 <c:when> tag. Shouldn't the answers be C and E which staisfies the empty operator and hence will execute the code inside <c:otherwise> tag? the hand written comments correctly mentions that E will satisfy empty operator.

Instead of B and D, C and E should be checked.

Placed checkmarks in C & E and deleted checkmarks from B & D

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

Anonymous    Jul 01, 2008
Printed
Page 841
Answers for question 26

The wrong answers are ticked for the question. The explanations correctly state that A,B,and D add something to the list, making it NOT empty.
This will cause the 'when' clause to execute and not the 'otherwise'. Therefore answers C and E should be ticked not B and D.

Note from the Author or Editor:
VALID

These options should be checked: C and E.

Anonymous  Oct 08, 2008  Sep 01, 2010
Printed
Page 843
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/>

Answer D (the selected answer)

D: If the second <auth-constraint> tag is removed, the constrained
resource can be accessed by both roles.

Is wrong and answer F:

F: If the second <auth-constraint> tag is removed, the constrained
resource can be accessed only by student users.

Is the correct answer.

The book is wrong.

Note from the Author or Editor:
VALID

Remove the checkmark from Option D and put it on Option F.

Anonymous  Feb 24, 2009  Mar 01, 2011
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!

Note from the Author or Editor:
Agreed. While it is not recommended to override the HttpServlet.service method; it certainly can be done. This question is poorly written and should be replaced. Even Option A is not completely valid; although there are extremely few cases where you would need a servlet ctor.

O'Reilly: For now just remove the check on Option E.

Anonymous  Sep 06, 2008  Mar 01, 2011
Printed
Page 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? THE WORDING OF THE STEM FORCES OPTION C TO BE VALID

Note from the Author or Editor:
Add a checkmark to option C.

Change the note for option C to "Option C: index.html must be outside of the WEB-INF/ directory to be accessible."

Anonymous    Jul 01, 2008
Printed
Page 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? THE WORDING OF THE STEM FORCES OPTION C TO BE VALID

Added a checkmark to option C.
Changed the note for option C to "Option C: index.html must be outside of the WEB-INF/ directory to be accessible."

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

Anonymous    Jul 01, 2008
Printed
Page 846
Question 37 answer E

Question 37 states:

You are tasked with adding several security features to your company?s Java EE web application. Specifically, you need to create several classes of users and based on a user?s class, you need to restrict them to use only some of the application?s pages. In order to restrict access, you must determine that users are who they say they are.

Which are true? (Choose all that apply.)

A. If you need to verify that users are who they say they are, you must use the application?s deployment descriptor to implement that requirement.
B. Java EE?s authorization capabilities should be used to determine that users are who they say they are.
C. In order to help you determine that users are who they say they are, you can use the deployment descriptor?s <login-config> tags.
D. In order to help you determine that users are who they say they are, you can use the deployment descriptor?s <user-data-constraint> tags.
E. Depending on the approach you use, determining that users are who they say they are might require including a "realm".

Answer E is one of the correct answers, but the book never discusses how to include a realm in order to provide the authentication necessary. Realm is shown in several examples and is defined as an overloaded term in security, but nothing is ever discussed about including realm-name in the web.xml login-config.

Note from the Author or Editor:
Agreed, option E is a vendor-specific feature and not part of the SCWCD exam and not covered in the book.

Remove option E here and on pg 810.

Anonymous  Feb 24, 2009  Mar 01, 2011
Printed
Page 847 & 811
Question 39 - Answer D

The question reads:
Given req is a reference to a valid HttpServletRequest, and:
13. String[] s = req.getCookies();
14. Cookie[] c = req.getCookies();
15. req.setAttribute("myAttr1", "42");
16. req.setAttribute("myAttr2", 42);
17. String[] s2 = req.getAttributeNames();
18. String[] s3 = req.getParameterValues("attr");

Which lines of code will not compile? (Choose all that apply.)
A. line 13
B. line 14
C. line 15
D. line 16
E. line 17
F. line 18

The soultion says that Answer D is not correct. "-Option D: setAttribute() takes a String and an Object, and as of Java 5, 42 can be boxed to an Object."

While this may be true for Java 5, this exam does not test on Java 5 as noted on page xxviii of the book:

"About the SCWCD (for Java EE 1.5) exam
The updated SCWCD exam is called ?Sun Certified Web Component Developer for the Java Platform, Enterprise Edition 5? (CX-310-083), but don?t get confused by the title. The updated exam is still designed for Java EE v1.4 and for the servlet v2.4 and JSP v2.0 specifications."

Which means autoboxing does not exist and Answer D IS correct. Line 16 will not compile.

Note from the Author or Editor:
Agreed. Drop option D and line 16 from the question here and on pg 811

Anonymous  Feb 24, 2009  Mar 01, 2011
Printed
Page 848 & 812
Question 41

Options C is wrong. It seems to have back-quote and then single-quote around the word personalChecking.

C. <c:if test="${account[`personalChecking']}">Checking
that fits your lifestyle.</c:if>

The beginning and ending quotes are supposed to be the same no matter where they are nested. It should be single-quoted in both places before and after the word personalChecking.

Note from the Author or Editor:
Yes, the back-quote should be changed to a single-quote.
Furthermore, there should be an additional open-paren in the Java code of the IF-stmt in the stem of the question.

Anonymous  Mar 27, 2009  Mar 01, 2011
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.

Note from the Author or Editor:
This requires more research and if the reader is correct (I suspect so), then this item needs to be rewritten.

Anonymous  Sep 07, 2008 
Printed
Page 850
Question 45

In line 15 of the shown code, you can read:

RequestDispatcher rd = request.RequestDispatcher("my.jsp");

I assume, that the "get" in the method name was lost and it supposed to be:

RequestDispatcher rd = request.getRequestDispatcher("my.jsp");

Note from the Author or Editor:
Correct. (and on pg 814)

Piotr Nowicki  Feb 27, 2011 
Printed
Page 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.

Note from the Author or Editor:
VALID

Change option C to "javax.servlet.OutputStream" and change option E to "javax.servlet.ServletOutputStream". These changes make option E valid and option C invalid, as it should be.

Make these changes also on pg 814.

Anonymous  May 19, 2008  Jul 01, 2008
Printed
Page 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.

Change option C to "javax.servlet.OutputStream" and change option E to "javax.servlet.ServletOutputStream". These changes make option E valid and option C invalid, as it should be.

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

Anonymous    Jul 01, 2008
Printed
Page 850
Question 47

The getOutputStream method returns a javax.servlet.ServletOutputStream. The java.io.ServletOutputStream mentioned in answer E does not exists.

Note from the Author or Editor:
VALID

Change "java.io" in Option E to "javax.servlet"
Also on pg 814.

Anonymous  Oct 12, 2008  Sep 01, 2010
Printed
Page 851
Answers for question 49

Again, wrong answer ticked. It should be D not C because 'jsp' is a reserved keyword. Explanation are again correct, just the tick is the wrong box.

Note from the Author or Editor:
VALID

Move the checkmark to option D

Anonymous  Oct 08, 2008  Jul 01, 2008
Printed
Page 851
Question 49

Answer given is C. Whereas the answer should be D. Handwritten comment agrees with this statement.

Moved the checkmark to option D

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

Anonymous    Jul 01, 2008
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.

Note from the Author or Editor:
I reluctantly agree. This question should be rewritten for the next Edition. The whole structure of the question depends upon a java.io.IOException being thrown but it is not clear. Furthermore, there is not "invalid" about the DD snippet shown so option A is not correct.

Riken Shah  Jul 21, 2009 
Printed
Page 857 & 821
Question 60 Option D

Question 60:

When comparing servlet initialization parameters to context initialization parameters, which are true for both? (Choose all that apply.)

D. Both can be directly accessed from a JSP.

Option D is marked as not true with the following explanation:

"-Option D: only context params can be directly accessed from JSPs."

JSP's have a config impicit object which can be used to access the init params for it's ServletConfig. ServletConfig.getInitParameter(String).

Option D IS correct as written.


Note from the Author or Editor:
Option D should be rewritten as "Both can be directly accessed from a JSP using the Expression Language."

This change must also be done on pg 821.

Anonymous  Feb 25, 2009  Mar 01, 2011
Printed
Page 860
Final Mock Exam Q65, Option C

The annotation on Option C states "If nothing else, doFilter() must invoke chain.doFilter()". This is not true. You can choose to block the request by not making the call to invoke the next entity. In this case, the filter is responsible for filling out the response. This is stated on the Sun site (http://java.sun.com/products/servlet/Filters.html) and also earlier in the book on P735 Q5 answer E.

Note that option C should STILL be checked, though, as you will EITHER have to invoke chain.doFilter() OR fill out the response.

Note from the Author or Editor:
Valid enough.

Rewrite the note by Option C to "Option C: you need to either invoke chain.doFilter() or generate an appropriate response."

Nige Wheeler  May 05, 2010  Mar 01, 2011
Printed
Page 863
Question 69

Answer D is not correct. Answer B is correct.

Note from the Author or Editor:
VALID

Answer is D, which is wrong because that allows the BEGINNERs to access resources in directory2. B should be the answer.

Move the checkmark to option B

Anonymous  Oct 12, 2008  Jul 01, 2008
Printed
Page 863
Question 69

Answer is D, which is wrong because that allows the BEGINNERs to access resources in directory2. B should be the answer.

Moved the checkmark to option B

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

Anonymous    Jul 01, 2008
Printed
Page 863 & 827
Question 69

This is to dispute earlier errata regarding question 69.

The question states:

Your web application has a valid dd with a single <security-constraint> tag.
Within this tag exists:

- a single http method that declares GET

All of the resources in your application exist within directory1 and
directory2 and the only defined roles are BEGINNER and EXPERT.

If you want to restrict BEGINNERs from using resources in directory2, which are true about the url and role tag(s) you should declare? (Choose all that apply.)

A. A single url tag should declare directory1 and a single role tag should declare EXPERT.
B. A single url tag should declare directory2 and a single role tag should declare EXPERT.
C. A single url tag should declare directory1 and a single role tag should declare BEGINNER.
D. A single url tag should declare directory2 and a single role tag should declare BEGINNER.
E. One url tag should declare ANY and its role tag should declare EXPERT, and another url tag should declare directory2 and its role tag should declare BEGINNER.
F. One url tag should declare both directories, and its role tag should declare EXPERT, and another url tag should declare directory1 and its role tag should declare BEGINNER.

None of these will do what is wanted. Here's why....

Since <http-method>GET</http-method> is used, only the GET method will be constrained. ALL OTHER METHODS WILL BE UNCONSTRAINED, FOR EVERYONE.

If Option B is chosen, EXPERT will be the only role allowed to perform GET requests on directory2, but everyone else (BEGINNER & EXPERT) will be able to perform POST, TRACE, PUT, etc.

If the question were more specific in asking what could be done to prevent BEGINNERs from performing GET requests on directory, then Option B would be the correct choice.

As it is written, there are no correct answers to this question.

Note from the Author or Editor:
Yes, you are right but the intent of the question is clear just not explicit. The last sentence of the stem should by rewritten as:

"If you want to restrict BEGINNERs from retrieving static resources..."

NOT:

"If you want to restrict BEGINNERs from using resources..."
because the word "use" is too loose.

Anonymous  Feb 25, 2009  Mar 01, 2011
Printed
Page 877 and 878

Text from crosswords is cut off.

Note from the Author or Editor:
Made changes to ensure all text prints.

Anonymous    Jul 01, 2008
Printed
Page 877 and 878

Text from crosswords was cut off. Made changes to ensure all text prints.

Anonymous    Jul 01, 2008