Remember the code?

Chapter 13 Filters and wrappers

Filters can intercept request before servlet and/or process reponse after servlet is completed.
Filters can be chained with other filters.
You must implement all methods : init() , doFilter() , destroy().

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

import javax.servlet.* ; // Filter and FilterChain are located here
public class BeerRequestFilter implements Filter {
	private FilterConfig fc;
 
	//You must implement init & destroy methods
	public void init (FilterConfig config) throws ServletException {
		this.fc=config;
	}
	// doFilter args are not HttpServletRequest and HttpServletResponse.
	public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws
			ServletException, IOException {
		HttpServletRequest httpReq = (HttpServletRequest) req; 
		// This casting is possible because the req is in fact HttpServletRequest!
 
		String name = httpReq.getRemoteUser();
		if(name != null) {
			fc.getServletContext().log("User " + name + " is updating" );
		}
		chain.doFilter(req.resp); //calling next filter
	}
	//You are required to implement destroy()
	Public void destroy(){
	}
}

DD

<filter>
	<filter-name>BeerRequest</filter-name> <!-- mandatory -->
	<filter-class>com.examle.BeerRequestFilter</filter-class> <!-- mandatory -->
	<init-param>
		<param-name>LogFileName</param-name>
		<param-name>UserLog.txt</param-name>
	</init-param>
</filter>

*Two ways to define filter-mapping : with <servlet-name> or <url-pattern>
Declare filter mapping with a URL pattern

<filter-mapping>
	<filter-name>BeerRequest</filter-name>
	<url-pattern>*.do</url-pattern>
</filter-mapping>

Declare filter mapping to a servlet name

<filter-mapping>
	<filter-name>BeerRequest</filter-name>
	<servlet-name>AdviceServlet</servlet-name>
</filter-mapping>

* One filter mapped multiple resources: Matching <url-pattern> processed first then Matching <servlet-name> are processed. Then in the order of they are list up in the DD.

*Dispatcher element is to define which action this filter is responsible to listen.

<filter-mapping>
<filter-name>BeerRequest</filter-name>
	<url-pattern>*.do</url-pattern>
	<dispatcher>REQUEST</dispatcher>  
	'dispatcher' can be used 0 ~ 4 time. Default is REQUEST
		And/or
	<dispatcher>INCLUDE</dispatcher>
		And/or
	<dispatcher>FORWARD</dispatcher>
		And/or
	<dispatcher>ERROR</dispatcher>
</filter-mapping>

Filter for reponse

For the same Filter class, define post activities after the chain.doFilter(req,resp); and they will be run after servlet is finished.

However, the response is already commited by servlet. You will need to create a new HttpServletReponse implemented class. Make this to use customs output stream and pass it down to servlet in chain.doFilter.

But creating a custom reponse class directly from the HttpServletResponse interface. So we extend wrapper classes.

Wrapper class wraps the real request or response and delegates call to the real thing(HttpServletResponse or HttpServletRequest)

• ServletRequestWrapper
• HttpServletRequestWrapper
• ServletResponseWrapper
• HttpServletResponseWrapper

Wrapper is usually called as “Decorate Pattern”

Chapter 14 Enterprise Design Patterns

A software design pattern is a “repeatable solution for a commonly-occuring software problem”.

Characteristics explained before we go into patterns

• Code to interface : polymorphism
• Separation of concern & cohesion : separating concerns increased cohesion
• Hide Complexity
• Loose Coupling : less two classes know each other . coding to interfaces
• Remote Proxy : an object local to the “client” object that pretends to be a remote object.
• Increase Declarative Control : using DD instead of hard coding

* J2EE pattern for Remote model Components : What to do when Models are remote?
- JNDI: Java Naming & Directory Interface => gives a network a centralized location to find things.
- RMI; Remote Method Invocation => pretend that you’re invoking local object . Local stub act as proxy ‘ server skeleton object similar to stub handle the request.

1. Create a remote interface - both STUB (proxy) and remote actual Model service will implement this interface
2. Create Actual model with the interface. This includes code that registers the model with a well-known registry such as JNDI & RMI registry
3. Generate Stub & Skeleton object. RMI compiler rmic (command) create proxies
4. Start Model Service (register itself and wait for calls)

* Business Delegate
Connect Service Module (JNDI) and talk to the stub for the business methods.

*Service Locator : JNDI access module.

*Transfer Object: JSP can use stub object using EL, but it will make a network call each time( Expensive) So, we bring the actual Model object to local. However the trade off is that the data is not up-to-date (stale)

*Front Controller : a single component , usually a servlet but possibly JSP act as the single control point for the presentation tier of a web application.

Summary

*Business Delegate : Act as proxy. Handles communication details & Errors

• Hiding complexity
• Coding to interface
• Loose coupling
• Sepratino of concerns

*Service Locator :
- obtains InitialContext Objects
- performs registry lookups (JNDI, RMI, UDDI,COS)
- handles communication details & exceptions
- can cache result for better performance

• Hiding complexity
• Separation of Concerns

*Transfer Object
- provides a local representation of a remote entity
- the data is stale

• Reduce network traffic

*Intercepting Filter:
- can intercept & modify request before servlet
- can intercept & modify response after servlet
- deployed using DD
- executed in chains
- must implement container call back methods (init,doFilter,destroy)

• Cohesion
• Loose coupling
• Increasing declarative control

*MVC

• Separation of concerns
• Loose coupling

*Front Controller

• Hiding complexity
• Separation of concerns
• Loose coupling

And this is finally the end.

Hope you had some fun reviewing the cram sheets and Good luck with your certification test!