http://www.javacertificationexams.com/scwcd-mock-exams.php
Above is the links for SCWCD mock exams available in net.
Few of the links also contains the SCWCD preparation guide.
If you want any study guide for SCWCD then go to www.scribd.com and search for the SCWCD as search word. You will get few articles and also books.
All the best.
Wednesday, March 11, 2009
Tuesday, March 10, 2009
SCWCD 5.0 QUICK REVISION NOTES
Revision Notes
The Servlet Technology Model
1. The HTTP protocol supports 7 methods: GET, POST, HEAD, OPTIONS, DELETE, PUT, and TRACE.
2. For each of the HTTP methods, there is a doXXX method where XXX is the method name such as Get, Post and so on.
3. The GET method is used to retrieve whatever information (in the form of an entity) is identified by the Request-URI.
4. The GET method is triggered when the user directly types the URL in the browser's address bar or when the user clicks a link or when the FORM specifies the GET method using "method" attribute.
5. Query string or form data during GET method is simply appended to the URL as name-value pairs separated with '&' and hence it is not so secure.
6. The POST method allows the client to send data of unlimited length to the Web server a single time. It also can be used to upload both text and binary data.
7. The POST method uses the body of the request to send the data and is useful when posting secure information such as login data.
8. The HEAD HTTP request is used to retrieve the meta-information about a resource.
9. The request parameters are stored as a set of name-value pairs. Multiple values can exist for any given parameter name.
10. ServletRequest interface provides the following methods:
* getParameter: Returns the value of a request parameter as a String, or null if the parameter does not exist. The method can be used when the parameter has only one value.
Reading the body directly via getInputStream() or getReader() can interfere with the execution of this method.
* getParameterNames: Returns an Enumeration of String objects containing the names of the parameters in this request. If the request has no parameters, the method returns an empty Enumeration.
* getParameterValues: Returns an array of String objects containing all the values the given request parameter has, or null if the parameter does not exist.
* getParameterMap: Returns an immutable java.util.Map containing parameter names as keys and parameter values as map values. The keys in the parameter map are of type String. The values in the parameter map are of type String array.
11. Headers can be retrieved using the methods of HttpServletRequest:
* getHeader: Returns the value of the specified request header as a String.
* getHeaders: Returns all the values of the specified request header as an Enumeration of String objects.
* getHeaderNames: Returns an enumeration of all the header names this request contains. If the request has no headers, this method returns an empty enumeration.
The following convenience methods are also provided:
o getIntHeader: Returns the value of the specified request header as an int.
o getDateHeader: Returns the value of the specified request header as a long value that represents a Date object.
12. HttpServletRequest.getCookies() returns an array of cookies present in the request. This method returns null if no cookies were sent.
13. HttpServletResponse has the following methods to set HTTP headers:
* setHeader: Sets a response header with the given name and value.
* addHeader: Adds a response header with the given name and value. This method allows response headers to have multiple values.
14. There are convenient variations of the above methods, such as setIntHeader, setDateHeader, addIntHeader, and addDateHeader.
15. The content type of the response can be set using ServletResponse.setContentType(String) or HttpServletResponse.setHeader("Content-Type", mimeTypeString);
16. A text stream can be acquired using ServletResponse.getWriter() whereas a binary stream using ServletResponse.getOutputStream().
17. The HttpServletResponse.sendRedirect() method is used to send an HTTP redirect response to the client. If the response has already been committed, this method throws an IllegalStateException.
18. The HttpServletResponse.addCookie(Cookie) method adds a cookie to the response stream. Cookies can also be set by setting the header but generally it is unadvisable to do so.
19. The Servlet lifecycle has 5 stages: (1) servlet class loading, (2) servlet instantiation, (3) call the init method, (4) call the service method, and (5) call destroy method.
20. The container initializes the servlet instance by calling the init method of the Servlet interface only once in its lifetime with a unique (per servlet declaration) object implementing the ServletConfig interface.
21. When the servlet container determines that a servlet should be removed from service, it calls the destroy method of the Servlet interface to allow the servlet to release any resources it is using and save any persistent state.
The Structure and Deployment of Web Applications
22. A Web application exists as a structured hierarchy of directories. The root of this hierarchy serves as the document root for files that are part of the application.
23. The WEB-INF is not a part of the public document tree of the application and no file in the WEB-INF directory may be served directly to a client by the container.
24. The directory structure of a web application contains
* /WEB-INF/web.xml deployment descriptor.
* /WEB-INF/classes/ directory for servlet and utility classes.
* /WEB-INF/lib/*.jar area for Java Archive files. These files contain servlets, beans, and other utility classes useful to the Web application.
25. The error-page element contains a mapping between an error code or exception type to the path of a resource in the web application.
The DTD for error-page element is
26. The init-param element contains a name-value pair as an initialization parameter of the servlet.
The DTD for init-param element is
ServletConfig.getInitParameter() and ServletConfig.getInitParameterNames() can be used to retrieve these parameters.
27. The mime-mapping element defines a mapping between an extension and a mime type.
The DTD for mime-mapping element is
28. The servlet element contains the declarative data of a servlet. If a jsp-file is specified and the load-on-startup element is present, the JSP should be precompiled and loaded.
The DTD for the above is
29. The servlet-mapping element defines a mapping between a servlet and a url pattern.
The DTD for the servlet-mapping is
30. The welcome-file-list contains an ordered list of welcome file elements.
The DTD is
31. Web applications can be packaged and signed into a Web ARchive (WAR) format file using the standard Java archive tools.
32. A WAR usually contains the following resources:
* Servlets, JavaServer Pages (JSP), Custom Tag Libraries
* Server-side utility classes (database beans, shopping carts, and so on)
* Static web resources (HTML, image, and sound files, and so on)
* Client-side classes (applets and utility classes)
33. The directory structure of a Web application consists of two parts. The first part is the public directory structure containing HTML/XML documents, JSP pages, images, applets, and so on. The container appropriately serves the directory's contents against incoming requests. The second part is a special WEB-INF directory that contains the following files and directories:
* web.xml - the web application deployment descriptor and may be tld files directly under the WEB-INF or under any of the sub-folders
* classes/ - a directory that contains server-side classes: servlet, utility classes, and JavaBean components
* lib/ - a directory that contains JAR archives of libraries (tag libraries and any utility libraries called by server-side classes)
* tags/ - a directory that contains Tag files
The Web Container Model
34. Context parameters are shared across the entire web application whereas Servlet initialization parameters are unique to the servlet.
35. The context-param element contains the declaration of a web application's servlet context initialization parameters.
The DTD is
36. The methods ServletContext.getInitParameter() and ServletContext. getInitParameterNames() could be used to access the servlet context initialization parameters.
37. A Servlet can store attributes within three scopes:
request: Managed by ServletRequest interface and valid only for the current request
session: Managed by HttpSession interface and available to any servlet in the same session
context: Managed by ServletContext interface and available to any servlet that is part of the same web application
38. The following methods are used to set, get and remove the attributes. They are available in ServletRequest, HttpSession, and ServletContext:
* getAttribute: Returns the value of the named attribute as an Object, or null if no attribute of the given name exists.
* getAttributeNames: Returns an Enumeration containing the names of the attributes available or an empty Enumeration if the object has no attributes available to it.
* setAttribute: Stores an attribute in this object. If the object passed is null, the effect is the same as calling removeAttribute(String).
* removeAttribute: Removes the object bound with the specified name.
39. The order which the container uses in building the chain of filters is:
* First thematching filter mappings in the same order that these elements appear in the deployment descriptor.
* Next thematching filter mappings in the same order that these elements appear in the deployment descriptor.
40. A Filter could be declared as follows:
Log Filter
com.whiz.LogFilter
LogLevel
DEBUG
and mapped as
LogFilter
/servlet/*
41. A filter could use DISPATCHER element with four valid values: FORWARD, REQUEST, INCLUDE, and ERROR.
42. The four wrapper classes javax.servlet.ServletRequestWrapper, javax.servlet.ServletResponseWrapper, javax.servlet.http.HttpServletRequestWrapper, and javax.servlet.http.HttpServletResponseWrapper
implement their respective interfaces (e.g. ServletRequest, ServletResponse, HttpServletRequest, and HttpServletResponse).
43. Servlet Life Cycle Events
Object Event Listener Interface Event Class Methods
context Initialization and destruction ServletContextListener ServletContextEvent contextInitialized
contextDestroyed
Attribute added, removed, or replaced ServletContextAttribute
Listener ServletContext
AttributeEvent attributeAdded
attributeRemoved
attributeReplaced
HTTP Session Created and destroyed HttpSessionListener HttpSessionEvent sessionCreated
sessionDestroyed
Migaration: activated and passivated HttpSessionActivationListener HttpSessionEvent sessionWillPassivate
sessionDidActivate
Attribute added, removed, or replaced HttpSessionAttributeListener HttpSessionBinding
Event attributeAdded
attributeRemoved
attributeReplaced
Object bound or unbound HttpSessionBindingListener HttpSessionBinding
Event valueBound
valueUnbound
Servlet Request Initialized and destroyed ServletRequestListener ServletRequestEvent requestInitialized
requestDestroyed
Attribute added, removed, or replaced ServletRequestAttribute
Listener ServletRequest
AttributeEvent attributeAdded
attributeRemoved
attributeReplaced
44. Except HttpSessionBindingListener and HttpSessionActivationListener, the rest of the listeners have to be configured in web.xml. A sample configuration could be the following:
listeners.MyRequestListener
45. HttpSessionBindingListener has to be implemented by the session attribute, which needs notification, rather than being implemented by a separate listener class.
46. RequestDispatcher can be obtained in three ways:
* ServletContext.getRequestDispatcher(String path): Starting from the context path. should start with '/'
* ServletRequest.getRequestDispatcher(String path): Starting from the request path
* ServletContext.getNamedDispatcher(String name): Starting from the name of a servlet known to the ServletContext, i.e. one that is mapped in web.xml.
47. The forward method of the RequestDispatcher interface may be called by the calling servlet only when no output has been committed to the client whereas include method can be called any time.
48. Additional request scoped attributes are added when the Request Dispatcher isn't obtained using the getNamedDispatcher() method.
Session Management
49. The session object can be obtained by
HttpServletRequest.getSession()
HttpServletRequest.getSession(boolean create)
Both the methods return the current session associated with this request, or, if the request does not have a session, it creates one (unless the boolean argument is false).
50. A session is "new" if the client does not yet know about the session or if the client chooses not to join the session. It can be tested by using HttpSession.isNew().
51. A session could be implemented using the following:
* Cookies: The name of the session tracking cookie id is JSESSIONID. It can be checked using HttpServletRequest.isRequestedSessionIdFromCookie() method.
* URL rewriting: The session uses URL to communicate the session id. The URL would be in the form of http://myserver/mywebapp/someresource.jsp;jsessionid=1234 with "jsessionid" as the session tracking ID. The method HttpServletRequest.isRequestedSessionIdFromURL() can be used to check whether the requested session ID came in as part of the request URL.
* Secure Sockets Layer (SSL): The information in the SSL can be used to track the session.
52. The invalidate() method of the HttpSession interface expires the current session. It causes the representation of the session to be invalidated and removed from its context.
53. Session timeout can be configured
1. Declaratively using the session-config element in web.xml as
10
It specifies sessions to be timed out after 10 min of inactivity. Sessions will never expire if the timeout is specified as 0 or less.
2. Programmatically using the API
* HttpSession.setMaxInactiveInterval(int seconds)
* int HttpSession.getMaxInactiveInterval()
Time is specified in seconds. Session will never expire if the timeout period for a session is set to -1 (note that a value of 0 will not give an infinite timeout).
54. URL rewriting could be done using
* HttpServletResponse.encodeURL(String): Encodes the specified URL by including the session ID in it, or, if encoding is not needed, returns the URL unchanged.
* encodeRedirectURL(String): Encodes the specified URL for use in the sendRedirect method or, if encoding is not needed, returns the URL unchanged.
Web Application Security
55. The four mechanisms of security are:
* Authentication: The means by which communicating entities prove to one another that they are acting on behalf of specific identities that have access to the system is called authentication. For example, a customer logs in to the bank's web site using his login and password to prove to the system that he is really the one what he claims to be.
* Authorization: The means by which interactions with resources are limited to collections of users or programs for the purpose of enforcing integrity, confidentiality, or availability constraints is called authorization. For example, a manager can see the details of all the employees whereas an employee can see only his details.
* Data Integrity: The means used to prove that information has not been modified by a third party while in transit is called data integrity. For example, if you send a file and its checksum separately, the receiving party can compute the checksum of the file and match it with the received checksum to ensure the contents of the file was not tampered on the way.
* Confidentiality (a.k.a. Data Privacy): The means used to ensure that information
is made available only to users who are authorized to access it is called confidentiality. For example, you could encrypt the data and send. The receiver who has the decrypting key alone would be able to read the data.
56. Security constraints are a declarative way of defining the protection of web content. A security constraint associates authorization and/or user data constraints with HTTP operations on web resources. A security-constraint element consists of the following elements:
* web-resource-collection
* auth-constraint
* user-data-constraint
57. The HTTP operations and web resources to which a security constraint applies (i.e. the constrained requests) are identified by one or more web resource collections. A web-resource-collection element consists of the following elements:
* url-pattern
* http-method
58. An authorization constraint establishes a requirement for authentication and names the authorization roles permitted to perform the constrained requests. A user must be a member of at least one of the named roles to be permitted to perform the constrained requests. The auth-constraint element consists of the role-name element.
59. A user data constraint specifies the strength of the required protection in the communication channel. It contains the transport-guarantee element which takes the following values:
* INTEGRAL - No one should be able to modify the data during transit
* CONFIDENTIAL - No one should observe the data during transit
* NONE - No transport guarantee required
60. 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. The child elements are:
* auth-method
* realm-name
* form-login-config: only when the auth-method is FORM
* form-login-page
* form-error-page
61. The security-role element contains the definition of a security role. The child element role-name specifies the security role name.
62. A web client can authenticate a user to a web server using one of the following mechanisms:
* HTTP Basic Authentication: Password is base 64 encoded and transmitted.
* HTTP Digest Authentication; Password is encrypted and transmitted.
* HTTPS Client Authentication; Data is encrypted using public-key cryptography and transmitted.
* Form Based Authentication; Same as HTTP Basic except that the login dialog box can be customized.
63. When using FORM based authentication, the action of login form should be 'j_security_check' and the user name field should be 'j_username' and password field should be 'j_password'.
For example,
The JavaServer Pages (JSP) Technology Model
64. The following table lists some of the elements in JSP pages and JSP documents:
Element JSP Page JSP Document
Directives
Declarationthis is a declaration
Expressionthis is an expression
Scriptletthis is a scriptlet
Template text Any textAny text
65. The page directive defines number of page dependent properties. The important attributes are the following:
"import"
It defines the packages that should be imported by the generated servlet.
For example,
"session"
It indicates that the page participates in HTTP session. If true, then the implicit script language variable named session references the current/new session for the page. If false, then the page does not participate in a session; the
session implicit variable is unavailable. The default value is true.
For example,
"contentType"
It defines the MIME type and the character encoding for the response of the JSP page.
For example,
or
"isELIgnored"
It defines whether EL expressions are ignored (if the value is true) or evaluated (if the value is false) for this page.
For example,
66. The include directive is used to insert a file into servlet class at the time when JSP file is translated into servlet.
For example,
67. The taglib directive is used to declare custom tags available to the page.
68. A JSP undergoes the following lifecycle methods:
* jspInit()
* _jspService()
* jspDestroy()
69. The following table describes the JSP Implicit objects.
Implicit Object Type Description
request Protocol dependent subtype of:javax.servlet.ServletRequestex:javax.servlet.http.HttpServletRequest in case of HTTP HTTP request data, as well as providing a context for associating request-specific data.
response Protocol dependent subtype of:javax.servlet.ServletRequestFor example,javax.servlet.http.HttpServletResponse in case of HTTP The page's response back to the client
pageContext javax.servlet.jsp.PageContext A single API to manage the various scoped attributes
session javax.servlet.http.HttpSession The session associated with the request
application javax.servlet.ServletContext The context in which the servlet is running
out javax.servlet.jsp.JspWriter The output stream used to send the response
config javax.servlet.ServletConfig The servlet configuration object
page java.lang.Object The JSP page itself
exception java.lang.Throwable For error pages, the uncaught exception
70. A tag library can be declared in web.xml as
http://www.whizlabs.com/tags
/whiz.tld
71. The scripting-invalid element is a subelement of jsp-property-group. Allowed values are true and false. Scripting elements can be disabled by setting the scripting-invalid element to true.
The el-ignored element is a subelement of jsp-property-group. Allowed values are true and false. EL can be disabled by setting the el-ignored element to true.
The following fragment disables both EL and scripting for all JSP Pages:
*.jsp
true
true
72. Include directive includes a static file in a JSP page, parsing the file's JSP elements. The include directive is processed when the JSP page is translated into a servlet class.
73. jsp:include action includes a static file or the result from another web component. The difference from the include directive is that not the source of the JSP, but its output is included. The included JSP page is being executed within the servlet engine and it's output is returned to the calling page.
For example,
74. Use Include directive when including static files which change very rarely, for example, Copyright file.
75. Use Include action when the included file is expected to be changed often, for example, a stock quotes file
Building JSP Pages Using the Expression Language (EL)
76. A primary feature of JSP technology version 2.0 is its support for an Expression Language (EL). An expression language makes it possible to easily access application data stored in JavaBeans components.
77. EL expressions are enclosed by the ${ } characters and can include literals. For example, ${ELExpression}.
78. Literal values that contain the ${ characters must be escaped as ${'${'}.
79. EL expressions can be used in:
* Static text
* Any standard or custom tag attribute that can accept an expression
80. The JSP container evaluates a variable that appears in an expression by looking up its value according to the behavior of PageContext.findAttribute(String). For example, when evaluating the expression ${product}, the container will look for 'product' in the page, request, session, and application scopes and will return its value. If 'product' is not found, null is returned.
81. The table describes the available implicit objects:
Implicit Object
Description
pageContext The context for the JSP pageProvides access to various objects including:
82. servletContext: The context for the JSP page's servlet and any Web components contained in the same application
83. session: The session object for the client
84. request: The request triggering the execution of the JSP page
85. response: The response returned by the JSP page
param A java.util.Map that maps parameter names to a single String parameter value. Equivalent to ServletRequest.getParameter(String name).
paramValues A java.util.Map that maps parameter names to a String[] of all values for that parameter. Equivalent to ServletRequest.getParameterValues(String name).
header A java.util.Map that maps parameter names to a single String parameter value. Equivalent to HttpServletRequest.getParameter(String name).
headerValues A java.util.Map that maps header names to a String[] of all values for that header. Equivalent to HttpServletRequest..getHeaders(String s)
cookie A java.util.Map that maps cookie names to a single Cookie object. Equivalent to HttpServletRequest.getCookies().
initParam A java.util.Map that maps context initialization parameter names to their String parameter value. Equivalent to ServletContext.getInitParameter(String name).
pageScope A java.util.Map that maps page-scoped attribute names to their values.
requestScope A java.util.Map that maps request-scoped attribute names to their values.
sessionScope A java.util.Map that maps session-scoped attribute names to their values.
applicationScope A java.util.Map that maps application-scoped attribute names to their values.
82. The "." operator is used for accessing properties whereas "[]" operator is used for accessing collections (arrays, lists, maps).
83. The JSP expression language unifies the treatment of the "." and "[]" operators. Thus a.b is equivalent to a["b"]. That is, the identifier b is used to construct a literal value and then the [] operator is used with that value.
84. Although a.b is equivalent to a["b"], the reverse is not true.
85. The following table shows the common usage of "." and "[]" operators.
Type
Method
Legal
Illegal
86. List listObj.get(1) ${list[1]}
87. ${list["1"]}
${list.1}
88. Map mapObj.get("key") ${map["key"]}
${map.key}
89. Array Array.get(arrayObj,1) ${arrayObj[1]}
90. ${arrayObj["1"]}
${arrayObj.1}
91. JavaBean employee.getName() ${employee.name}
92. ${employee["name"]}
93. ${employee['name']}
86. The following table summarizes the Arithmetic, Relational, and Logical operators in EL:
EL Operators
Arithmetic Relational Logical
· Addition: + · == (eq) · && (and)
· Subtraction: - · != (ne) · (or)
· Multiplication: * · < (lt) · ! (not) · Division: / (div) · > (gt)
· Remainder: % (mod · <= (le) · >= (ge)
87. The operator precedence is as follows:
Highest to lowest, left-to-right
[] .
()
- (unary) not ! empty
* / div % mod
+ - (binary)
< > <= >= lt gt le ge
== != eq ne
&& and
or
? :
88. An EL function is given a name and a static method in a specific class that will implement the function.
89. Any EL function has to be defined in the Tag Library Descriptor (TLD). The class specified in the TLD must be a public class, and must be specified using a fully qualified class name (including packages). The specified method must be a public static method in the specified class, and must be specified using a fully qualified return type followed by the method name, followed by the fully qualified argument types in parentheses.
For example, the following TLD fragment describes a function with name "caps" that is intended to capitalize the string passed:
...
caps
com.whiz.util.capitalize
java.lang.String capitalize(java.lang.String)
Building JSP Pages Using Standard Actions
90. The jsp:useBean action declares a variable in the JSP and associates an instance of a Javabean with it.
The syntax of the jsp:useBean action is
where beandetails can be one of the following:
* class="className"
* class="className" type="typeName"
* beanName="beanName" type="typeName"
* type="typeName"
91. The following table illustrates the various attributes of jsp:useBean action:
Attribute Description
id The case sensitive name used to identify the object instance.
scope The scope within which the reference is available. The default value is page.
class The fully qualified (including package name) class name.
beanName The name of a Bean, as you would supply to instantiate() method in the java.beans.Beans class. This attribute can also be a request time expression.
type An optional attribute specifies the type of the class, and follows standard java casting rules. The type must be a superclass, an interface implemented by the class or the class itself. The default value is the same as the value of the class attribute
92. The jsp:setProperty action assigns values to the bean's properties. The syntax is
where properties can be one of the following:
· property="*"
· property="propertyName"
· property="propertyName" param="parameterName"
· property="propertyName" value="propertyValue"
93. The following table illustrates the various attributes of jsp:setProperty action:
Attribute Description
name The name of a bean instance defined by a jsp:useBean action or some other action
property The name of the property whose value will be set. If it is set to * then the tag will iterate over the current ServletRequest parameters, matching parameter names and value type(s) to property names and setter method type(s), setting each matched property to the value of the matching parameter. If a parameter has a value of "", the corresponding property is not modified.
param The name of the request parameter whose value is given toa bean property.
value The value to assign to the given property. This attribute can accept a request-time attribute expression as a value.An action may not have both param and value attributes.
94. Theaction places the value of a bean instance property, converted to a String, into the implicit out object, from which the value can be displayed as output. The syntax is:
95. The following table illustrates the various attributes of jsp:getProperty action:
Attribute Description
name The name of the object instance from which the property is obtained.
property Names the property to get.
96. Functionally the jsp:include and jsp:forward actions are similar to RequestDispatcher.include() and RequestDispatcher.forward() methods.
97. A jsp:include action provides for the inclusion of static and dynamic resources in the same context as the current page.
Syntax:
A simple request-time inclusion
Passing parameters to the requsted resource
{
98. The following table illustrates the various attributes of jsp:include action:
Attribute Description
page The URL is a relative urlSpec. Relative paths are interpreted relative to the current JSP page. Accepts a request-time attribute value
flush Optional boolean attribute. If the value is true, the buffer is flushed now. The default value is false.
99. A jsp:forward action delegates the request to the forwarded resource and terminates the execution of the current page.
Syntax:
A simple request-time forward
Passing parameters to the requsted resource
{
100. The following table illustrates the various attributes of jsp:forward action:
Attribute Description
page The URL is a relative urlSpec. Relative paths are interpreted relative to the current JSP page. Accepts a request-time attribute value
101. The flush attribute is only valid for jsp:include action and not for jsp:forward action.
102. In both jsp:include and jsp:forward actions, the attribute to refer the resource is "page" and not "file."
103. The jsp:param element is used to provide key/value information. This element is used in the jsp:include, jsp:forward, and jsp:params elements.
Syntax:
Both the attributes are mandatory: name and value. The name attribute indicates the name of the parameter, and value, which may be a request-time expression, indicates its value.
Building JSP Pages Using Tag Libraries
104. The taglib directive in a JSP page declares that the page uses a tag library, uniquely identifies the tag library using a URI and associates a tag prefix that will distinguish usage of the actions in the library.
The syntax is:
<%@ taglib ( uri="tagLibraryURI" tagdir="tagDir" ) prefix="tagPrefix" %>
105. The following table describes the attributes of taglib directive:
Attribute Description
uri Either an absolute URI or a relative URI specification that uniquely identifies the tag library descriptor associated with this prefix. The URI is used to locate a description of the tag library.
tagdir Indicates this prefix is to be used to identify tag extensions installed in the /WEB-INF/tags/ directory or a subdirectory. A translation error will occur
106. if the value does not start with /WEB-INF/tags/
107. if the value does not point to a directory that exists
108. if used in conjunction with the uri attribute
prefix Defines the prefix string inthat is used to distinguish a custom action, e.g., . Prefixes starting with jsp:, jspx:, java:, javax:, servlet:, sun:, and sunw: are reserved and hence illegal.
106. JSP tags can cooperate with each other by sharing objects. The object created by the enclosing tag of a group of nested tags is available to all inner tags.
107. The JSTL core tags can be divided into the following four categories:
· General-purpose
o
o
o
o
· Conditional actions
o
o
o
o
· Iterator actions
o
o
· URL Related
o
o
o
o
108. The core tag library is referred in the page as
<%@ taglib prefix="c" uri="http://java.sun.com/jstl/core" %>
Building a Custom Tag Library
109. Classic tag handlers implement either the Tag, IterationTag, or BodyTag interface or they extend from the TagSupport or BodyTagSupport classes.
110. The various methods and constants defined in the classic tag interfaces are as follows:
Tag
Methods
· doStartTag: Process the end tag for this instance
· doEndTag: Process the end tag for this instance
Constants
· SKIP_BODY indicates that body evaluation should be skipped.
· EVAL_BODY_INCLUDE indicates that the tag body should be evaluated into the existing output stream.
· SKIP_PAGE indicates that the rest of the page should be skipped.
· EVAL_PAGE indicates that page evaluation should continue.
IterationTag
Methods
· doAfterBody(): Process body (re)evaluation
Constants
· EVAL_BODY_AGAIN indicates the reevaluation of the body.
BodyTag
Constants
· EVAL_BODY_BUFFERED indicates the creation of a new buffer, a BodyContent on which to evaluate the body of this tag.
111. The doStartTag() can return
· SKIP_BODY
· EVAL_BODY_INCLUDE
· EVAL_BODY_BUFFERED
112. The doAfterBody() can return
· EVAL_BODY_AGAIN
· SKIP_BODY
113. The doEndTag() can return
· SKIP_PAGE
· EVAL_PAGE
114. A PageContext is an object that provides a context to store references to objects used by the page, encapsulates implementation-dependent features, and provides convenience methods.
115. Using the PageContext, the following tasks can be done:
* Storing, Retrieving, and Finding attributes in Application, Session, Request, and Page scopes
* Accessing the JSP implicit objects
* Forward and Include of the current request
* Error page exception processing
116. To access an object created by an enclosing tag, a tag handler must first obtain its enclosing tag with either of the following static method invocations:
* TagSupport.getParent() - Used to access immediate parent tag
* TagSupport.findAncestorWithClass(from, class) - Used to access any arbitrary tag ancestor
The parent handler's statically and dynamically created objects can be obtained once the parent object is retrieved.
117. A "Simple" tag in Java can implement either SimpleTag interface or extends SimpleTagSupport class. The tag handler should implement only one
method: doTag().
118. Unlike classic tag handlers, SimpleTag extends JspTag instead of extending from Tag. Tag interface relies on PageContext whereas SimpleTag only relies on JspContext.
119. The body of a Simple Tag, if present, is translated into a JSP Fragment and passed to the setJspBody method. Because JSP fragments do not support scriptlets, theof a SimpleTag cannot be "JSP."
120. Tag files are written using JSP syntax and they don't need to be compiled. They are compiled as they are invoked.
121. Tag files can be placed in two locations.
* /META-INF/tags directory(or its sub-directory
) in a JAR file installed in the /WEB-INF/lib/
* /WEB_INF/tags directory
A tag library descriptor is required in the first case where as it is not required for the second case.
122. A tag file has the .tag or .tagx extension and can also include other files that contain a common resource. An include file for a tag file has a .tagf extension.
123. In JSP, you need the taglib directive as usual, with the prefix attribute to identify your tag library throughout the page. But instead of a uri attribute, you have a tagdir attribute. The tagdir attribute refers to the WEB-INF/tags directory or any subdirectory below WEB-INF/tags.
J2EE Patterns
125. The following table summarizes the scenarios under which a particular pattern could be useful along with its pros and cons:
Intercepting Filter
Scenario Significance
When the presentation-tier request handling mechanism receives many different types of requests, which require varied types of processing, Some requests need to be simply forwarded to the appropriate handler component, while other requests must be modified, audited, or uncompressed before being further processed, which results in
126. Nested if/else conditional checks
127. A fragile code that breaks when new features/modifications are made.
128. Copy-and-paste style of programming
Pros
129. Centralizes control with loosely coupled handlers
130. Improves reusability
131. Declarative and flexible configuration
Cons
132. Information sharing is inefficient
Front Controller
Scenario Significance
The system requires a centralized access point for presentation-tier request handling to support the integration of system services, content retrieval, view management, and navigation, which results in
133. Duplicate code
134. Blended view content and view navigation
135. Unmaintainable code
136. Centralizes control
137. Improves manageability of security
138. Improves reusability
Service
Scenario Significance
Service lookup and creation involves complex interfaces and network operations which often leads to
139. Vendor dependency in the application
140. Duplicated Java Naming and Directory Interface (JNDI) code
141. Repeated creation of context and looking up, which is slow performing
142. Abstracts complexity
143. Provides uniform service access to clients
144. Facilitates adding new business components
145. Improves network performance
146. Improves client performance by caching
Business Delegate
Scenario Significance
Presentation-tier components interact directly with business services. This direct interaction exposes the underlying implementation details of the business service application program interface (API) to the presentation tier which results in
147. Tight coupling between presentation-tier components and business services
148. Increased network invocations reducing performance
149. Lack of client-side caching mechanism or aggregating service.
150. Clients handling networking issues
Pros
151. Reduces Coupling, Improves Manageability
152. Translates business service exceptions
153. Implements failure recovery and thread synchronization
154. Exposes simpler, uniform interface to business tier
155. Better performance
156. Hides remoteness
Cons
157. Introduces additional layer
Transfer Object
Scenario Significance
When application clients interact with enterprise beans, there is a possibility that some methods exposed by the business components return data to the client. Often, the client invokes a business object's get methods multiple times until it obtains all the attribute values. This leads to
158. Increased network overhead
159. Reduced performance
Pros
160. Simplifies entity bean and remote interface
161. Transfers more data in fewer remote calls
162. Reduces network traffic
163. Reduces code duplication
Cons
164. May introduce stale transfer objects
165. May increase complexity due to synchronization and version control
166. Concurrent access and transactions may lead to inconsistent transfer objects
Model View Controller
Scenario Significance
An application containing a mixture of data access code, business logic code, and presentation code leads to
167. Unmaintainable code due to strong interdependencies and ripple effects
168. Addition of new views/clients becomes near to impossible
169. Prevents reuse as code is highly coupled
170. Promotes copy-and-paste style of programming
Pros
171. Re-use of model components
172. Easier support for new types of clients
Cons
173. Increased design complexity
ALL THE BEST
The Servlet Technology Model
1. The HTTP protocol supports 7 methods: GET, POST, HEAD, OPTIONS, DELETE, PUT, and TRACE.
2. For each of the HTTP methods, there is a doXXX method where XXX is the method name such as Get, Post and so on.
3. The GET method is used to retrieve whatever information (in the form of an entity) is identified by the Request-URI.
4. The GET method is triggered when the user directly types the URL in the browser's address bar or when the user clicks a link or when the FORM specifies the GET method using "method" attribute.
5. Query string or form data during GET method is simply appended to the URL as name-value pairs separated with '&' and hence it is not so secure.
6. The POST method allows the client to send data of unlimited length to the Web server a single time. It also can be used to upload both text and binary data.
7. The POST method uses the body of the request to send the data and is useful when posting secure information such as login data.
8. The HEAD HTTP request is used to retrieve the meta-information about a resource.
9. The request parameters are stored as a set of name-value pairs. Multiple values can exist for any given parameter name.
10. ServletRequest interface provides the following methods:
* getParameter: Returns the value of a request parameter as a String, or null if the parameter does not exist. The method can be used when the parameter has only one value.
Reading the body directly via getInputStream() or getReader() can interfere with the execution of this method.
* getParameterNames: Returns an Enumeration of String objects containing the names of the parameters in this request. If the request has no parameters, the method returns an empty Enumeration.
* getParameterValues: Returns an array of String objects containing all the values the given request parameter has, or null if the parameter does not exist.
* getParameterMap: Returns an immutable java.util.Map containing parameter names as keys and parameter values as map values. The keys in the parameter map are of type String. The values in the parameter map are of type String array.
11. Headers can be retrieved using the methods of HttpServletRequest:
* getHeader: Returns the value of the specified request header as a String.
* getHeaders: Returns all the values of the specified request header as an Enumeration of String objects.
* getHeaderNames: Returns an enumeration of all the header names this request contains. If the request has no headers, this method returns an empty enumeration.
The following convenience methods are also provided:
o getIntHeader: Returns the value of the specified request header as an int.
o getDateHeader: Returns the value of the specified request header as a long value that represents a Date object.
12. HttpServletRequest.getCookies() returns an array of cookies present in the request. This method returns null if no cookies were sent.
13. HttpServletResponse has the following methods to set HTTP headers:
* setHeader: Sets a response header with the given name and value.
* addHeader: Adds a response header with the given name and value. This method allows response headers to have multiple values.
14. There are convenient variations of the above methods, such as setIntHeader, setDateHeader, addIntHeader, and addDateHeader.
15. The content type of the response can be set using ServletResponse.setContentType(String) or HttpServletResponse.setHeader("Content-Type", mimeTypeString);
16. A text stream can be acquired using ServletResponse.getWriter() whereas a binary stream using ServletResponse.getOutputStream().
17. The HttpServletResponse.sendRedirect() method is used to send an HTTP redirect response to the client. If the response has already been committed, this method throws an IllegalStateException.
18. The HttpServletResponse.addCookie(Cookie) method adds a cookie to the response stream. Cookies can also be set by setting the header but generally it is unadvisable to do so.
19. The Servlet lifecycle has 5 stages: (1) servlet class loading, (2) servlet instantiation, (3) call the init method, (4) call the service method, and (5) call destroy method.
20. The container initializes the servlet instance by calling the init method of the Servlet interface only once in its lifetime with a unique (per servlet declaration) object implementing the ServletConfig interface.
21. When the servlet container determines that a servlet should be removed from service, it calls the destroy method of the Servlet interface to allow the servlet to release any resources it is using and save any persistent state.
The Structure and Deployment of Web Applications
22. A Web application exists as a structured hierarchy of directories. The root of this hierarchy serves as the document root for files that are part of the application.
23. The WEB-INF is not a part of the public document tree of the application and no file in the WEB-INF directory may be served directly to a client by the container.
24. The directory structure of a web application contains
* /WEB-INF/web.xml deployment descriptor.
* /WEB-INF/classes/ directory for servlet and utility classes.
* /WEB-INF/lib/*.jar area for Java Archive files. These files contain servlets, beans, and other utility classes useful to the Web application.
25. The error-page element contains a mapping between an error code or exception type to the path of a resource in the web application.
The DTD for error-page element is
26. The init-param element contains a name-value pair as an initialization parameter of the servlet.
The DTD for init-param element is
ServletConfig.getInitParameter() and ServletConfig.getInitParameterNames() can be used to retrieve these parameters.
27. The mime-mapping element defines a mapping between an extension and a mime type.
The DTD for mime-mapping element is
28. The servlet element contains the declarative data of a servlet. If a jsp-file is specified and the load-on-startup element is present, the JSP should be precompiled and loaded.
The DTD for the above is
29. The servlet-mapping element defines a mapping between a servlet and a url pattern.
The DTD for the servlet-mapping is
30. The welcome-file-list contains an ordered list of welcome file elements.
The DTD is
31. Web applications can be packaged and signed into a Web ARchive (WAR) format file using the standard Java archive tools.
32. A WAR usually contains the following resources:
* Servlets, JavaServer Pages (JSP), Custom Tag Libraries
* Server-side utility classes (database beans, shopping carts, and so on)
* Static web resources (HTML, image, and sound files, and so on)
* Client-side classes (applets and utility classes)
33. The directory structure of a Web application consists of two parts. The first part is the public directory structure containing HTML/XML documents, JSP pages, images, applets, and so on. The container appropriately serves the directory's contents against incoming requests. The second part is a special WEB-INF directory that contains the following files and directories:
* web.xml - the web application deployment descriptor and may be tld files directly under the WEB-INF or under any of the sub-folders
* classes/ - a directory that contains server-side classes: servlet, utility classes, and JavaBean components
* lib/ - a directory that contains JAR archives of libraries (tag libraries and any utility libraries called by server-side classes)
* tags/ - a directory that contains Tag files
The Web Container Model
34. Context parameters are shared across the entire web application whereas Servlet initialization parameters are unique to the servlet.
35. The context-param element contains the declaration of a web application's servlet context initialization parameters.
The DTD is
36. The methods ServletContext.getInitParameter() and ServletContext. getInitParameterNames() could be used to access the servlet context initialization parameters.
37. A Servlet can store attributes within three scopes:
request: Managed by ServletRequest interface and valid only for the current request
session: Managed by HttpSession interface and available to any servlet in the same session
context: Managed by ServletContext interface and available to any servlet that is part of the same web application
38. The following methods are used to set, get and remove the attributes. They are available in ServletRequest, HttpSession, and ServletContext:
* getAttribute: Returns the value of the named attribute as an Object, or null if no attribute of the given name exists.
* getAttributeNames: Returns an Enumeration containing the names of the attributes available or an empty Enumeration if the object has no attributes available to it.
* setAttribute: Stores an attribute in this object. If the object passed is null, the effect is the same as calling removeAttribute(String).
* removeAttribute: Removes the object bound with the specified name.
39. The order which the container uses in building the chain of filters is:
* First the
* Next the
40. A Filter could be declared as follows:
and mapped as
41. A filter could use DISPATCHER element with four valid values: FORWARD, REQUEST, INCLUDE, and ERROR.
42. The four wrapper classes javax.servlet.ServletRequestWrapper, javax.servlet.ServletResponseWrapper, javax.servlet.http.HttpServletRequestWrapper, and javax.servlet.http.HttpServletResponseWrapper
implement their respective interfaces (e.g. ServletRequest, ServletResponse, HttpServletRequest, and HttpServletResponse).
43. Servlet Life Cycle Events
Object Event Listener Interface Event Class Methods
context Initialization and destruction ServletContextListener ServletContextEvent contextInitialized
contextDestroyed
Attribute added, removed, or replaced ServletContextAttribute
Listener ServletContext
AttributeEvent attributeAdded
attributeRemoved
attributeReplaced
HTTP Session Created and destroyed HttpSessionListener HttpSessionEvent sessionCreated
sessionDestroyed
Migaration: activated and passivated HttpSessionActivationListener HttpSessionEvent sessionWillPassivate
sessionDidActivate
Attribute added, removed, or replaced HttpSessionAttributeListener HttpSessionBinding
Event attributeAdded
attributeRemoved
attributeReplaced
Object bound or unbound HttpSessionBindingListener HttpSessionBinding
Event valueBound
valueUnbound
Servlet Request Initialized and destroyed ServletRequestListener ServletRequestEvent requestInitialized
requestDestroyed
Attribute added, removed, or replaced ServletRequestAttribute
Listener ServletRequest
AttributeEvent attributeAdded
attributeRemoved
attributeReplaced
44. Except HttpSessionBindingListener and HttpSessionActivationListener, the rest of the listeners have to be configured in web.xml. A sample configuration could be the following:
45. HttpSessionBindingListener has to be implemented by the session attribute, which needs notification, rather than being implemented by a separate listener class.
46. RequestDispatcher can be obtained in three ways:
* ServletContext.getRequestDispatcher(String path): Starting from the context path. should start with '/'
* ServletRequest.getRequestDispatcher(String path): Starting from the request path
* ServletContext.getNamedDispatcher(String name): Starting from the name of a servlet known to the ServletContext, i.e. one that is mapped in web.xml.
47. The forward method of the RequestDispatcher interface may be called by the calling servlet only when no output has been committed to the client whereas include method can be called any time.
48. Additional request scoped attributes are added when the Request Dispatcher isn't obtained using the getNamedDispatcher() method.
Session Management
49. The session object can be obtained by
HttpServletRequest.getSession()
HttpServletRequest.getSession(boolean create)
Both the methods return the current session associated with this request, or, if the request does not have a session, it creates one (unless the boolean argument is false).
50. A session is "new" if the client does not yet know about the session or if the client chooses not to join the session. It can be tested by using HttpSession.isNew().
51. A session could be implemented using the following:
* Cookies: The name of the session tracking cookie id is JSESSIONID. It can be checked using HttpServletRequest.isRequestedSessionIdFromCookie() method.
* URL rewriting: The session uses URL to communicate the session id. The URL would be in the form of http://myserver/mywebapp/someresource.jsp;jsessionid=1234 with "jsessionid" as the session tracking ID. The method HttpServletRequest.isRequestedSessionIdFromURL() can be used to check whether the requested session ID came in as part of the request URL.
* Secure Sockets Layer (SSL): The information in the SSL can be used to track the session.
52. The invalidate() method of the HttpSession interface expires the current session. It causes the representation of the session to be invalidated and removed from its context.
53. Session timeout can be configured
1. Declaratively using the session-config element in web.xml as
It specifies sessions to be timed out after 10 min of inactivity. Sessions will never expire if the timeout is specified as 0 or less.
2. Programmatically using the API
* HttpSession.setMaxInactiveInterval(int seconds)
* int HttpSession.getMaxInactiveInterval()
Time is specified in seconds. Session will never expire if the timeout period for a session is set to -1 (note that a value of 0 will not give an infinite timeout).
54. URL rewriting could be done using
* HttpServletResponse.encodeURL(String): Encodes the specified URL by including the session ID in it, or, if encoding is not needed, returns the URL unchanged.
* encodeRedirectURL(String): Encodes the specified URL for use in the sendRedirect method or, if encoding is not needed, returns the URL unchanged.
Web Application Security
55. The four mechanisms of security are:
* Authentication: The means by which communicating entities prove to one another that they are acting on behalf of specific identities that have access to the system is called authentication. For example, a customer logs in to the bank's web site using his login and password to prove to the system that he is really the one what he claims to be.
* Authorization: The means by which interactions with resources are limited to collections of users or programs for the purpose of enforcing integrity, confidentiality, or availability constraints is called authorization. For example, a manager can see the details of all the employees whereas an employee can see only his details.
* Data Integrity: The means used to prove that information has not been modified by a third party while in transit is called data integrity. For example, if you send a file and its checksum separately, the receiving party can compute the checksum of the file and match it with the received checksum to ensure the contents of the file was not tampered on the way.
* Confidentiality (a.k.a. Data Privacy): The means used to ensure that information
is made available only to users who are authorized to access it is called confidentiality. For example, you could encrypt the data and send. The receiver who has the decrypting key alone would be able to read the data.
56. Security constraints are a declarative way of defining the protection of web content. A security constraint associates authorization and/or user data constraints with HTTP operations on web resources. A security-constraint element consists of the following elements:
* web-resource-collection
* auth-constraint
* user-data-constraint
57. The HTTP operations and web resources to which a security constraint applies (i.e. the constrained requests) are identified by one or more web resource collections. A web-resource-collection element consists of the following elements:
* url-pattern
* http-method
58. An authorization constraint establishes a requirement for authentication and names the authorization roles permitted to perform the constrained requests. A user must be a member of at least one of the named roles to be permitted to perform the constrained requests. The auth-constraint element consists of the role-name element.
59. A user data constraint specifies the strength of the required protection in the communication channel. It contains the transport-guarantee element which takes the following values:
* INTEGRAL - No one should be able to modify the data during transit
* CONFIDENTIAL - No one should observe the data during transit
* NONE - No transport guarantee required
60. 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. The child elements are:
* auth-method
* realm-name
* form-login-config: only when the auth-method is FORM
* form-login-page
* form-error-page
61. The security-role element contains the definition of a security role. The child element role-name specifies the security role name.
62. A web client can authenticate a user to a web server using one of the following mechanisms:
* HTTP Basic Authentication: Password is base 64 encoded and transmitted.
* HTTP Digest Authentication; Password is encrypted and transmitted.
* HTTPS Client Authentication; Data is encrypted using public-key cryptography and transmitted.
* Form Based Authentication; Same as HTTP Basic except that the login dialog box can be customized.
63. When using FORM based authentication, the action of login form should be 'j_security_check' and the user name field should be 'j_username' and password field should be 'j_password'.
For example,
The JavaServer Pages (JSP) Technology Model
64. The following table lists some of the elements in JSP pages and JSP documents:
Element JSP Page JSP Document
Directives
Declaration
Expression
Scriptlet
Template text Any text
65. The page directive defines number of page dependent properties. The important attributes are the following:
"import"
It defines the packages that should be imported by the generated servlet.
For example,
"session"
It indicates that the page participates in HTTP session. If true, then the implicit script language variable named session references the current/new session for the page. If false, then the page does not participate in a session; the
session implicit variable is unavailable. The default value is true.
For example,
"contentType"
It defines the MIME type and the character encoding for the response of the JSP page.
For example,
or
"isELIgnored"
It defines whether EL expressions are ignored (if the value is true) or evaluated (if the value is false) for this page.
For example,
66. The include directive is used to insert a file into servlet class at the time when JSP file is translated into servlet.
For example,
67. The taglib directive is used to declare custom tags available to the page.
68. A JSP undergoes the following lifecycle methods:
* jspInit()
* _jspService()
* jspDestroy()
69. The following table describes the JSP Implicit objects.
Implicit Object Type Description
request Protocol dependent subtype of:javax.servlet.ServletRequestex:javax.servlet.http.HttpServletRequest in case of HTTP HTTP request data, as well as providing a context for associating request-specific data.
response Protocol dependent subtype of:javax.servlet.ServletRequestFor example,javax.servlet.http.HttpServletResponse in case of HTTP The page's response back to the client
pageContext javax.servlet.jsp.PageContext A single API to manage the various scoped attributes
session javax.servlet.http.HttpSession The session associated with the request
application javax.servlet.ServletContext The context in which the servlet is running
out javax.servlet.jsp.JspWriter The output stream used to send the response
config javax.servlet.ServletConfig The servlet configuration object
page java.lang.Object The JSP page itself
exception java.lang.Throwable For error pages, the uncaught exception
70. A tag library can be declared in web.xml as
71. The scripting-invalid element is a subelement of jsp-property-group. Allowed values are true and false. Scripting elements can be disabled by setting the scripting-invalid element to true.
The el-ignored element is a subelement of jsp-property-group. Allowed values are true and false. EL can be disabled by setting the el-ignored element to true.
The following fragment disables both EL and scripting for all JSP Pages:
72. Include directive includes a static file in a JSP page, parsing the file's JSP elements. The include directive is processed when the JSP page is translated into a servlet class.
73. jsp:include action includes a static file or the result from another web component. The difference from the include directive is that not the source of the JSP, but its output is included. The included JSP page is being executed within the servlet engine and it's output is returned to the calling page.
For example,
74. Use Include directive when including static files which change very rarely, for example, Copyright file.
75. Use Include action when the included file is expected to be changed often, for example, a stock quotes file
Building JSP Pages Using the Expression Language (EL)
76. A primary feature of JSP technology version 2.0 is its support for an Expression Language (EL). An expression language makes it possible to easily access application data stored in JavaBeans components.
77. EL expressions are enclosed by the ${ } characters and can include literals. For example, ${ELExpression}.
78. Literal values that contain the ${ characters must be escaped as ${'${'}.
79. EL expressions can be used in:
* Static text
* Any standard or custom tag attribute that can accept an expression
80. The JSP container evaluates a variable that appears in an expression by looking up its value according to the behavior of PageContext.findAttribute(String). For example, when evaluating the expression ${product}, the container will look for 'product' in the page, request, session, and application scopes and will return its value. If 'product' is not found, null is returned.
81. The table describes the available implicit objects:
Implicit Object
Description
pageContext The context for the JSP pageProvides access to various objects including:
82. servletContext: The context for the JSP page's servlet and any Web components contained in the same application
83. session: The session object for the client
84. request: The request triggering the execution of the JSP page
85. response: The response returned by the JSP page
param A java.util.Map that maps parameter names to a single String parameter value. Equivalent to ServletRequest.getParameter(String name).
paramValues A java.util.Map that maps parameter names to a String[] of all values for that parameter. Equivalent to ServletRequest.getParameterValues(String name).
header A java.util.Map that maps parameter names to a single String parameter value. Equivalent to HttpServletRequest.getParameter(String name).
headerValues A java.util.Map that maps header names to a String[] of all values for that header. Equivalent to HttpServletRequest..getHeaders(String s)
cookie A java.util.Map that maps cookie names to a single Cookie object. Equivalent to HttpServletRequest.getCookies().
initParam A java.util.Map that maps context initialization parameter names to their String parameter value. Equivalent to ServletContext.getInitParameter(String name).
pageScope A java.util.Map that maps page-scoped attribute names to their values.
requestScope A java.util.Map that maps request-scoped attribute names to their values.
sessionScope A java.util.Map that maps session-scoped attribute names to their values.
applicationScope A java.util.Map that maps application-scoped attribute names to their values.
82. The "." operator is used for accessing properties whereas "[]" operator is used for accessing collections (arrays, lists, maps).
83. The JSP expression language unifies the treatment of the "." and "[]" operators. Thus a.b is equivalent to a["b"]. That is, the identifier b is used to construct a literal value and then the [] operator is used with that value.
84. Although a.b is equivalent to a["b"], the reverse is not true.
85. The following table shows the common usage of "." and "[]" operators.
Type
Method
Legal
Illegal
86. List listObj.get(1) ${list[1]}
87. ${list["1"]}
${list.1}
88. Map mapObj.get("key") ${map["key"]}
${map.key}
89. Array Array.get(arrayObj,1) ${arrayObj[1]}
90. ${arrayObj["1"]}
${arrayObj.1}
91. JavaBean employee.getName() ${employee.name}
92. ${employee["name"]}
93. ${employee['name']}
86. The following table summarizes the Arithmetic, Relational, and Logical operators in EL:
EL Operators
Arithmetic Relational Logical
· Addition: + · == (eq) · && (and)
· Subtraction: - · != (ne) · (or)
· Multiplication: * · < (lt) · ! (not) · Division: / (div) · > (gt)
· Remainder: % (mod · <= (le) · >= (ge)
87. The operator precedence is as follows:
Highest to lowest, left-to-right
[] .
()
- (unary) not ! empty
* / div % mod
+ - (binary)
< > <= >= lt gt le ge
== != eq ne
&& and
or
? :
88. An EL function is given a name and a static method in a specific class that will implement the function.
89. Any EL function has to be defined in the Tag Library Descriptor (TLD). The class specified in the TLD must be a public class, and must be specified using a fully qualified class name (including packages). The specified method must be a public static method in the specified class, and must be specified using a fully qualified return type followed by the method name, followed by the fully qualified argument types in parentheses.
For example, the following TLD fragment describes a function with name "caps" that is intended to capitalize the string passed:
...
java.lang.String capitalize(java.lang.String)
Building JSP Pages Using Standard Actions
90. The jsp:useBean action declares a variable in the JSP and associates an instance of a Javabean with it.
The syntax of the jsp:useBean action is
where beandetails can be one of the following:
* class="className"
* class="className" type="typeName"
* beanName="beanName" type="typeName"
* type="typeName"
91. The following table illustrates the various attributes of jsp:useBean action:
Attribute Description
id The case sensitive name used to identify the object instance.
scope The scope within which the reference is available. The default value is page.
class The fully qualified (including package name) class name.
beanName The name of a Bean, as you would supply to instantiate() method in the java.beans.Beans class. This attribute can also be a request time expression.
type An optional attribute specifies the type of the class, and follows standard java casting rules. The type must be a superclass, an interface implemented by the class or the class itself. The default value is the same as the value of the class attribute
92. The jsp:setProperty action assigns values to the bean's properties. The syntax is
where properties can be one of the following:
· property="*"
· property="propertyName"
· property="propertyName" param="parameterName"
· property="propertyName" value="propertyValue"
93. The following table illustrates the various attributes of jsp:setProperty action:
Attribute Description
name The name of a bean instance defined by a jsp:useBean action or some other action
property The name of the property whose value will be set. If it is set to * then the tag will iterate over the current ServletRequest parameters, matching parameter names and value type(s) to property names and setter method type(s), setting each matched property to the value of the matching parameter. If a parameter has a value of "", the corresponding property is not modified.
param The name of the request parameter whose value is given toa bean property.
value The value to assign to the given property. This attribute can accept a request-time attribute expression as a value.An action may not have both param and value attributes.
94. The
95. The following table illustrates the various attributes of jsp:getProperty action:
Attribute Description
name The name of the object instance from which the property is obtained.
property Names the property to get.
96. Functionally the jsp:include and jsp:forward actions are similar to RequestDispatcher.include() and RequestDispatcher.forward() methods.
97. A jsp:include action provides for the inclusion of static and dynamic resources in the same context as the current page.
Syntax:
A simple request-time inclusion
Passing parameters to the requsted resource
{
98. The following table illustrates the various attributes of jsp:include action:
Attribute Description
page The URL is a relative urlSpec. Relative paths are interpreted relative to the current JSP page. Accepts a request-time attribute value
flush Optional boolean attribute. If the value is true, the buffer is flushed now. The default value is false.
99. A jsp:forward action delegates the request to the forwarded resource and terminates the execution of the current page.
Syntax:
A simple request-time forward
Passing parameters to the requsted resource
{
100. The following table illustrates the various attributes of jsp:forward action:
Attribute Description
page The URL is a relative urlSpec. Relative paths are interpreted relative to the current JSP page. Accepts a request-time attribute value
101. The flush attribute is only valid for jsp:include action and not for jsp:forward action.
102. In both jsp:include and jsp:forward actions, the attribute to refer the resource is "page" and not "file."
103. The jsp:param element is used to provide key/value information. This element is used in the jsp:include, jsp:forward, and jsp:params elements.
Syntax:
Both the attributes are mandatory: name and value. The name attribute indicates the name of the parameter, and value, which may be a request-time expression, indicates its value.
Building JSP Pages Using Tag Libraries
104. The taglib directive in a JSP page declares that the page uses a tag library, uniquely identifies the tag library using a URI and associates a tag prefix that will distinguish usage of the actions in the library.
The syntax is:
<%@ taglib ( uri="tagLibraryURI" tagdir="tagDir" ) prefix="tagPrefix" %>
105. The following table describes the attributes of taglib directive:
Attribute Description
uri Either an absolute URI or a relative URI specification that uniquely identifies the tag library descriptor associated with this prefix. The URI is used to locate a description of the tag library.
tagdir Indicates this prefix is to be used to identify tag extensions installed in the /WEB-INF/tags/ directory or a subdirectory. A translation error will occur
106. if the value does not start with /WEB-INF/tags/
107. if the value does not point to a directory that exists
108. if used in conjunction with the uri attribute
prefix Defines the prefix string in
106. JSP tags can cooperate with each other by sharing objects. The object created by the enclosing tag of a group of nested tags is available to all inner tags.
107. The JSTL core tags can be divided into the following four categories:
· General-purpose
o
o
o
o
· Conditional actions
o
o
o
o
· Iterator actions
o
o
· URL Related
o
o
o
o
108. The core tag library is referred in the page as
<%@ taglib prefix="c" uri="http://java.sun.com/jstl/core" %>
Building a Custom Tag Library
109. Classic tag handlers implement either the Tag, IterationTag, or BodyTag interface or they extend from the TagSupport or BodyTagSupport classes.
110. The various methods and constants defined in the classic tag interfaces are as follows:
Tag
Methods
· doStartTag: Process the end tag for this instance
· doEndTag: Process the end tag for this instance
Constants
· SKIP_BODY indicates that body evaluation should be skipped.
· EVAL_BODY_INCLUDE indicates that the tag body should be evaluated into the existing output stream.
· SKIP_PAGE indicates that the rest of the page should be skipped.
· EVAL_PAGE indicates that page evaluation should continue.
IterationTag
Methods
· doAfterBody(): Process body (re)evaluation
Constants
· EVAL_BODY_AGAIN indicates the reevaluation of the body.
BodyTag
Constants
· EVAL_BODY_BUFFERED indicates the creation of a new buffer, a BodyContent on which to evaluate the body of this tag.
111. The doStartTag() can return
· SKIP_BODY
· EVAL_BODY_INCLUDE
· EVAL_BODY_BUFFERED
112. The doAfterBody() can return
· EVAL_BODY_AGAIN
· SKIP_BODY
113. The doEndTag() can return
· SKIP_PAGE
· EVAL_PAGE
114. A PageContext is an object that provides a context to store references to objects used by the page, encapsulates implementation-dependent features, and provides convenience methods.
115. Using the PageContext, the following tasks can be done:
* Storing, Retrieving, and Finding attributes in Application, Session, Request, and Page scopes
* Accessing the JSP implicit objects
* Forward and Include of the current request
* Error page exception processing
116. To access an object created by an enclosing tag, a tag handler must first obtain its enclosing tag with either of the following static method invocations:
* TagSupport.getParent() - Used to access immediate parent tag
* TagSupport.findAncestorWithClass(from, class) - Used to access any arbitrary tag ancestor
The parent handler's statically and dynamically created objects can be obtained once the parent object is retrieved.
117. A "Simple" tag in Java can implement either SimpleTag interface or extends SimpleTagSupport class. The tag handler should implement only one
method: doTag().
118. Unlike classic tag handlers, SimpleTag extends JspTag instead of extending from Tag. Tag interface relies on PageContext whereas SimpleTag only relies on JspContext.
119. The body of a Simple Tag, if present, is translated into a JSP Fragment and passed to the setJspBody method. Because JSP fragments do not support scriptlets, the
120. Tag files are written using JSP syntax and they don't need to be compiled. They are compiled as they are invoked.
121. Tag files can be placed in two locations.
* /META-INF/tags directory(or its sub-directory
) in a JAR file installed in the /WEB-INF/lib/
* /WEB_INF/tags directory
A tag library descriptor is required in the first case where as it is not required for the second case.
122. A tag file has the .tag or .tagx extension and can also include other files that contain a common resource. An include file for a tag file has a .tagf extension.
123. In JSP, you need the taglib directive as usual, with the prefix attribute to identify your tag library throughout the page. But instead of a uri attribute, you have a tagdir attribute. The tagdir attribute refers to the WEB-INF/tags directory or any subdirectory below WEB-INF/tags.
J2EE Patterns
125. The following table summarizes the scenarios under which a particular pattern could be useful along with its pros and cons:
Intercepting Filter
Scenario Significance
When the presentation-tier request handling mechanism receives many different types of requests, which require varied types of processing, Some requests need to be simply forwarded to the appropriate handler component, while other requests must be modified, audited, or uncompressed before being further processed, which results in
126. Nested if/else conditional checks
127. A fragile code that breaks when new features/modifications are made.
128. Copy-and-paste style of programming
Pros
129. Centralizes control with loosely coupled handlers
130. Improves reusability
131. Declarative and flexible configuration
Cons
132. Information sharing is inefficient
Front Controller
Scenario Significance
The system requires a centralized access point for presentation-tier request handling to support the integration of system services, content retrieval, view management, and navigation, which results in
133. Duplicate code
134. Blended view content and view navigation
135. Unmaintainable code
136. Centralizes control
137. Improves manageability of security
138. Improves reusability
Service
Scenario Significance
Service lookup and creation involves complex interfaces and network operations which often leads to
139. Vendor dependency in the application
140. Duplicated Java Naming and Directory Interface (JNDI) code
141. Repeated creation of context and looking up, which is slow performing
142. Abstracts complexity
143. Provides uniform service access to clients
144. Facilitates adding new business components
145. Improves network performance
146. Improves client performance by caching
Business Delegate
Scenario Significance
Presentation-tier components interact directly with business services. This direct interaction exposes the underlying implementation details of the business service application program interface (API) to the presentation tier which results in
147. Tight coupling between presentation-tier components and business services
148. Increased network invocations reducing performance
149. Lack of client-side caching mechanism or aggregating service.
150. Clients handling networking issues
Pros
151. Reduces Coupling, Improves Manageability
152. Translates business service exceptions
153. Implements failure recovery and thread synchronization
154. Exposes simpler, uniform interface to business tier
155. Better performance
156. Hides remoteness
Cons
157. Introduces additional layer
Transfer Object
Scenario Significance
When application clients interact with enterprise beans, there is a possibility that some methods exposed by the business components return data to the client. Often, the client invokes a business object's get methods multiple times until it obtains all the attribute values. This leads to
158. Increased network overhead
159. Reduced performance
Pros
160. Simplifies entity bean and remote interface
161. Transfers more data in fewer remote calls
162. Reduces network traffic
163. Reduces code duplication
Cons
164. May introduce stale transfer objects
165. May increase complexity due to synchronization and version control
166. Concurrent access and transactions may lead to inconsistent transfer objects
Model View Controller
Scenario Significance
An application containing a mixture of data access code, business logic code, and presentation code leads to
167. Unmaintainable code due to strong interdependencies and ripple effects
168. Addition of new views/clients becomes near to impossible
169. Prevents reuse as code is highly coupled
170. Promotes copy-and-paste style of programming
Pros
171. Re-use of model components
172. Easier support for new types of clients
Cons
173. Increased design complexity
ALL THE BEST
Subscribe to:
Posts (Atom)
Posts
