The Uniform Resource Indicator is the part of the URL excluding the domain name and the query string.
Wrong statement. URI is the superset of URL. All URLs are URIs.
The PUT method is the complement to the GET method.
The complement to the PUT method is the DELETE method.
P.64 Only gives the definition of the three paths (Context, servlet and Path Info) but does not tell exactly how to determine the three paths from a request. The given table is almost useless because it does not tell how the author arrived at the values. In fact, you cannot indentify the three parts of a URI unless you know the servlet mappings, which are nowhere to be seen.
<context path="/features? docbase="c:/projects..." reloadable="true">
I don't know where the author got the <context> tag from. As per the specification there is no such tag:
<!ELEMENT web-app (icon?, display-name?, description?,
distributable?, context-param*, filter*, filter-mapping*,
listener*, servlet*, servlet-mapping*, session-config?, mimemapping*,
welcome-file-list?, error-page*, taglib*, resourceenv-
ref*, resource-ref*, security-constraint*, login-config?,
security-role*, env-entry*, ejb-ref*, ejb-local-ref*)>
Discussion of URI to Servlet mapping is beyond my comprehension.
Attributes are defined and stored by getXXX and setXXX methods.
getXXX and setXXX???
The method names are same for getting or setting attributes from/to anywhere: getAttribute and setAttribute.
P.130, Listing 4.1
It shows that you can take a connection out of a connection pool and put it into the context in the contextInitialized() method. This is a very wrong approach and promotes a bad practice. Connections are meant to be taken out of a pool as and when needed and then returned immediately. In this example, however, you are taking out a connection from a pool for the life of the whole application!!! What's the point of having a pool then?
I think that the author's intention is to create a ConnectionPool (and not a PoolConnection) in the context listener.
Further, reference to the JNDI stuff at this point will be confusing to the novices.
There is no mention that Filters are not needed for the exam. The reviewing questions also has questions on Filters. The Key Terms section also mention Filters.
This chapter is at best INCOMPLETE. It does not even explain how an exception thrown by a servlet is trapped by the container and invokes an error page. No mention of how to handle/configure the business exceptions. There is no mention of 'rootCause' in ServletException section, which is the most important link in the chain of exception handling.
Discussion at page 204-209 is beyond my comprehension. I don't understand why is all that info there anyway. But may be that's just me. In any case, there are lot of other things that are necessary for this approach to work. Such as, you must have servlet mapping. It does not work for static pages. Almost 5 pages are devoted to thing that nobody even uses and does not work. This will definitely confuse, or worse, scare, the novices.
This chapter leaves out the important concepts such as what is meant by "a client joining the session". Obviously, there is no mention of isNew() method. It does discuss URL rewriting but does not mention it in relation to HttpSession.
I sincerely do not appreciate the organization of this chapter. Why is Declarative and Programatic security discussed in Auditing section???
P 240, As you can see declarative and programatic security can be used together.
Can be??? Is it possible to use programatic security without declarative security? I don't think so.
BEWARE: THIS CHAPTER HAS THE POTENTIAL TO BRAINWASH YOU.
P. 276, Listing 8.3
The author has taken out out.println("Count="+count); out of the synchronized block to improve performance. Whaaaaaat??? An SCJP with no knowledge of servlets will tell how stupid this code is. The whole point of using a synchronized block was to ensure that no other thread should be able to mess with count until its value is printed out. count++ is already an atomic operation and it does not need a synchronized block.
The author has mentioned the existance of multiple instances of a servlet class for explaining thread safety of class variables but the author has not done so in explaining thread safety of instance variables where it is more appropriate. Class variables are unsafe even if there is only one instance of a servlet. While for instance variables, the author has given a blanket statement that they are unsafe which is not correct for servlets implementing STM. Agreed, STM is discussed later but then such statement shouldn't be there in the first place.
By design, session attributes are thread safe.
Really??? I don't think so. What if a user opens multiple browser windows using Cntrl N and sends a request from both?
The complete section regarding thread safety of context attribute is WRONG. Don't even read it unless you want to try retrieving context parameters using context.getAttribute(). Just remember that context attributes are NEVER thread safe. This does not depend on anything.
I am returning my copy as I have no intention to proof read the JSP section.
[ August 04, 2002: Message edited by: Ram Manglampalli ]