Kunal Jag

Before a deployed Web application can begins processing client requests, the container performs a number of steps to deliver its services. Following is the order a servlet container follows:

Listener classes
The container instantiates an instance for each event listener identified by a <listener> element in the deployment descriptor.

Filters
Next, the container instantiate an instance of each filter identified by a <filter> element in the deployment descriptor and calls each filter instance�s init() method.

Servlets
Finally, an instance of each registered servlet identified by a <servlet> element that includes a <load-on-startup> element in the order defined by the <load-on-startup> element values, and call each servlet�s init() method.

Regards,

The exam is about servlets 2.4, so be careful if you start messing with Servlets 2.5 specification.

That's a very apt statement. In Servlets 2.4 spec, web.xml is a mandatory artifact. That said, it's always good to know about new changes in the spec.

About web.xml
The servlet specification mandates the DD file- web.xml to be a part of every Web application. Please note that with Java EE 5, the Web application DD is optional for simple applications containing JSP pages and static files. If your web module does not contain any servlets, filter, or listener components then it does not need a DD.

About META-INF
When a Web application is deployed as a WAR, the container creates a directory called META-INF inside the document root, the META-INF contains dependencies and information useful to Java archive tools.

Regards,

Which three interfaces need to be declared in the web application descriptor?

Following are the different event listeners which can be configured to be used in a Web application:

Servlet Context Events
javax.servlet.ServletContextListener
javax.servlet.ServletContextAttributeListener

To receive notification events, the listener implementation class must be configured in the DD.


Request Events
javax.servlet.ServletRequestListener
javax.servlet.ServletRequestAttributeListener

To receive notification events, the listener implementation class must be configured in the DD.

Session Events
javax.servlet.http.HttpSessionListener
javax.servlet.http.HttpSessionAttributeListener
javax.servlet.http.HttpSessionBindingListener
javax.servlet.http.HttpSessionActivationListener

There's no need to configure the HttpSessionActivationListener and HttpSessionBindingListener implementation classes in the DD.

Regards,

So, my question is if we synchronize the get or post method and when client is working on that servlet then other client has to wait or not because of synchronization issues?

Absolutely, Synchronizing the entire service(), doGet() or doPost() method will kill concurrency. Doing so will cause extra delays and performance penalty. It's always advisable to use short synchronized blocks.

Regards,

Following are different match types one can define in the Deployment Descriptor (DD) web.xml file.

Exact Match
An exact match ends with an extension, like .do or .process. This type of match has the highest priority and resolved first if one such exists.

Example:
<url-pattern> /process.do < /url-pattern>

