Errata

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

Note from the Author or Editor:
Correct.

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)

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)

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

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

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

Unchecked C

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

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.

"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

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

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

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.

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

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.

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

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") %>' />

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}

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

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

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

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 {

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

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

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

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.

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.

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

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.

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

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

Added a checkmark to option C

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

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

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.

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

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

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.

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

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

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

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

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.

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.

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.

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

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

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

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

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