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 come from several SCWCD books like
HFSJ,
David Bridgewater and
Deshmukh/Malavia.
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>
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,
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 fileCreate the TLD fileThe 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){
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
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. --Ulf
CategoryCertification ScwcdFaq ScwcdLinks