SCW CD H INTS

Here are some of the SCWCD related hints that I thought would be good to be written
somewhere.

Please let me know if I've made any mistakes. Most of them comes from several SCWCD books
like the HFSJ, David Bridgewater, Hanumanth Deshmuk.

Regards,

Jothi Shankar Kumar. S

1) Of the big 7 HTTP methods,

SAFE >> GET, HEAD, TRACE, OPTIONS

IDEMPOTENT* >> GET, HEAD, TRACE, OPTIONS, PUT, DELETE

NON-IDEMPOTENT >> POST

* yields the same result if the operation is applied multiple times

2) A <jsp:forward> effectively terminates the current page. Nothing before the <jsp:forward> or
after the <jsp:forward> is written to the response!

3) If a jsp page fails to translate, then any request to that page should return a 500(server error)
communicated back in the HTTP response.

4) The servlets created from the JSP page have to obey some special rules, a vendor will
typically have a specialized JSP base servlet-perhaps extending HttpServlet or GenericServlet In
Tomcat, this is called org.apache.jasper.runtime.HttpJspBase

5) Beware of the deprecated encodeUrl and encodeRedirectUrl methods. They have mixed
casing for the Url instead of URL. So encodeUrl and encodeRedirectUrl won't work for 2.4
schema. Instead it should be encodeURL and encodeRedirectURL.

6) A value of 0 or a negative value in the session-timeout of the session-config in the web.xml file
(which is expressed in minutes) indicates that the session never expires. However, this can be
overridden using the setMaxInactiveInterval() in the code where the time is in expressed in
seconds. Always Remember web.xml in minutes and the code in seconds.

7) Don't be thrown by weird but legal variants for directive syntax. You don't need white space
after the opening marker or before the closing marker: <%@page import="java.util.*"%> You can
also put extra white space before or after the equal sign for the attribute: <%@ page import =
java.util.*"%> Single quotes are as acceptable as double quotes for attribute values: <%@ page
import="java.util.*" %>
8) There are 4 page directives required to be known for the exam. They are,

<%@ Page import...%> -- Can appear any number of times and anywhere in the JSP

And for the below ones - There shall be only one occurrence of any attribute/value pair defined by
this directive in a given translation unit, unless the values for the duplicate attributes are identical
for all occurrences.

<%@ Page session...%>

<%@ Page contentType...%>

<%@ Page isELIgnored...%>

Also note that "Only pageEncoding and contentType should appear at the beginning of the page"
while the rest can appear anywhere in your JSP page.

9) You have to keep java code (like scriptlets, expressions) free of EL, Always remember EL is not
java

The following won't work since it has EL inside an expression, <%=

request.getParameter(${name.value})%> >> This will never ever compile.

10) ${"Not a Number"+ 3.0}. You will get a javax.servlet.jsp.el.ELException, complaining that Not
a Number; cannot be converted to a java.lang.Double value. This example also goes to show that
the addition operator in EL -unlike Java- is not overloaded to handle string concatenation. There's
no operator overloading or string concatenation in EL.

11) The difference between jsp:include and @include...

<jsp:include> Standard Action

• Attributes: page (and flush)

• Page attribute accepts relative URLs.(*)

• Response from target page included at request time.

• Target page to include can be soft-coded as an expression.

• Can execute conditionally in the middle of page logic.

• Target page doesn't have to exist until request time.

<%@ include %> Directive

• Attribute: file
 • File attribute accepts relative URLs.(*)

• Target file included during translation phase.

• Target file must be a hard-coded literal value.

• Will be processed unconditionally; can't be embedded in page logic.

• Target file must exist at translation time.

• Does not necessarily include the latest version of the target file: depends on your
container (not mandated by the JSP specification).

(*) relative urls are defined in the JSP specification : JSP.1.2.1 Relative URL Specifications

12) Having a directory called WEB-INF is a strong recommendation, but not an absolute
obligation. Look out for questions that ask you to say whether a web application must have
particular directories. The correct answer is no!

13) The deployment descriptor has, in fact, 27 top-level elements, shown in Figure below. These
top-level elements each contain half a dozen or so elements, at various levels of nesting, ranging
from the very simple (e.g., <distributable>, with no nested elements) to <servlet> (with 9 nested
elements, some containing more nested elements). <web-app>
<description>
<display-name>
<icon>
<distributable>
<context-param>
<filter>
<filter-mapping>
<listener>
<servlet>
<servlet-mapping>
<session-config>
<mime-mapping>
<welcome-file-list>
<error-page>
<jsp-config>
<security-constraint>
<login-config>
<security-role>
<env-entry>
<ejb-ref>
<ejb-local-ref>
<service-ref>
<resource-ref>
<resource-env-ref>
<message-destination-ref>
<locale-encoding-mapping-list>
14) A web.xml file that contains only an empty root element (<web-app version="2.4"></web-
app>) is perfectly legal.

