Submitted by heartin on Thu, 03/26/2015 - 08:25
HttpSessionBindingListener interface should be implemented by classes that may be bound into sessions as attributes and if they want to know when they were bound. When an object which implements this interface is bound to a session or unbound from the session, the container will call its valueBound and valueUnbound methods respectively. Since the interface is added by the attributes that are added to the session themselves and cannot listen to any other attributes, you don’t have to mention it in the web.xml file or have the @WebListener annotation.
Submitted by heartin on Fri, 03/20/2015 - 09:24
What are the three ways in which you can tell the container that your class is a servlet?
Compare filters with RequestDispatcher mechanism.
Can you include or forward to filters using the RequestDispatcher mechanism?
What will happen if you call two RequestDispatcher forwards or includes from within a servlet's doXXX method?
Can you use wrappers to have two RequestDispatcher forward requests without any exception?
Submitted by heartin on Thu, 03/19/2015 - 21:38
If you need to extend the functionality of request or response objects, there are wrapper classes that can wrap around current request or response. The wrapper classes implements the required interfaces so that we can pass it to any place that expects those interface implementations. These wrappers will simply delegate the calls to the default container implementation of the request and response interfaces.
Submitted by heartin on Sat, 03/14/2015 - 20:07
When a request is forwarded or included using the RequestDispatcher mechanism, the container may change the URI paths (request uri, context path, servlet path, path info and query string) in the request object to reflect new path.
This can be demonstrated using a simple example.
First, we will create an util class with a method to print the current values of all these URI path attributes and call it from a normal servlet, included servlet and forwarded servlet.
Submitted by heartin on Sat, 03/14/2015 - 13:22
All calls to other resources in a web application should go through the container. RequestDispatcher is a mechanism provided by the container for that purpose. Container will give us an implementation of the RequestDispatcher interface and we can use it to delegate control to other resources in the application.
You can obtain RequestDispatcher object from
Submitted by sneha on Sat, 03/14/2015 - 12:50
In this demo, we will create a listener and then add, remove and delete attributes from the request object so that the listener methods are invoked.
Follow the below steps in order. You should have already configure apache tomcat with eclipse as mentioned in configuring-apache-tomcat-with-eclipse.
Create a new Dynamic Web project in eclipse as:
Submitted by heartin on Sat, 03/07/2015 - 19:33
All web applications in a Java EE server have their own unique context roots. A web application's context is reprecented by an implementation of the ServletContext interface. Each web application has only one servletContext and one ServletContext belongs to only one application. Servlets need to make use of the container interface to communicate with other components outside of their application or even within their application.
A servlet can use a ServletContext object for various purposes, including:
Submitted by heartin on Sat, 01/31/2015 - 07:12
RequestDispatcher mechanism used for forwarding to and including other resources. We will understand the basics of RequestDispatcher mechanism using a simple exercise.
Before proceeding, you need to configure your eclipse and tomcat. I am using eclipse Eclipse Java EE IDE for Web Developers version: Luna and Apache Tomcat version 8.0.18. Apache Tomcat version 8.0.18 support Servlet Spec 3.1, JSP Spec 2.3, EL Spec 3.0, WebSocket spec 1.1 and support java version 7 and above.