Directory Match
A directory match ends with an asterisk (*).
Example:
<servlet-mapping> <servlet-name>three</servlet-name> <url-pattern>/fooStuff/*</url-pattern> </servlet-mapping>

Extension Match
Extension MatchStarts with an asterisk and ends with an extension. This type of match has the least priority and resolved if the other two match types are not resolved.

Example:
<url-pattern> *.do < /url-pattern>

I believe that by writing the SCJP exam you�ve already switched to Java SE. SCWCD will be a crucial benchmark for your skills on the presentation tier of the Java EE platform. Going further, you can enhance your skills by learning business tier technologies like EJB 3 and further compliment your skill set by learning Hibernate ORM.

Regards,

The default value for isELIgnored page directive depends on the web.xml artifact; if your web.xml specifies servlets 2.3 (corresponding to JSP 1.2) or earlier, the default is true. However, If your web.xml specifies servlets 2.4 (corresponding to JSP 2.0) or earlier, the default is false. As an illustration, consider the following copde snippet from the DD which declares a deployment plan for Servlets 2.4 and JSP 2.0.

<web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee <a href="http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"" target="_blank" rel="nofollow">http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"</a> version="2.4"> <display-name>web app name here</display-name> <!-- other declarations go here --> </web-app>

Regards,

The key difference between HttpSessionBindingListener and HttpSessionAttributeListener is that in case of the former, a class itself receives notifications when it's bind to a session or unbind from a session object. Whereas, the HttpSessionAttributeListener is like a generic listener, which can be used to track all attributed which are added, removed or replaced in a session.


Regards,
[ July 04, 2008: Message edited by: Kunal Jag ]

According to Head First Servlets and JSP, HttpSessionActivationListener must be registered in the DD because it is directly related to the session and not to an attribute.

Please check the errata list of your favorite book.

Regards,

Based on my reading of the spec and the HSF book, I have not come across anything that suggests containers are required to store a specific context attribute.

Every container sets some attributes (depending on the Web server implementing the specification). For instance, Tomcat 5 sets the following context attributes:

1. org.apache.catalina.jsp_classpath
2. org.apache.catalina.WELCOME_FILES
3. javax.servlet.context.tempdir
4. org.apache.catalina.resources

The following code snippet demonstrates the same:
Enumeration attrNames=getServletContext().getAttributeNames(); while(attrNames.hasMoreElements()){ String ctxAttribute=(String) attrNames.nextElement(); out.println("<BR> Attribute Name --> "+ctxAttribute+", has value Value --> "+getServletContext().getAttribute(ctxAttribute)); }

Regards,

Dee Brown wrote:
Spring/hibernate: I have read that they go hand in hand.

That�s indeed correct. Spring is not a rip-off of any ORM framework. Instead, Spring provides easy integration points for all ORMs. For example, Spring�s HibernateTemplate provides a wrapper over Hibernate that simplifies data access code and removes boilerplate.

Anand Bhatt wrote:
Spring ,JPA

JPA, an EJB 3 sub-spec is heavily influenced by Hibernate. The coolest feature is that it supports "out-of-container" testing and can be used in Java SE environment without requiring any heavyweight application server.


Regards,
[ July 04, 2008: Message edited by: Kunal Jag ]

Which of the following listeners are not configured in the deployment descriptor? Select two choices.

a. ServletContextListener
b. ServletContextAttributesListener
c. HttpSessionAttributeListener
d. HttpSessionActivationListener
e. HttpSessionBindingListener
f. HttpSessionListener

Correct options are D and E. Like HttpSessionBindingListener, there's no need to configure the HttpSessionActivationListener implementation class in the DD.

Regards,

Propagation of IllegalStateException is a common point of confusion among many exam aspirants. Following are some scenarios which can land you in trouble:

RequestDispatcher
You can call an include action anytime, but the forward has to be called before the response is committed. Otherwise, an IllegalStateException exception will be thrown.

Session Tracking
All methods for storing, retrieving and removing attributes are called on an active session. If called on a session which has been invalidated, an IllegalStateException will be thrown.

Programmatically Setting Error Codes
If the response has already been committed, the sendError() method throws an IllegalStateException. After using this method, the response should be considered to be committed and should not be written to.

Retrieving Request Data
You can read the request body as character data using ServletRequest.getReader() method which retrieves the body of the request as character data using a BufferedReader. Care should be taken that you can�t read request parameters using any of the getParameter() methods described in this section and then attempt to read the request with the getInputStream() or getReader() method or vice versa. Any such attempt will throw an IllegalStateException.

I hope this will help.


Regards,

Implementing STM does not make servlets thread-safe

It�s indeed a bad idea to use SingleThreadModel. STM ensures that each servlet handles only one request at a time. The container may implement that behavior in several different container dependent ways. One strategy is to create a pool of servlet instances. Since only one thread is executing in a given servlet instance, this strategy appears "thread-safe". However, it gives a false impression about thread-safety as static or class variables are never thread safe. Static variables are not associated to a particular instance, and there exists only a single copy of such variables. No matter how many instances are created, it�s the same copy which is shared across all instances. Secondly, instance variables cannot be used to share data among multiple requests because the instances serving each request might be different. Thirdly, single-thread model approach doesn�t guard attributes stored in session and context scopes, they are still being shared between multiple instances.

Regards,