15) Top level web.xml elements can appear in any order as compared to the servlet 2.3
specification. However, the order still matters within the elements inside the top-level elements -
<servlet>, for example.

16) The use of META-INF - Imagine, you have many web apps that needs to be deployed to a
container and all those web apps use some a jar file called myjar.jar. Now you want to package all
your web apps as wars and deploy them to the container. You will end up duplicating myjar.jar in
all your war files. Here is where META-INF comes to play. Each WAR can now reference the
JARs it needs in this common repository by using an existing mechanism: a manifest file. This file
is called MANIFEST.MF, and it must be located in the META-INF directory in the WAR file.

17) Any attempt by a client to access any resources under the WEB-INF directory should return a
404 not found error.

18) When getting a RequestDispatcher? from the ServletContextOnly? only full paths are allowed
(i.e., paths beginning with a forward slash "/", which denotes the context root). Paths without the
initial forward slash will not work. You'll get a runtime exception (IllegalArgumentException), but
whereas when you get the RequestDispatcher? from the ServletRequest?, you can use paths
without a forward slash or with a forward slash or with a .. which means go one directory above
the current directory and use that as the path.

19) The HTTP HEAD method is a GET method, the only difference is that it returns only the
header and not the body. So you can override doGET when your HTTP method is HEAD.

20) If you use getParameter when there are actually an array of request parameters, then the
value returned will be the first value in the array.

21) When the servlet is not initialized correctly i.e., when it throws UnavailableException? or
ServletException?, remember that the destroy() method is not called as it is not a successful
initialization.

22) White space is optional after <%!, <%, and <%=, and before %>

23) jsp:include and jsp:forward allows jsp:param to be declared in their body

24) Both the include directive <%@ include... and forward action <jsp:forward... does not support
the flush attribute but <jsp:include... does support the optional flush attribute.

25) The six JSP Standard actions that you need to know for the exam, <jsp:useBean>,
<jsp:setProperty>, <jsp:getProperty>, <jsp:param>, <jsp:forward>, <jsp:include>

27) A small note about status codes,

Status Code Purpose
100-199 Informational
200-299 Request was succesful
300-399 Request file has moved.
 400-499 Client error
500-599 Server error.

28) EL can also perform lexical comparison ${"joe" eq "sam"} will return false. Under the covers,
the equals method is applied to get the output. In general EL relational evaluation will invoke
useful comparison methods on objects (such as equals() and compareTo()) when they are
appropriate and available.

29) The GenericServlet? abstract class provies implementation for all the methods other than the
service() method.

30) we need not configure HttpSessionBindingListener? or HttpSessionActivationListener? in the

DD.

31) Easy way to remember what the [] operator works with: "BLAM!"

Which stands for ...

Beans Lists Arrays Maps

32) Easy way to remember the important HTTP Methods:

"Get Dan To Put His Parka On!"

Which stands for...

GET DELETE TRACE PUT HEAD POST OPTIONS

33) There are actually 3 artifacts involved in custom tag creation,

• Create the tag class handler - The actual java file

• Create the TLD file
• The actual tag usage in the jsp page

34) There are certain prefixes that you can't use for your custom tags, they are: jsp, jspx, servlet,
java, javax, sun, sunw

Also note that they are case sensitive. So you are free to use Sun, SUnW...and so on for your
custom tag prefixes.

35) There are actually 4 groups of core tag libraries (the ony JSTL tag library that you are
expected to know for the SCWCD 1.4 exam). They are,

• General Purpose - <c:out>, <c:set>, <c:remove>, <c:catch>

 • Conditional - <c:if>, <c:choose>, <c:when>, <c:otherwise>
• Iteration - <c:forEach>, <c:forTokens>
• URL-Related - <c:import>, <c:redirect>, <:c:url>, <c:param>

36) The only requirement for a EL function is that it should be declared public static.

37) You don't need a seperate TLD for your EL functions. You can house your EL functions in the
same TLD as your custom tags. The only constraint lies in the name.

38) The sendError method will replace the contentType of your response to text/html

39) A 405, SC_METHOD_NOT_ALLOWED is returned if your servlet doesn't provide a doPost()

method and when the request has a POST as the HTTP method.

40) In your jsp page, the declaration code has no access to implicit objects; you have to pass
these as parameters to the methods you declare.

41) Beware of commenting inside your scriptlets and declarations. Only java type of comments
are allowed. For example,

<%! publis void calculateSum(int x, it y){

<%-- This is a method to add two numbers --%> //Be aware that this will
catch error during compilation of this jsp page.

Only comments like //, /*...etc...which are java based comments are allowed inside scriptlets and
declarations. Scriptlets and declarations are java!

42) Assume that you have a jsp error page and you include that in another jsp which might throw
an error. Now, the actual error page gets translated only when the jsp in which you have included
the error page actually throws the error.

43) There's no flush attribute as there is for <jsp:include>. Instead, certain things have to be true
about the state of the response for the <jsp:forward> to be processed successfully. It all comes
down to the thorny question of whether any part of the response has already been committed - in
other words, written back to the client. Responses are considered uncommitted when anything
written to them already is still in the memory buffer and the buffer has never been flushed.

So a <jsp:forward> won't work if

• There is no buffer (in a JSP, this can be achieved with a page directive, setting the buffer
attribute to none), and even one character has been written to the response.
• The buffer has been explicitly flushed (response.flushBuffer()).
• The buffer has been automatically flushed on filling up (in a JSP, this will happen by
default; see the page directive attribute autoFlush for more information).

If you try to do any of the above, you'll get an IllegalStateException.

44) Two special rules apply to files within the /WEB-INF directory. One is that direct client access
should be disallowed with an HTTP 404 (file not found) error. The second regards the order of
class loading. Java classes in the /WEB-INF/classes directory should be loaded before classes
resident in JAR files in the /WEB-INF/lib directory.

45) carriage returns and line feeds are not allowed for url patterns in <servlet> tag's <url-pattern>.
However, white spaces are allowed like <urlpattern>My Servlet</url-pattern> is legal and works.
You'll probably find that your browser substitutes a hexadecimal representation of the white space
character in the address line (%20).

46) A small note about <load-on-startup> of servlets,

1) A servlet with a lower number will be loaded before a servlet with a higher number. 2) If the
numbers are the same, you're in the lap of the web container designers- there are no guarantees
on which servlet starts first. 3) If the number is negative, the web container can do whatever it
pleases regarding loading the servlet: It's as if the <load-on-startup> element wasn't there at all.

If a <jsp-file> is specifi ed rather than a <servlet-class>, a <load-onstartup> setting ensures that

the JSP is pre-compiled (turned into a servlet), then loaded as any other servlet would be.

47) Always remember that the included pages can't do anything to the headers. Be it a servlet or
a jsp.

48) parameters -unlike attributes- can have multiple values for the same name.

49) Whenever a Request Dispatcher is used to forward or include a resource -be it dynamic
(servlet) or static (plain HTML)- the security model does not apply. It is applicable only to web
resources requested by a client.

50) The implicit objects available in JSP pages are: request, response, pageContext, session,
application, out, config, page, exception (in error pages only). They're explained in the JSP 2.0
specification section 1.8.3.

The implicit objects available in EL pages are: pageContext, pageScope, requestScope,

sessionScope, applicationScope, param, paramValues, header, headerValues, cookie, initParam.
They're explained in the JSP 2.0 specification section 2.2.3.

51) There are two kinds of comments in a jsp page one like <%-- COMMENTS --%> (a JSP
comment) and the other your regular HTML comment <!-- COMMENT -->. The JSP comment is
ignored completely during the translation pase.

52) Of the 4 scripting elements in a JSP page, none will nest within others or within themselves.

53) exception implicit object in a jsp is available only in designated error pages, which have the
directive <%@ page isErrorPage="true" %>

54) A jsp page can have either elements (declarations, directives, expressions, scriptlet) or
template text (which is directly shown on the browser)
55) Even if you omit the contentType attribute of the page directive, the jsp container sets it to
"text/html" using the response.setContentType("text/html");

56) EL functions can have void return type.

57) Authentication - 4 types of Authentication

1) FORM - Very weak, allows custom login pages, no encryption
2) BASIC - Only encoding, weak base64
3) DIGEST - Optional for containers, the encryption mechanism is not
widely used
4) CLIENT-CERT - use of PKC, Strongest with encryption

There is also vendor specific authentication type.

58) DIGEST is not an HTTP standard for Authentication while the rest of the 3 (BASIC, CLIENT-
CERT, FORM) are HTTP standards.

This is incorrect. DIGEST is defined in RFC 2716, while FORM is not an official standard - it's
defined in the servlet spec. --UlfDittmer?