Sneha's Blog

Ajax with Direct Web Remoting (DWR)

2010-06-16T06:58:00.000-07:00

This is my blog entry after a long time.

Recently i have used ajax with dwr (Direct Web Remoting) and it was very useful. I would like to discuss the same this time.

DWR allows the us to call server-side Java objects from javascript with a great ease.

- Using DWR you can call server-side Java objects from javascript directly, so you can eliminate entire request-response handling code.

- DWR is deployed as a servlet within your Web application. But there is no need for you to write the servlet code to call the back end object.

- We can introduce the classes we require to call objects from. For each exposed class, DWR dynamically generates JavaScript to include in your Web page. The generated JavaScript contains stub functions that represent the corresponding methods on the Java class and also performs XMLHttpRequests behind the scenes. These requests are sent to the DWR servlet, which, in its second role, translates the request into a method call on a server-side Java object and sends the method's return value back to the client side in its servlet response, encoded into JavaScript.

- There are some utility functions provided to perform common UI tasks.

How to use it?

Ensure you have dwr.jar in your classpath.

Main components include:

- jsp event handler to call javascript.

- javascript function to call the server-side class.

- Server-side class to make the actual database call.

- dwr.xml file to expose the server-side class to the client.

Now let us look at an example.

In our jsp file, if you select a stream type, all the streams with that stream type should be populated dynamically.


<select id="streamType" name="streamType" onchange="onStreamTypeChange();"> 
 <!-- options holding the list of stream types--!>
</select>

<select id="streamDesc" name="streamDesc">
         <option value="">&nbsp;</option>
</select>

This calls the below javascript function to populate the relevant streams, whenever the value of this select list is changed (stream type is changed).


function onStreamTypeChange()

{

        l = document.findJobs.streamType;

        sST = l.options[l.selectedIndex].value;

        StreamAdapter.getStreamsForStreamType(sST, populateStreams);

 /*
  StreamAdapter           - JavaScriptName - specified in dwr.xml(explained below)
  getStreamsForStreamType - methodName
  sST                     - methodParams ...
  populateStreams         - callBack function
 */

}

This function passes the selected streamType into a method called getStreamsForStreamType of the object StreamAdapter.

After the remote method is called, the results from that method are passed to the popStreams javascript callback function(populateStreams).

- NOTE : callback function should be the last parameter. You can have multiple method params before that.


function populateStreams(data)

{

        DWRUtil.removeAllOptions("streamDesc"); // Utility functions provided by DWR

        DWRUtil.addOptions("streamDesc", data); // Utility functions provided by DWR

        /*
   if you want to access the elements inside the list, 
   then incoming list can be accessed as an array and
   elements can be accessed as below...
  
   streamDesc_1 = data[0];
   streamDesc_2 = data[1];

 */

        var l = document.findJobs.streamDesc;

        

        for(i=0; i < l.options.length; i++)

        {

          if(l.options[i].value == "<c:out value="${sessionScope.findJobs.streamDesc}" />")

          {

            l.selectedIndex = i;

          }

        }

}

This method contains the logic to adjust the DOM to reflect the data coming back from the server-side. You will see there are a couple of DWR util functions in there to remove the current options from the select list and then add new options, which have come back from the server. The function then selects a value from the new select list based on a session attribute.

StreamAdapter is a server-side class that actually makes a database call. This class takes in the parameters sent from the JS function, calls down to a DAO class to get some results and returns a List back to the client side as below.


public class StreamAdapter
{ 
  
  public List<String> getStreamsForStreamType(String streamType) throws Exception
  {
    
    CommonJobDAO dao = new CommonJobDAO();
    
    List<String> result = dao.getStreamsForStreamType(streamType);
    
    return result;
  }
 
  public List<StreamBean> "getStreamDetails(int stream_id){
 ....
  }
}

In order to expose the StreamAdapter class to the client, there is a config file called dwr.xml. This file tells DWR to create a new instance of the StreamAdapter class whenever it is called and gives the location of the class as below.


<!DOCTYPE dwr PUBLIC
    "-//GetAhead Limited//DTD Direct Web Remoting 2.0//EN"
    "http://getahead.org/dwr/dwr20.dtd">

<dwr>
  <allow>
    <create creator="new" javascript="StreamAdapter">
      <param name="class" value="com.myproject.adapters.StreamAdapter"/>
 <include method= "getStreamsForStreamType"/>  <!OPTIONAL>
 <include method= "getStreamDetails"/>  <!OPTIONAL>
    </create>
  </allow>
  <allow>
    <create creator="new" javascript="AnotherAdapter">
      <param name="class" value="com.myproject.adapter.FieldAdapter"/>
    </create>
  </allow>
</dwr>

The above is the simpler version of dwr.xml file.

if you are retrieving List or Map then you can use convert element which specifies the members to include in the JavaScript serialization of StreamBean.

You can declare the dwr servlet as below in web.xml file.


<servlet>
    <servlet-name>dwr-invoker</servlet-name>
    <display-name>DWR Servlet</display-name>
    <servlet-class>org.directwebremoting.servlet.DwrServlet</servlet-class>
    <init-param>
       <param-name>debug</param-name>
       <param-value>false</param-value>
    </init-param>
  </servlet>

<servlet-mapping>
    <servlet-name>dwr-invoker</servlet-name>
    <url-pattern>/dwr/*</url-pattern>
  </servlet-mapping>

Pros and cons of DWR:

- Very easy to use.
- very quick.
- DWR does a great job of hiding the Ajax machinery, but it's important to remember that the network is not transparent .

Hope it will be useful.

References :
http://www.ibm.com/developerworks/java/library/j-ajax3/

Method C : Delegate Struts Action management to the Spring framework

2009-05-21T08:07:00.000-07:00

Here we are going to delegate Struts action management to the Spring framework.

All you have to do is...

For each action that uses Spring, you need to define the action mapping to use org.springframework.web.struts.DelegatingActionProxy and declare a matching (action "path" == bean "name") Spring bean for the actual Struts action. This is an example of an action that requires an instance of UserDatabase:

Note the changes in struts-config file.

Inside action-mappings instead of declaring the action's class name, it registers the name of Spring's proxy class. The DelegatingActionProxy class uses the action mapping name to look up the action in the Spring context. This is the context that was declared with ContextLoaderPlugIn.


<struts-config>
 <form-beans>
    <form-bean name="searchForm" type="org.apache.struts.validator.DynaValidatorForm">
               <form-property name="id"    type="java.lang.Long"/>
    </form-bean>
    
  </form-beans>

 <global-forwards type="org.apache.struts.action.ActionForward">
     <forward   name="welcome"                path="/welcome.do"/>
     <forward   name="searchEntry"            path="/searchEntry.do"/>
     <forward   name="searchSubmit"           path="/searchSubmit.do"/>
 </global-forwards>

 <action-mappings>
    <action    path="/welcome" forward="/WEB-INF/pages/welcome.htm"/>

    <action    path="/searchEntry" forward="/WEB-INF/pages/search.jsp"/>
               
    <action    path="/searchSubmit"
               type="org.springframework.web.struts.DelegatingActionProxy"
               input="/searchEntry.do"
               validate="true"
               name="searchForm">
              <forward name="success" path="/WEB-INF/pages/detail.jsp"/>
              <forward name="failure" path="/WEB-INF/pages/search.jsp"/>
    </action>  

 </action-mappings>

 <message-resources parameter="ApplicationResources"/>

 <plug-in className="org.apache.struts.validator.ValidatorPlugIn">
    <set-property property="pathnames" value="/WEB-INF/validator-rules.xml,/WEB-INF/validation.xml"/>
 </plug-in>


 <plug-in className="org.springframework.web.struts.ContextLoaderPlugIn">
    <set-property property="contextConfigLocation" value="/WEB-INF/beans.xml"/>
 </plug-in>

 
</struts-config>

The corresponding Spring bean configuration...


<beans>
  
  <bean id="employee_1" class="struts.spring.employee.beans.Employee">
   <property name="id" value="1" />
   <property name="name" value="Sneha" />
  </bean>
  
  <bean id="employee_2" class="struts.spring.employee.beans.Employee">
   <property name="id" value="2" />
   <property name="name" value="Prashant" />
  </bean>
  
  <bean id="employeeService" class="struts.spring.employee.business.EmployeeImpl">
 <property name="employees">
   <map>
    <entry key="1">
     <ref bean="employee_1" />
    </entry> 
    <entry key="2">
     <ref bean="employee_2" />
    </entry>
   </map>
 </property>
  </bean>
  
  <bean name="/searchSubmit" 
    class="struts.spring.employee.actions.FindEmployeeAction">
     <property name="employeeService">
        <ref bean="employeeService"/>
     </property>
  </bean>
   
</beans>

Merits:
1. As the action is under Spring's control, it populates the action's JavaBean properties and leaves the door open to applying features such as Spring's AOP interceptors.

The action-delegation solution is the best of the three.

Hope it will be useful...

References : http://www.ibm.com/developerworks/java/library/j-sr2.html

Method B : Override the Struts RequestProcessor with Spring's DelegatingRequestProcessor

2009-05-21T08:05:00.000-07:00

To avoid the above disadvantage of coupling the Struts Action to the Spring framework, you can override the Struts RequestProcessor processor with the org.springframework.web.struts.DelegatingRequestProcessor class.

To do the above just use tag to override the default Struts RequestProcessor with the DelegatingRequestProcessor in Struts-config file. Then register the action in Spring config file where you register other beans.


<?xml version="1.0" encoding="ISO-8859-1" ?>

<!DOCTYPE struts-config PUBLIC
          "-//Apache Software Foundation//DTD Struts Configuration 1.1//EN"
          "http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd">

<struts-config>
 <form-beans>
    <form-bean name="searchForm" type="org.apache.struts.validator.DynaValidatorForm">
               <form-property name="id"    type="java.lang.Long"/>
    </form-bean>
    
  </form-beans>

 <global-forwards type="org.apache.struts.action.ActionForward">
     <forward   name="welcome"                path="/welcome.do"/>
     <forward   name="searchEntry"            path="/searchEntry.do"/>
     <forward   name="searchSubmit"           path="/searchSubmit.do"/>
 </global-forwards>

 <action-mappings>
    <action    path="/welcome" forward="/WEB-INF/pages/welcome.htm"/>

    <action    path="/searchEntry" forward="/WEB-INF/pages/search.jsp"/>
               
    <action    path="/searchSubmit"
               type="struts.spring.employee.actions.FindEmployeeAction"
               input="/searchEntry.do"
               validate="true"
               name="searchForm">
              <forward name="success" path="/WEB-INF/pages/detail.jsp"/>
              <forward name="failure" path="/WEB-INF/pages/search.jsp"/>
    </action>  

 </action-mappings>

 <message-resources parameter="ApplicationResources"/>
 
 <controller processorClass="org.springframework.web.struts.DelegatingRequestProcessor"/>

 <plug-in className="org.apache.struts.validator.ValidatorPlugIn">
    <set-property property="pathnames" value="/WEB-INF/validator-rules.xml,/WEB-INF/validation.xml"/>
 </plug-in>


 <plug-in className="org.springframework.web.struts.ContextLoaderPlugIn">
    <set-property property="contextConfigLocation" value="/WEB-INF/beans.xml"/>
 </plug-in>

 
</struts-config>

and here is Spring config file. Register the action here and remember name attribute to match the struts-config action mapping name.
employeeService property will be populated at runtime using getter injection.


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">

<beans>
  
  <bean id="employee_1" class="struts.spring.employee.beans.Employee">
   <property name="id" value="1" />
   <property name="name" value="Sneha" />
  </bean>
  
  <bean id="employee_2" class="struts.spring.employee.beans.Employee">
   <property name="id" value="2" />
   <property name="name" value="Prashant" />
  </bean>
  
  <bean id="employeeService" class="struts.spring.employee.business.EmployeeImpl">
 <property name="employees">
   <map>
    <entry key="1">
     <ref bean="employee_1" />
    </entry> 
    <entry key="2">
     <ref bean="employee_2" />
    </entry>
   </map>
 </property>
  </bean>
  
  <bean name="/searchSubmit" 
    class="struts.spring.employee.actions.FindEmployeeAction">
     <property name="employeeService">
        <ref bean="employeeService"/>
     </property>
  </bean>
   
</beans>

Now your action class extend the Struts's org.apache.struts.action.Action Class instead of Spring ActionSupport Class.


public class FindEmployeeAction extends Action{
 
 private EmployeeI employeeService;
 
 public EmployeeI getEmployeeService() {
  return employeeService;
 }

 public void setEmployeeService(EmployeeI employeeService) { //1
  this.employeeService = employeeService;
 }

 public ActionForward execute(
   ActionMapping mapping,
   ActionForm form,
   HttpServletRequest request,
   HttpServletResponse response)
   throws IOException, ServletException {
   
   DynaActionForm searchForm = (DynaActionForm) form;
   Long id = Long.parseLong(searchForm.get("id").toString());
   
   System.out.println("Inside FindEmployeeAction_2 id = "+id);
   
         Employee employee = getEmployeeService().findEmployeeById(id);

   if (null == employee) {
    System.out.println("employee not found");
    return mapping.findForward("failure") ;
   }
   
   System.out.println("employee found");
   request.setAttribute("emp", employee);
   return mapping.findForward("success");
  }
}

As you have seen at 1 employeeService JavaBean property will be automatically populated by the DelegatingRequestProcessor.

Merits:
1. Protects the Struts action from knowing it's being managed by Spring while giving you all the benefits of Spring's action management framework.
2. Because your Struts actions are oblivious to the existence of Spring, you can swap out Spring for some other inversion of control container without refactoring your Struts code.
3. This approach is definitely better than the first one

Demerits:
1. If you were using a different RequestProcessor, then you would need to integrate the Spring DelegatingRequestProcessor manually.
2. The added code would become a maintenance hassle and would also reduce your application's flexibility going forward. Moreover, there has been some talk of replacing the Struts RequestProcessor with a chain of command. Such a change would negatively impact the longevity of this solution.

Hope it will be useful...

References : http://www.ibm.com/developerworks/java/library/j-sr2.html

Method A : Using Spring's ActionSupport Class to integrate Struts

2009-05-21T08:01:00.000-07:00

Here we are going to use Spring's ActionSupport class to integrate Struts.

Action classes of Struts framework do not get started as Spring framework beans, thus cannot be wired through Dependency Injection

If the Action class wants to access beans of Spring framework, it has to access them manually.

Instead of extending Action class, you can extend Spring's org.springframework.web.struts.ActionSupport Class which provides getWebApplicationContext() method to obtain a Spring context

Action Support provides a reference to the current Spring application context, e.g. for bean lookup or resource loading
- Auto-detects a ContextLoaderPlugIn context, falling back to the root WebApplicationContext.
- For typical usage, i.e. accessing middle tier beans, use a root WebApplicationContext.

Below is how your Struts Action Class look like :


public class FindEmployeeAction extends ActionSupport{ //1
 public ActionForward execute(
   ActionMapping mapping,
   ActionForm form,
   HttpServletRequest request,
   HttpServletResponse response)
   throws IOException, ServletException {
   
   DynaActionForm searchForm = (DynaActionForm) form;
   Long id = Long.parseLong(searchForm.get("id").toString());
   
   System.out.println("Inside FindEmployeeAction id = "+id);
   
   ApplicationContext ctx = getWebApplicationContext(); //2
   EmployeeI employeeService = (EmployeeI) ctx.getBean("employeeService"); //3
         
   Employee employee = employeeService.findEmployeeById(id);

   if (null == employee) {
    return mapping.findForward("failure") ;
   }
   
   request.setAttribute("emp", employee);
   return mapping.findForward("success");
  }
}

Let see how the above Action Class is different from Traditional Action Class and how can it provide a reference to the current Spring context.

1. Extend ActionSupport(org.springframework.web.struts.ActionSupport) Class instead Action Class.
2. ApplicationContext refernce is obtained through getWebApplicationContext() method which is there in ActionSupport Class.
3. Look up for Spring bean using the context reference you have obtained.

Have a look at Spring-config file also.


<beans>
  
  <bean id="employee_1" class="struts.spring.employee.beans.Employee">
   <property name="id" value="1" />
   <property name="name" value="Sneha" />
  </bean>
  
  <bean id="employee_2" class="struts.spring.employee.beans.Employee">
   <property name="id" value="2" />
   <property name="name" value="Prashant" />
  </bean>
  
  <bean id="employeeService" class="struts.spring.employee.business.EmployeeImpl">
 <property name="employees">
   <map>
    <entry key="1">
     <ref bean="employee_1" />
    </entry> 
    <entry key="2">
     <ref bean="employee_2" />
    </entry>
   </map>
 </property>
  </bean>
  
   
</beans>

Merits :
1. Very Simple and easy to understand.

Demerits:
1. It couples the Struts action to the Spring framework. If you ever decide to replace Spring, you would have to rewrite the code.
2. As the Struts action isn't under Spring's control, it can't reap the benefits of Spring AOP.
3. Useful when using multiple independent Spring contexts, but for the most part it's not as desirable a solution as the other two choices.

Hope it will be useful...

References : http://www.ibm.com/developerworks/java/library/j-sr2.html

Integrating Spring with Struts

2009-05-20T08:31:00.000-07:00

Key to the Spring Framework is the freedom to choose what works best for your application. Spring offers you choices when building web applications, too. Although Spring offers its own very capable web framework, you are free to choose another if you’d like and still be able to take advantage of Spring in the other layers of your application.

Advantages of integrating a Struts application into the Spring framework:

1. Spring was explicitly designed to resolve some of the real-world problems of JEE, such as complexity, poor performance, testability, and much more.
2. Second, the Spring framework includes an AOP implementation that lets you apply aspect-oriented techniques to normal object-oriented code.

Both Struts and Spring frameworks have their merits and drawbacks, but most would agree that Struts is still king when it comes to MVC. Many development teams have learned to rely on Struts as the foundation for building quality software under strict deadlines. With so much momentum behind Struts, even development teams that would like to integrate features of the Spring framework don't want to switch to Spring MVC. The good news is that you don't have to. The Spring architecture allows you to connect Struts as your Web framework to Spring-based business and persistence layers.

Below we will see three approaches to integrating Struts applications into the Spring framework and discuss their merits and demerits.

A. Using Spring's ActionSupport class to integrate Struts.
B. Override the Struts RequestProcessor with Spring's DelegatingRequestProcessor.
C. Delegate Struts Action management to the Spring framework.

Whatever technique you use, you will need to add the Spring ContextLoaderPlugin to load the Spring application context for the Struts ActionServlet. Simply add the plug-in to your struts-config.xml file as you would any other plug-in, as shown below:


<plug-in className="org.springframework.web.struts.ContextLoaderPlugIn">
    <set-property property="contextConfigLocation" value="/WEB-INF/beans.xml"/>
</plug-in>

and here is the code for my bean, interface and impl which is common to all three methodologies.


public class Employee implements Serializable{
 
 private Long id;
 private String name;
 
 public Long getId() {
  return id;
 }
 public void setId(Long id) {
  this.id = id;
 }
 public String getName() {
  return name;
 }
 public void setName(String name) {
  this.name = name;
 }
 
}

public interface EmployeeI {
 
 public Employee findEmployeeById(Long id);
 
 public int getNoOfEmployees();
}

public class EmployeeImpl implements EmployeeI{
 
 private Map<Long,Employee> employees = new HashMap<Long,Employee>();
 
 public Employee findEmployeeById(Long id){
  System.out.println("Inside findEmployeeById id = "+id);
  Employee employee = (Employee)employees.get(id.toString());
  System.out.println("Employee found = "+employee);
  return employee;
 }
 
 public int getNoOfEmployees(){
  return employees.size();
 }

 public Map<Long, Employee> getEmployees() {
  return employees;
 }

 public void setEmployees(Map<Long, Employee> employees) {
  this.employees = employees;
 }
 
}

In my Impl Class I am having HashMap which is set at runtime using Spring's getter injection.

I have divided three methodologies into three ariticles as dont want to make it messy. Complete code is provided in the respective articles.

Method A : A. Using Spring's ActionSupport class to integrate Struts.

Method B : B. Override the Struts RequestProcessor with Spring's DelegatingRequestProcessor.

Method C : C. Delegate Struts Action management to the Spring framework.

If you directly want to go the best method. Find out my continuation article,
C. Delegate Struts Action management to the Spring framework.

RMI using Spring

2009-05-14T08:18:00.000-07:00

Let us look at Spring’s support to Remoting.

Spring supports remoting for several different Remote Procedure Call models, including Remote Method Invocation (RMI), Caucho’s Hessian and Burlap, and Spring’s own HTTP invoker.

Spring offers a POJO-based programming model for both your server and client, no matter which remoting solution you choose. This is accomplished using a proxy factory bean that enables you to wire remote services into properties of your other beans as if they were local objects.

The client makes calls to the proxy as if the proxy were providing the service functionality. The proxy communicates with the remote service on behalf of the client. It handles the details of connecting and making remote calls to the remote service.

If the call to the remote service results in a java.rmi.RemoteException, the proxy handles that exception and rethrows it as an unchecked
org.springframework.remoting.RemoteAccessException. Remote exceptions usually signal problems such as network or configuration issues that can’t be gracefully recovered from. Since there’s usually very little that a client can do to gracefully recover from a remote exception, rethrowing a RemoteAccessException makes it optional for the client to handle the exception.

Spring simplifies the RMI model by providing a proxy factory bean that enables you to wire RMI services into your Spring application is if they were local JavaBeans. Spring also provides a remote exporter that makes short work of converting your Spring-managed beans into RMI services.

Spring’s RmiProxyFactoryBean is a factory bean that creates a proxy to an RMI service. RmiProxyFactoryBean produces a proxy object that talks to remote RMI services on behalf of the client. The client talks to the proxy through the service’s interface as if the remote service were just a local POJO.

RmiProxyFactoryBean certainly simplifies the use of RMI services in a Spring application. But that’s only half of an RMI conversation.

Spring provides an easier way to publish RMI services. Instead of writing RMI-specific classes with methods that throw RemoteException, you simply write a POJO that performs the functionality of your service. Spring handles the rest.

For a typical Spring Application we need the following files:

1. An interface that defines the functions.

2. An Implementation that contains properties, its setter and getter methods, functions etc.

3. A XML file called Spring configuration file.

4. Client program that uses the function

Because the service interface doesn’t extend java.rmi.Remote and none of its methods throw java.rmi.RemoteException, this trims the interface down a bit. But more importantly, a client accessing the service through this interface will not have to catch exceptions that they probably won’t be able to deal with. Instead of generating a server skeleton and client stub using rmic and manually adding it to the RMI registry (as you would in conventional RMI), we’ll use Spring’s RmiServiceExporter.

RmiServiceExporter exports any Spring-managed bean as an RMI service. RmiServiceExporter works by wrapping the bean in an adapter class. The adapter class is then bound to the RMI registry and proxies requests to the service class.

The simplest way to use RmiServiceExporter to expose the employeeService bean as an RMI service is to configure it in Spring with the following XML:


<bean class="org.springframework.remoting.rmi.RmiServiceExporter">
        <property name="serviceName" value="employee-service"/>
        <property name="service" ref="employeeService"/>
        <property name="serviceInterface" value="rmi.common.EmployeeI"/>
        <property name="registryPort" value="1234"/>
</bean>

Here the employeeService bean is wired into the service property to indicate that RmiServiceExporter is going to export the bean as an RMI service. ServiceName property names the RMI service and the serviceInterface property specifies the interface implemented by the service.


<bean id="employeeService" class="rmi.server.EmployeeImpl">
</bean>

Now let us look at an example...

Let us have simple employee recruitment service exposed through EmployeeI interface which contains methods to add, remove and get number of employees.


public class Employee implements Serializable {
 private String name;
 private String address;
 
 public Employee(String name,String address){
  this.name = name;
  this.address = address;
 }
 
 // getters and setters
}


public interface EmployeeI {
 
 public void addEmployee(Employee employee);
 
 public void removeEmployee(Employee employee);

    public List<Employee> getEmployees();  
    
}

Here is the implementation for EmployeeI interface.


public class EmployeeImpl implements EmployeeI{

    private List<Employee> employees = new ArrayList<Employee>();

    public void addEmployee(Employee employee) {
     employees.add(employee);
    }
    
    public void removeEmployee(Employee employee){
     employees.remove(employee);
    }

    public List<Employee> getEmployees() {
        return employees;
    }
}

On the server side, we need to configure Spring to export the service through RMI. As we discussed earlier we can do it by RmiServiceExporter.
The interface can be accessed by using RmiProxyFactoryBean, or via plain RMI in case of a traditional RMI service. The RmiServiceExporter explicitly supports the exposing of any non-RMI services via RMI invokers. Of course, we first have to set up our service in the Spring container:


<beans>
    <bean id="employeeService" class="rmi.server.EmployeeImpl"/>        
    
    <bean class="org.springframework.remoting.rmi.RmiServiceExporter">
        <property name="serviceName" value="employee-service"/>
        <property name="service" ref="employeeService"/>
        <property name="serviceInterface" value="rmi.common.EmployeeI"/>
        <property name="registryPort" value="1234"/>
    </bean>
</beans>

Now to run the server side service you need Spring context initialization.


public class EmpServerDemo {
 public static void main(String[] args) {
  ApplicationContext ctx = new ClassPathXmlApplicationContext("rmi/server/rmi-server-context.xml");
 }
}

Now let us have a look at client side.

To link in the service on the client, we'll create a separate Spring container, containing the simple object and the service linking configuration bits:


<beans>
    <bean id="employeeService" class="org.springframework.remoting.rmi.RmiProxyFactoryBean">
        <property name="serviceUrl" value="rmi://localhost:1234/employee-service"/>
        <property name="serviceInterface" value="rmi.common.EmployeeI"/>
    </bean>
</beans>

You can make client calls through the below code...


public class EmpClientDemo {
 public static void main(String[] args) {
  ApplicationContext ctx = new ClassPathXmlApplicationContext("rmi/client/rmi-client-context.xml");
  EmployeeI employee = (EmployeeI) ctx.getBean("employeeService");
  employee.addEmployee(new Employee("Prashant", "address1"));
  employee.addEmployee(new Employee("Sneha", "address2"));
  List<Employee> employees = employee.getEmployees();
  System.out.println("Total number of employees: " + employees.size());
  Iterator<Employee> it = employees.iterator();
  while (it.hasNext()) {
   Employee emp = (Employee) it.next();
   System.out.println(" " + emp);
  }
 }
}

Therefore, the client will not be aware of the fact that the service is running remote and even less about the fact that its method calls are marshaled through RMI. The Spring bean configuration file takes care of these details, so the client code will not be affected if we change the remoting strategy or even if we choose to run the service in-process.

First run the EmpServerDemo in one console to launch the RMI server and then run the EmpClientDemo in another console.

RMI with Spring is as simple as that.

Hope it will be useful....

References :

Spring in Action by Craig Walls.

http://cosminaru.ro/blog/2006/11/02/spring-by-examples-rmi/.

Persistence in Spring

2009-05-07T06:51:00.000-07:00

Last week I read Spring in Action by Craig Walls.

It was very good book and I found it very informative.

I would like to share few quotations from the book, which gives generic idea about Persistance in Spring.

Spring comes with a family of data access frameworks that integrate with a variety of data access technologies. Whether you are persisting your data via direct JDBC, iBATIS, or an object relational mapping (ORM) framework like Hibernate, Spring removes the tedium of data access from your persistence code. Instead, you can lean on Spring to handle the low-level data access work for you so that you can turn your attention to managing your application’s data.

Spring supports persistence mechanisms like JDBC, Hibernate, the Java Persistence API (JPA), iBATIS etc.

DAO stands for data access object, which perfectly describes a DAO’s role in an application. DAOs exist to provide a means to read and write data to the database.

They should expose this functionality through an interface by which the rest of the application will access them. This has a couple of advantages. First, it makes your service objects easily testable since they are not coupled to a specific data access implementation.

In addition, the data access tier is accessed in a persistence technology–agnostic manner. That is, the chosen persistence approach is isolated to the DAO while only the relevant data access methods are exposed through the interface. This makes for a flexible application design and allows the chosen persistence framework to be swapped out with minimal impact to the rest of the application. If the implementation details of the data access tier were to leak into other parts of the application, the entire application would become coupled with the data access
tier, leading to a rigid application design.

One way Spring helps you insulate your data access tier from the rest of your application is by providing you with a consistent exception hierarchy that is used across all of its DAO frameworks.

In JDBC , you can’t do anything with JDBC without being forced to catch java.sql.SQLException. SQLException is treated as a “one size
fits all” exception for problems related to data access. Rather than have a different exception type for each possible problem, SQLException is sthe exception that’s thrown for all data access problems.

Even so, Hibernate’s exceptions are specific to Hibernate. As stated before, we’d like to isolate the specifics of the persistence mechanism to the data access layer. If Hibernate-specific exceptions are being thrown then the fact that we’re dealing with Hibernate will leak into the rest of the application. Either that, or you’ll be forced to catch persistence platform exceptions and rethrow them as platform-agnostic exceptions.

On one hand, JDBC’s exception hierarchy is too generic—in fact, it’s not much of a hierarchy at all. On the other hand, Hibernate’s exception hierarchy is proprietary to Hibernate. What we need is a hierarchy of data access exceptions that are descriptive but not directly associated with a specific persistence framework.

Spring’s persistence platform agnostic exceptions :
Spring JDBC provides a hierarchy of data access exceptions that solve both problems. In contrast to JDBC, Spring provides several data access exceptions, each descriptive of the problem.

Even though Spring’s exception hierarchy is far more rich than JDBC’s simple SQLException, it isn’t associated with any particular persistence solution. This means that you can count on Spring to throw a consistent set of exceptions, regardless of which persistence provider you choose. This helps to keep your persistence choice confined to the data access layer.

Spring promotes the use of unchecked exceptions. This leaves the decision of whether to catch an exception in the developer’s hands. To take advantage of Spring’s data access exceptions, you must use one of Spring’s supported data access templates.

Spring applies Template method Pattern to data access.

It separates the fixed and variable parts of the data access process into two distinct classes: templates and callbacks. Templates manage the fixed part (controlling transactions, managing resources, and handling exceptions)of the process while your custom data access code (creating statements, binding parameters, and marshaling result sets) is handled in the callbacks.

Spring comes with several templates to choose from, depending on your persistence platform choice. If you’re using straight JDBC then you’ll want to use JdbcTemplate. But if you favor one of the object-relational mapping frameworks then perhaps HibernateTemplate or JpaTemplate is more suitable. Direct wiring of the templates is fine, but Spring also provides a set of convenient DAO base classes that can manage the template for you.

The data access templates are not all there is to Spring’s data access framework. Each template also provides convenience methods that simplify data access without the need to create an explicit callback implementation. Furthermore, on top of the template-callback design, Spring provides DAO support classes that are meant to be subclassed by your own DAO classes.

When writing your application DAO implementation, you can subclass a DAO support class and call a template retrieval method to have direct access to the underlying data access template. For example, if your applicationDAO subclasses JdbcDaoSupport then you only need to call getJdbcTemplate() to get a JdbcTemplate to work with.

Just as Spring provides several data access template implementations, it also provides several DAO support classes—one for each template.

Spring’s persistence support options will depend on a data source. So, let us know how to configure Spring with a data source for the DAOs to access the database.

Configuring a data source

Regardless of which form of Spring DAO support you use, you’ll likely need to configure a reference to a data source. Spring offers several options for configuring data source beans in your Spring application, including:
1. Data sources that are defined by a JDBC driver
2. Data sources that are looked up by JNDI
3. Data sources that pool connections

1. Let us look at using JNDI data sources :

Spring applications will quite often be deployed to run within a JEE application server such as WebSphere, JBoss, or even a web container like Tomcat. These servers allow you to configure data sources to be retrieved via JNDI. The benefit of configuring data sources in this way is that they can be managed completely external to the application, leaving the application to simply ask for a data source when it’s ready to access the database. Moreover, data sources managed in an application server are often pooled for greater performance and can be hotswapped
by system administrators.

With Spring, we can configure a reference to a data source that is kept in JNDI and wire it into the classes that need it as if it were just another Spring bean. Spring’s JndiObjectFactoryBean makes it possible to retrieve any object, including data sources, from JNDI and make it available as a Spring bean.

How does JndiObjectFactoryBean retrieve a data source from JNDI:


<bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean" scope="singleton">
 <property name="jndiName" value="/jdbc/SampleDatasource" />
 <property name="resourceRef" value="true" />
</bean>

The jndiName attribute is used to specify the name of the resource in JNDI. If only the jndiName property is set then the data source will be looked up as is. But if the application is running within a Java application server then you’ll want to set the resourceRef property to true.

When resourceRef is true, the value of jndiName will be prepended with java:comp/env/ to retrieve the data source as a Java resource from the application server’s JNDI directory. Consequently, the actual name used will be java:comp/env/jdbc/SampleDatasource.

2 Using a pooled data source :

Configuring a BasicDataSource bean is like


<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource">
        <property name="driverClassName" value="com.mysql.jdbc.Driver"/>
        <property name="url" value="jdbc:mysql://localhost/test"/>
        <property name="username" value="root"/>
        <property name="password" value=""/>
 <property name="initialSize" value="5" />
 <property name="maxActive" value="10" />
</bean>

The first four properties are elemental to configuring a BasicDataSource. The driverClassName property specifies the fully qualified name of the JDBC driver class. Here we’ve configured it with the JDBC driver for the Hypersonic database. The url property is where we set the complete JDBC URL for the database. Finally, the username and password properties are used to authenticate when you’re connecting to the database. Those four basic properties define connection information for BasicData- Source. In addition, several properties can be used to configure the data source pool itself.

3. JDBC driver-based data source

The simplest data source you can configure in Spring is one that is defined through a JDBC driver. Spring offers two such data source classes to choose from (both in the org.springframework.jdbc.datasource package):

-> DriverManagerDataSource—Returns a new connection every time that a connection is requested. Unlike DBCP’s BasicDataSource, the connections
provided by DriverManagerDataSource are not pooled.

-> SingleConnectionDataSource—Returns the same connection every time that a connection is requested. Although SingleConnectionDataSource
isn’t exactly a pooled data source, you can think of it as a data source with a pool of exactly one connection.

Configuring either of these data sources is similar to how we configured DBCP’s BasicDataSource as shown above. The only difference is that since neither DriverManagerDataSource nor Single-ConnectionDataSource provides a connection pool, there are no pool configuration
properties to set.

Although SingleConnectionDataSource and DriverManagerDataSource are great for small applications and running in development, you should seriously consider the implications of using either in a production application. Because SingleConnectionDataSource has one and only one database connection to work with, it doesn’t work well in a multithreaded application. At the same time, even though DriverManagerDataSource is capable of supporting multiple threads, it incurs a performance cost for creating a new connection each time a connection is requested. Because of these limitations, using pooled data sources strongly recommend.

Hope it will be useful...

Integrating Hibernate with Spring

2009-05-06T08:52:00.000-07:00

I tried to learn how to integrate Hibernate with Spring and found very useful information in Spring in Action by Craig Walls.

It was very good book and I found it very informative.

I would like to share few quotations from the book specific to this topic (Integrating Hibernate with Spring).

Before getting started let me tell you about the example I have used in this article.

I am having a very basic table in database


CREATE TABLE  sample (
  id int(10) unsigned NOT NULL AUTO_INCREMENT,
  name varchar(45) NOT NULL,
  city varchar(45) NOT NULL,
  PRIMARY KEY (id)
) ;

and here is Sample.hbm.xml


<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
        "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
        "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">

<hibernate-mapping >
    <class name="hibernate.Sample" table="sample" lazy="false">
    
        <id name="id" column="id" type="java.lang.Long">
            <generator class="increment"/>
        </id>
        <property name="name" type="string"/>
        <property name="city" type="string"/>
        
    </class>
</hibernate-mapping>

and here is Sample bean.


public class Sample implements Serializable{
 
 private Long id;
 private String name;
 private String city;
 
 // getters and setters
}

Now let us get into detail...

The standard way to get a reference to a Hibernate Session object is through an implementation of Hibernate’s SessionFactory interface. Among other things, SessionFactory is responsible for opening, closing, and managing Hibernate Sessions.

The first thing you’ll need to do is to configure a Hibernate session factory bean in Spring.

Spring’s HibernateTemplate provides an abstract layer over a Hibernate Session. HibernateTemplate’s main responsibility is to simplify the work of opening and closing Hibernate Sessions and to convert Hibernate-specific exceptions to one of the Spring ORM exceptions (In the case of Hibernate 2, this means converting a checked HibernateException to an unchecked Spring exception.)

The following XML shows how to configure a HibernateTemplate in Spring:


<bean id="hibernateTemplate" class="org.springframework.orm.hibernate3.HibernateTemplate">
 <property name="sessionFactory" ref="sessionFactory" />
</bean>

The sessionFactory property takes a reference to an implementation of org.hibernate.SessionFactory. Here you have a few options, depending on
how you use Hibernate to map your objects to database tables.

-> If you are using Hibernate’s classic XML mapping files, you’ll want to use Spring’s LocalSessionFactoryBean.

LocalSessionFactoryBean is a Spring factory bean that produces a local Hibernate SessionFactory instance that draws its mapping metadata from one or more XML mapping files.

how to configure a LocalSessionFactory-Bean that loads the mapping files for the RoadRantz domain objects:


<bean id="sessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
 <property name="dataSource" ref="dataSource" />
 <property name="mappingResources">
  <list>
   <value>hibernate/Sample.hbm.xml</value> 
  </list>
 </property>
 <property name="hibernateProperties">
  <props>
   <prop key="hibernate.dialect">org.hibernate.dialect.MySQLDialect</prop>
   <prop key="show_sql">true</prop>
  </props>
 </property>
</bean>

-> For annotation-based Hibernate, Spring’s AnnotationSessionFactoryBean works much like LocalSessionFactoryBean, except that it creates a SessionFactory based on annotations in one or more domain classes.

The XML required to configure an AnnotationSessionFactoryBean in Spring is similar to the XML for LocalSessionFactoryBean:


<bean id="sessionFactory" class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
 <property name="dataSource" ref="dataSource" />
 <property name="annotatedClasses">
  <list>
   <value>hibernate.Sample</value>
  </list>
 </property>
 <property name="hibernateProperties">
  <props>
   <prop key="hibernate.dialect">org.hibernate.dialect.MySQLDialect</prop>
   <prop key="show_sql">true</prop>
  </props>
 </property>
</bean>

The dataSource and hibernateProperties properties serve the same purpose with AnnotationSessionFactoryBean as with LocalSessionFactoryBean. However, instead of configuring one or more mapping files, we must configure AnnotationSessionFactoryBean with one or more classes that are annotated for persistence with Hibernate.

With the HibernateTemplate bean declared and wired with a session factory, we’re ready to start using it to persist and retrieve objects from the database.

Injected HibernateTemplate into HibernateSampleDao.


public class HibernateSampleDAO {
 
 private HibernateTemplate hibernateTemplate;

 public void setHibernateTemplate(HibernateTemplate hibernateTemplate) {
  this.hibernateTemplate = hibernateTemplate;
 } 

}

HibernateSampleDAO accepts a HibernateTemplate reference via setter injection. So configure it.


<bean id="hibSampleDAO" class="hibernate.HibernateSampleDAO">
 <property name="hibernateTemplate" ref="hibernateTemplate" />
</bean>

saveSample() method that is used to persist a Sample object to the database:


public void saveSample(Sample sample) {
 hibernateTemplate.saveOrUpdate(sample);
}

The saveOrUpdate() method inspects the object to see if its ID field is null. If it is, it must be a new object and thus it is inserted into the database. If it’s not null, it is assumed that it is an existing object and its data is updated.

Now let us look at findSampleByCity() method that uses HibernateTemplate’s find() method to retrieve a Sample by querying by the cityName.


public Sample findSampleByCity(String city) {
 List<Sample> results = hibernateTemplate.find("from Sample sample"+
   " where city = ?",new Object[] {city});
  return results.size() > 0 ? (Sample) results.get(0) : null;
}

And here’s how you might use HibernateTemplate’s load() method to load a specific instance of a Sample by the sample’s ID field:


public Sample getSampleById(Long id) {
 return (Sample)hibernateTemplate.load(Sample.class, id);
}

So far, the configuration of HibernateSampleDAO involves four beans. The datasource is wired into the session factory bean (either LocalSessionFactoryBean or AnnotationSessionFactoryBean). The session factory bean is wired into the HibernateTemplate. Finally, the HibernateTemplate is wired into HibernateSampleDAO, where it is used to access the database.

To simplify things slightly, Spring offers HibernateDaoSupport, a convenience DAO support class, that enables you to wire a session factory bean directly into the DAO class. Under the covers, HibernateDaoSupport creates a HibernateTemplate that the DAO can use.

Let’s rework HibernateSampleDAO to use HibernateDaoSupport. The first step is to change HibernateSampleDAO to extend HibernateDaoSupport:


public class HibernateSampleDAO extends HibernateDaoSupport {
…
}

HibernateSampleDAO no longer needs a HibernateTemplate property as it did in previous example. Instead, you can use the getHibernateTemplate() method to get a HibernateTemplate that HibernateDaoSupport creates for you. So, the next step is to change all the data access methods in HibernateSampleDAO to use getHibernateTemplate().

For example, here’s the saveSample() method updated for the new HibernateDaoSupport-based HibernateSampleDAO:


public void saveSample(Sample sample) {
 getHibernateTemplate().saveOrUpdate(sample);
}

HibernateSampleDAO no longer needs a HibernateTemplate reference, so you can remove it. Instead of a Hibernate-Template, you can directly give reference of a Hibernate SessionFactory so that it can produce a HibernateTemplate internally.


<bean id="hibSampleDAO" class="hibernate.HibernateSampleDAO">
 <property name="sessionFactory" ref="sessionFactory"/>
</bean>

If you think of extending Spring specific class as an intrusion of Spring into your application code, then you can take advantage of Hibernate 3’s support for contextual sessions to remove Spring-specific dependencies from your DAOs.

Using Hibernate 3 contextual sessions:

Contextual sessions, introduced in Hibernate3, are a way in which Hibernate itself manages one Session per transaction.

There’s no need for HibernateTemplate to ensure this behavior. So, instead of wiring a HibernateTemplate into your DAO, you can wire a Hibernate Session-Factory.


public class HibernateSampleDAO{
 …
 private SessionFactory sessionFactory;
 public void setSessionFactory(SessionFactory sessionFactory) {
  this.sessionFactory = sessionFactory;
 }
}

In this new HibernateSampleDAO, a SessionFactory reference is injected into the sessionFactory property. Since SessionFactory comes from the Hibernate API, HibernateSampleDAO no longer depends on the Spring Framework. Instead of using HibernateTemplate to perform persistence operations, you now ask the Session-Factory for the current session.


public void saveSample(Sample sample) {
 sessionFactory.getCurrentSession().saveOrUpdate(sample);
}

Configuring this HibernateRantDao is similar to that of HibernateDaoSupport-based version.

Both HibernateDaoSupport and our new pure-Hibernate version of HibernateSampleDao require a Hibernate SessionFactory to be wired into their sessionFactory property. In either case, the sessionFactory bean (which is a SessionFactory-producing LocalSessionFactoryBean or AnnotationSession-FactoryBean) is suitable


<bean id="hibSampleDAO" class="hibernate.HibernateSampleDAO">
 <property name="sessionFactory" ref="sessionFactory" />
</bean>

Note :
-> If you’re using Hibernate 2 then you have no other option than to use HibernateTemplate.

-> The main benefit of Hibernate contextual sessions is that they decouple your DAO implementations from Spring.

-> The primary drawback of contextual sessions is that they throw Hibernatespecific exceptions. Although HibernateException is a runtime exception, the exception hierarchy is specific to Hibernate and not as ORM-agnostic as Spring’s persistence exception hierarchy. This may hinder migration to a different ORM solution.

Hope it will be useful...

More about ApplicationContext in Spring

2009-04-16T13:07:00.000-07:00

While the beans package provides basic functionality for managing and manipulating beans, often in a programmatic way, the context package adds ApplicationContext, which enhances BeanFactory functionality in a more framework-oriented style.

A bean factory is fine for simple applications, but to take advantage of the full power of the Spring Framework, you’ll probably want to load your application beans using Spring’s more advanced container, the application context.

Many users will use ApplicationContext in a completely declarative fashion, not even having to create it manually, but instead relying on support classes such as ContextLoader to automatically start an ApplicationContext as part of the normal startup process of a J2EE web-app. Of course, it is still possible to programmatically create an ApplicationContext.

The basis for the context package is the ApplicationContext interface, located in the org.springframework.context package. Deriving from the BeanFactory interface, it provides all the functionality of BeanFactory. To allow working in a more framework-oriented fashion, using layering and hierarchical contexts, the context package also provides the following:

In most cases, you’ll use the ApplicationContext, which adds more enterprise-level, J2EE functionality, such as
-> internationalization (i18n)
-> custom converters (for converting Strings to Object types)
-> event publication/notification
-> Access to resources, such as URLs and files
-> Loading of multiple (hierarchical) contexts, allowing each to be focused on one particular layer, for example the web layer of an application.

You could also implement your own ApplicationContext and add support for loading from other resources (such as a database). While many Contexts are available for loading beans, you’ll only need a few, which are listed below. The others are internal classes that are used by the framework itself.

1. ClassPathXmlApplicationContext: Loads context files from the classpath (that is, WEB-INF/classes or WEB-INF/lib for JARs) in a web application. Initializes using a


new ClassPathXmlApplicationContext(path)

where path is the path to the file. The path argument can also be a String array of paths. This is a good context for using in unit tests.

2. FileSystemXmlApplicationContext: Loads context files from the file system, which is nice for testing. Initializes using a


new FileSystemXmlApplicationContext (path)

where path is a relative or absolute path to the file. The path argument can also be a String array of paths.

3. XmlWebApplicationContext: Loads context files internally by the ContextLoaderListener, but can be used outside of it. For instance, if you are running a container that doesn’t load Listeners in the order specified in web.xml, you may have to use this in another Listener. Below is the code to use this Loader.


XmlWebApplicationContext context = new XmlWebApplicationContext();
context.setServletContext(ctx);
context.refresh();

Once you’ve obtained a reference to a context, you can get references to beans using


ctx.getBean(“beanId”)

You will need to cast it to a specific type, but that’s the easy part. Of the above contexts, ClassPathXmlApplicationContext is the most flexible. It doesn’t care where the files are, as long as they’re in the classpath. This allows you to move files around and simply change the classpath.

Aside from the additional functionality offered by application contexts, another big difference between an application context and a bean factory is how singleton beans are loaded. A bean factory lazily loads all beans, deferring bean creation until the getBean() method is called. An application context is a bit smarter and preloads all singleton beans upon context startup. By preloading singleton beans, you ensure that they will be ready to use when needed—your application won’t have to wait for them to be created.

Hope it will be useful...

More about BeanFactory in Spring

2009-04-16T04:01:00.000-07:00

As its name implies, a bean factory is an implementation of the Factory design pattern. That is, it is a class whose responsibility is to create and dispense beans. The BeanFactory is the actual container which instantiates, configures, and manages a number of beans. These beans typically collaborate with one another, and thus have dependencies between themselves. When a bean factory hands out objects, those objects are fully configured, are aware of their collaborating objects, and are ready to use.

BeanFactory is a workhorse that initializes beans and calls their lifecycle methods. It should be noted that most lifecycle methods only apply to singleton beans. Spring cannot manage prototype (non-singleton) lifecycles. This is because, after they’re created, prototypes are handed off to the client and the container loses track of it. For prototypes, Spring is really just a replacement for the “new” operator.

A BeanFactory is represented by the interface org.springframework.beans.factory.BeanFactory, and it is having multiple implementations. The most commonly used simple BeanFactory implementation is org.springframework.beans.factory.xml.XmlBeanFactory. (This should be qualified with the reminder that ApplicationContexts are a subclass of BeanFactory, and most users end up using XML variants of ApplicationContext).

Although for most scenarios, almost all user code managed by the BeanFactory does not have to be aware of the BeanFactory, the BeanFactory does have to be instantiated somehow. This can happen via explicit user code such as:


Resource res = new FileSystemResource("beans.xml");
XmlBeanFactory factory = new XmlBeanFactory(res);


ClassPathResource res = new ClassPathResource("beans.xml");
XmlBeanFactory factory = new XmlBeanFactory(res);


ClassPathXmlApplicationContext appContext = new ClassPathXmlApplicationContext(
        new String[] {"applicationContext.xml", "applicationContext-part2.xml"});
// of course, an ApplicationContext is just a BeanFactory
BeanFactory factory = (BeanFactory) appContext;

Beans are lazily loaded into bean factories, meaning that while the bean factory will immediately load the bean definitions (the description of beans and their properties), the beans themselves will not be instantiated until they are needed.

BeanDefinition includes

1. class name which is normally the actual implementation class of the bean being described in the bean definition. However, if the bean is to be constructed by calling a static factory method instead of using a normal constructor, this will actually be the class name of the factory class.

2. bean behavioral configuration elements, which state how the bean should behave in the container (i.e. prototype or singleton, autowiring mode, dependency checking mode, initialization and destruction methods)

3. constructor arguments and property values to set in the newly created bean. An example would be the number of connections to use in a bean that manages a connection pool (either specified as a property or as a constructor argument), or the pool size limit.

4. other beans a bean needs to do its work, i.e. collaborators (also specified as properties or as constructor arguments). These can also be called dependencies.

In the much more common case where the BeanFactory itself directly creates the bean by calling its constructor (equivalent to Java code calling new), the class attribute specifies the class of the bean to be constructed. In the less common case where the BeanFactory calls a static factory method on a class to create the bean, the class attribute specifies the actual class containing the static factory method. (the type of the returned bean from the static factory method may be the same class or another class entirely, it doesn't matter).

1. Bean creation via constructor

When creating a bean using the constructor approach, all normal classes are usable by Spring and compatible with Spring. That is, the class being created does not need to implement any specific interfaces or be coded in a specific fashion. Just specifying the bean class should be enough. However, depending on what type of IoC you are going to use for that specific bean, you may need a default (empty) constructor.

Note : Additionally, the BeanFactory isn't limited to just managing true JavaBeans, it is also able to manage virtually any class you want it to manage. Most people using Spring prefer to have actual JavaBeans (having just a default (no-argument) constructor and appropriate setters and getters modeled after the properties) in the BeanFactory, but it it's also possible to have more exotic non-bean-style classes in your BeanFactory. If, for example, you need to use a legacy connection pool that absolutely does not adhere to the JavaBean specification, no worries, Spring can manage it as well.

Using the XmlBeanFactory you can specify your bean class as follows:


<bean id="myBean"
      class="spring.MyBean"/>

2. Bean creation via static factory method

When defining a bean which is to be created using a static factory method, along with the class attribute which specifies the class containing the static factory method, another attribute named factory-method is needed to specify the name of the factory method itself. Spring expects to be able to call this method and get back a live object, which from that point on is treated as if it had been created normally via a constructor. One use for such a bean definition is to call static factories in legacy code.

Following is an example of a bean definition which specifies that the bean is to be created by calling a factory-method. Note that the definition does not specify the type (class) of the returned object, only the class containing the factory method. In this example, createInstance must be a static method.


<bean id="myBean"
      class="spring.MyBean"
      factory-method="createInstance"/>

3. Bean creation via instance factory method

In a fashion similar to instantiation via a static factory method, instantiation using an instance factory method is where a non-static method of an existing bean from the container is invoked to create a new bean. To use this mechanism, the 'class' attribute must be left empty, and the 'factory-bean' attribute must specify the name of a bean in the current (or parent/ancestor) container that contains the instance method that is to be invoked to create the object. The name of the factory method itself must be set using the 'factory-method' attribute.


<!-- the factory bean, which contains a method called createInstance() -->
<bean id="serviceLocator" class="com.foo.DefaultServiceLocator">
<!-- inject any dependencies required by this locator bean -->
</bean>
<!-- the bean to be created via the factory bean -->
<bean id="exampleBean"
factory-bean="serviceLocator"
factory-method="createService"/>

To singleton or not to singleton

Beans are defined to be deployed in one of two modes: singleton or non-singleton (prototype). When a bean is a singleton, only one shared instance of the bean will be managed and all requests for beans with an id or ids matching that bean definition will result in that one specific bean instance being returned.

The non-singleton, prototype mode of a bean deployment results in the creation of a new bean instance every time a request for that specific bean is done. This is ideal for situations where for example each user needs an independent user object or something similar.

Beans are deployed in singleton mode by default, unless you specify otherwise. Keep in mind that by changing the type to non-singleton (prototype), each request for a bean will result in a newly created bean and this might not be what you actually want. So only change the mode to prototype when absolutely necessary.

In the example below, two beans are declared of which one is defined as a singleton, and the other one is a non-singleton (prototype). myBean is created each and every time a client asks the BeanFactory for this bean, while myBeanAgain is only created once; a reference to the exact same instance is returned on each request for this bean.


<bean id="myBean"
      class="spring.MyBean" singleton="false"/>
<bean name="myBeanAgain"
      class="spring.MyBeanAgain" singleton="true"/>

A BeanFactory is essentially nothing more than the interface for an advanced factory capable of maintaining a registry of different beans and their dependencies. The BeanFactory enables you to read bean definitions and access them using the bean factory. When using just the BeanFactory you would create one and read in some bean definitions in the XML format as follows:


InputStream is = new FileInputStream("beans.xml");
XmlBeanFactory factory = new XmlBeanFactory(is);

The BeanFactory interface has only five methods for clients to call:

boolean containsBean(String): returns true if the BeanFactory contains a bean definition or bean instance that matches the given name

Object getBean(String): returns an instance of the bean registered under the given name. Depending on how the bean was configured by the BeanFactory configuration, either a singleton and thus shared instance or a newly created bean will be returned. A BeansException will be thrown when either the bean could not be found (in which case it'll be a NoSuchBeanDefinitionException), or an exception occurred while instantiating and preparing the bean

Object getBean(String,Class): returns a bean, registered under the given name. The bean returned will be cast to the given Class. If the bean could not be cast, corresponding exceptions will be thrown (BeanNotOfRequiredTypeException). Furthermore, all rules of the getBean(String) method apply (see above)

boolean isSingleton(String): determines whether or not the bean definition or bean instance registered under the given name is a singleton or a prototype. If no bean corresponding to the given name could not be found, an exception will be thrown (NoSuchBeanDefinitionException)

String[] getAliases(String): Return the aliases for the given bean name, if any were defined in the bean definition

Hope it will be useful.....

BeanFactory and ApplicationContext in Spring

2009-04-14T13:25:00.001-07:00

Basis for Spring's Dependency Injection feature is provided by two most fundamental and important packages in Spring namely org.springframework.beans and org.springframework.context packages.

The BeanFactory from org.springframework.beans provides an advanced configuration mechanism capable of managing beans (objects) of any nature, using potentially any kind of storage facility.

The ApplicationContext from org.springframework.context package builds on top of the BeanFactory (it's a subclass) and adds other functionality such as easier integration with Springs AOP features, message resource handling (for use in internationalization), event propagation, declarative mechanisms to create the ApplicationContext and optional parent contexts, and application-layer specific contexts such as the WebApplicationContext, among other enhancements.

BeanFactory is an internal interface that provides the configuration framework and basic functionality, while the ApplicationContext adds enhanced capabilities to it, some of them perhaps more J2EE and enterprise-centric.

ApplicationContext is a complete superset of a BeanFactory, and any description of BeanFactory capabilities and behavior should be considered to apply to ApplicationContexts as well.

How to determine which one is best suited in a particular situation. BeanFactory or ApplicationContext???

Normally when building most applications in a J2EE-environment, the best option is to use the application context for every application unless the resources of this application are restricted, such as when running in an applet or a mobile device, and you don't need all the features of the ApplicationContext.

Hope it will be useful...

Dependency Injection in Spring

2009-04-12T12:55:00.000-07:00

What is Dependency Injection:

Originally, dependency injection was commonly referred to by another name inversion of control(IoC). But in an article written in early 2004,
Martin Fowler asked what aspect of control is being inverted. He concluded that it is the acquisition of dependencies that is being inverted.

In the Java community there's been a rush of lightweight containers that help to assemble components from different projects into a cohesive application.(Ex: Spring) Underlying these containers is a common pattern to how they perform the wiring, a concept they refer under the very generic name of "Inversion of Control"

For this new breed of containers the inversion is about how they lookup a plugin implementation. The approach that these containers use is to ensure that any user of a plugin follows some convention that allows a separate assembler module to inject the implementation into the lister.

Based on that revelation, he coined the phrase “dependency injection,” a term that better describes what is going on. Inversion of Control is a generic term and the more specific name for this pattern is Dependency Injection.

Dependency injection is basically giving an object what it needs instead of letting this object get it by itself. It is based on a best practice technique (design pattern). This technique allows a part of application to be changed without causing problems in other areas of the application. A design is inflexible unless it cannot be easily adapted.

Why use Dependency Injection:

Instead of using Depenedency Injection if we hardcode "new" in our code.
What if something changes?
How do we externalize configuration from Java code, important if things change?

By avoiding use of a custom factory we are reducing extra code to be written in the application

By applying Dependency Injection in your projects, you’ll find that your code will become significantly simpler, easier to understand, and easier to test.

Any nontrivial application is made up of two or more classes that collaborate with each other to perform some business logic. Traditionally,
each object is responsible for obtaining its own references to the objects it collaborates with (its dependencies). This can lead to highly coupled and hard-to-test code. When applying Dependency injection(DI), objects are given their dependencies at creation time by some external entity that coordinates each object in the system. In other words, dependencies are injected into objects. So, DI means an inversion of responsibility with regard to how an object obtains references to collaborating objects.

Software components (Clients), are often a part of a set of collaborating components which depend upon other components (Services) to successfully complete their intended purpose. In many scenarios, they need to know “which” components to communicate with, “where” to locate them, and “how” to communicate with them. When the way such services can be accessed is changed, such changes can potentially require the source of lot of clients to be changed.

One way of structuring the code is to let the clients embed the logic of locating and/or instantiating the services as a part of their usual logic. Another way to structure the code is to have the clients declare their dependency on services, and have some "external" piece of code assume the responsibility of locating and/or instantiating the services and simply supplying the relevant service references to the clients when needed. In the latter method, client code typically is not required to be changed when the way to locate an external dependency changes. This type of implementation is considered to be an implementation of Dependency Injection and the "external" piece of code referred to earlier is likely to be either hand coded or implemented using one of a variety of DI frameworks.

Dependency Injection uses the Hollywood Principle: “Don’t call me, I’ll call you.” In other words, your classes don’t look up or instantiate the classes they depend on. The control is inverted and some form of container sets the dependencies. Using IoC often leads to much cleaner code and provides an excellent way to de-couple dependent classes.

IOC in Spring:

IoC is a big part of what Spring does. It also offers a number of other capabilities apart from Dependency Injection(DI).

The core of Spring’s implementation is based on DI, although dependency lookup features are provided as well. When Spring automatically provides collaborators to a dependent object, it does so using DI. In a Spring-based application, it is always preferable to use dependency injection to pass collaborators to dependent objects rather than have the dependent objects obtain the collaborators via lookup. Although DI is the preferred mechanism for wiring together collaborators and dependent objects, you need dependency
lookup to access the dependent objects. In many environments, Spring cannot automatically wire up all of your application components using DI, and you must use dependency lookup to access the initial set of components. When you are building web applications using Spring’s MVC
support, Spring can avoid this by gluing your entire application together automatically. Wherever possible, you should use DI with Spring; otherwise, you can fall back on the dependency lookup capabilities.

Dependency Injection(DI) is provided by Core package in Spring Framework allowing you to manage bean container functionality. The basic principle is that beans define their dependencies (i.e. the other objects they work with) only through constructor arguments, arguments to a factory method, or properties which are set on the object instance after it has been constructed or returned from a factory method. Then, it is the job of the container to actually inject those dependencies when it creates the bean. This is fundamentally the inverse (hence the name Inversion of Control) of the bean instantiating or locating its dependencies on its own using direct construction of classes, or something like the Service Locator pattern.

An interesting feature of Spring’s IoC container is that it has the ability to act as an adaptor between its own dependency injection container and external dependency lookup containers.

Spring supports both constructor and setter injection and bolsters the standard IoC feature set with a whole host of useful additions to make your life easier.

Dependency Injection majorly in two forms:

1. Setter-based: Classes are typically JavaBeans, with a no-arg constructor, and with setters for the IoC container to use when wiring dependencies. This is the variant recommended by Spring. While Spring supports constructor-based injection, a large number of constructor arguments can be difficult to manage.


public interface Hello {

 public String sayHello(String str);
 
 public String showEmpDetails();
}

public class HelloImpl implements Hello{
 
 private String greeting; 
 private EmployeeTO empTO;
 
 public String sayHello(String str){
  return greeting+" "+str;
 }
 
 public String showEmpDetails(){
  return "Employee "+empTO.getName()+ " with empId = "+empTO.getId();
 }

 public String getGreeting() {
  return greeting;
 }

 public void setGreeting(String greeting) {
  System.out.println("Inside setGreeting");
  this.greeting = greeting;
 }
 
 public void setEmpTO(EmployeeTO empTO) {
  System.out.println("Inside setEmpTO");
  this.empTO = empTO;
 } 
 
}

<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">

  <beans>

   <bean id="hello" class="bean_injection.HelloImpl">
   
    <property name="greeting"> 
        <value>Good Night!...</value> 
    </property>
    
    <property name="empTO"> 
        <ref local="employeeTO"/> 
    </property>

   </bean>
   
   <bean id="employeeTO" class="bean_injection.EmployeeTO">
   
           <property name="id"> 
        <value>1</value> 
    </property>
    
    <property name="name"> 
        <value>Prashant</value> 
    </property>

   </bean>
   

</beans>

2. Constructor-based: Classes contain constructors with a number of arguments. The IoC container discovers and invokes the constructor based on the number of arguments and their object types. This approach guarantees that a bean is not created in an invalid state.


public interface Hello {

 public String sayHello(String str);
}

public class HelloImpl implements Hello{
 
 private String greeting; 
 
 public HelloImpl(){}
 
 public HelloImpl(String str){
  System.out.println("Inside constructor ");
  this.greeting = str;
 }
 
 public String sayHello(String str){
  return greeting+" "+str;
 }
 
}

<beans>

   <bean id="hello" class="bean_injection.HelloImpl">
   
     <constructor-arg> 
   <value>Good Morning!...</value> 
  </constructor-arg>
   </bean>

</beans>

Which one to use (Setter-based / Constructor-based)?

Constructor injection is particularly useful when you absolutely must have an instance of the dependency class before your component is used. Many containers, Spring included, provide a mechanism for ensuring that all dependencies are defined when you use setter injection, but by using constructor injection, you assert the requirement for the dependency in a container-agnostic manner.

Setter injection is useful in a variety of different cases. If you want the component to expose its dependencies to the container but provide its own defaults, setter injection is usually the best way to accomplish this. Another benefit of setter injection is that it allows dependencies to be declared on an interface, although this is not as useful as you might first think. Consider a typical business
interface with one business method, defineMeaningOfLife(). If, in addition to this method, you define a setter for injection such as setEncylopedia(), you are mandating that all implementations must use or at least be aware of the encyclopedia dependency. You do not need to define this setter at all—any decent IoC container, Spring included, can work with the component in terms of the
business interface but still provide the dependencies of the implementing class.

Benefits of Dependency Injection :

1. Unit testable
2. Dependencies are explicit
3. Consistent
4. Can wire up arbitrarily complicated graphs
5. You don’t need to write plumbing code
6. Pluggability
7. Reduces cost of programming to interfaces to zero

As described by Rod Johnson "Spring provides a factory to end all factories".

Hope it will be useful.

Advanced JavaScript by Chuck Easttom

2009-02-06T09:44:00.000-08:00

Few days before I started reading Advanced JavaScript Third Edition by Chuck Easttom.

It was very good book and I found the arrays chapter to be very interesting...

I would like to share few quotations from the book.

JavaScript is an easy-to-use object-oriented scripting language designed for creating dynamic online applications that link together objects and resources on both clients and servers. While Java is used by programmers to create new objects and applets, JavaScript is designed for use by HTML page authors and enterprise application developers to dynamically script the behavior of objects running on either the client or the server.

JavaScript’s design and concepts represent the next generation of software for the Internet. JavaScript is:

1. Designed for creating network-centric applications
2. Complementary to and integrated with Java
3. Complementary to and integrated with HTML
4. Open and cross-platform

This means that JavaScript works hand in hand with HTML, and will work on any platform (Windows, Linux, Mac, etc.). It is also important to note that you don’t need any special tools to use JavaScript. You can simply write scripts in any text editor, as we will do throughout most of this book.

With JavaScript, an HTML page might contain a form that processes data on the client side. A server-side JavaScript might pull data out of a relational database and format it in HTML on the fly. A page might contain JavaScript scripts that run on both the client and the server.

JavaScript supports most of Java’s expression syntax and basic control flow constructs. The only difference is the variable declaration.

JavaScript and Java are both based on objects, but their implementations differ. In both languages, many built-in functions are implemented as properties and methods of various objects.

JavaScript resembles Perl in that it is interpreted, not compiled. Java is referred to as a compiled language. Unlike most other programming languages, though, Java is not compiled to a native machine code, but rather to a Java byte code.

Both Java and JavaScript are based on objects. However, their implementations of objects are different. JavaScript is an object-based language. It supports built-in, extensible objects, but no classes or inheritance. Its object hierarchy is not an inheritance hierarchy as in Java. JavaScript features two types of objects:

Static objects — objects that combine general functions (methods) and data constructs (properties). The values of such objects’ properties are usually read-only. A static object is a single object, and thus does not enable you to create instances of it. For example, the Math object in JavaScript is a static one, because you cannot create instances according to its template.

Dynamic objects — objects by which instances are created. A dynamic object resembles a template. You do not touch or use the object directly. In order to take advantage of such an object, you must create an instance of it.

JavaScript’s object model is somewhat simpler than Java’s equivalent, so JavaScript’s object implementation is much easier to accommodate than Java’s model.

Another difference between Java and JavaScript is their time of binding. JavaScript features dynamic binding, so all object references are checked at run time. Java, on the other hand, is based on static binding, meaning that all object references must exist and be valid at compile time.

Another difference between Java and JavaScript is that Java is strongly typed, as opposed to JavaScript, which is loosely typed. That is, when you declare a variable in Java, you must specify its data type. For example, when you create a variable to contain integer values you must use the int keyword. In JavaScript, all variables are declared in the same way.

A very important difference between Java and JavaScript is that JavaScript is integrated with, and embedded in, HTML.

Internal Scripts:
The


<SCRIPT>

tag is used to enclose JavaScript code in HTML documents.
This is probably the most common method for inserting JavaScript into HTML documents.

External Scripts:
Using


<SCRIPT>

tag, which enables the use of external scripts; that is, you can use a JavaScript script that is located in another file.
Some people prefer to have their scripts in external files for a few reasons. First, your script is not as immediately and easily viewable as your HTML.
Also, some web developers have common scripts they use on multiple pages.
External scripts are useful when you need to integrate a long, sophisticated JavaScript script into an HTML file.

But we have some disadvantages too..
No back references: JavaScript scripts are mainly driven by user-initiated events. A click on a button calls a function, a selection of a form element executes another function, and so on. If you design your entire script in an external file, you will have difficulties in referring to the HTML definitions in the original file. For this reason, place only general functions in an external script.

Additional processing: The JavaScript interpreter evaluates all functions found in your script header, including those defined in the external file, and stores them in memory. Loading unneeded functions in an external file degrades the script performance.

Additional server access: You know how irritating it is to wait until another page loads in the window, especially with slow connections. That is the problem with the SRC attribute. When the browser comes across the tag that tells it to interpret JavaScript code in another file, it must first load that file. Such an action is time consuming. Most programmers say that efficiency is not as important as maintainability and clarity. However, with web page development, appearance is everything and a slow-loading web site is unlikely to be successful. Always keep in
mind that unnecessary HTTP hits to the server should be avoided.

JavaScript-only files should have the filename suffix .js, and the server must map the .js suffix to the MIME type application/x-javascript, which it sends back in the HTTP header. If the server does not map the .js filename extension to application/x-javascript, Navigator will not properly load the JavaScript file specified by the SRC attribute. In short, your server must be configured to reflect the proper MIME type; otherwise, the browser does not respond properly with the data coming back in the HTTP response to the SRC-initiated request.

There are four specific data types in JavaScript: numbers, strings, Booleans, and null values.As opposed to other languages, a variable data type is not declared explicitly but rather implicitly according to its initial value assignment. Also unique to JavaScript, there is no explicit distinction between integers and real-valued numbers.

The Value Null
The value null is often used to initialize variables that do not have any special meaning. You assign it to a variable using the standard assignment statement:

var name = null

The null value is special in that it is automatically converted to initial values of other data types. When used as a number it becomes 0, when used as a string it becomes "", and when used as a Boolean value it becomes false. Since the source of many JavaScript errors is uninitialized variables, one of the common debugging techniques is to initialize all uninitialized variables, including the meaningless ones, with a null value.
The JavaScript interpreter uses the null value on two occasions:
(1) built-in functions return null under certain circumstances, and
(2) nonexistent properties evaluate to null.
When checking for a null value, you should check if it is false or if it is equal to null.

Type Conversion

In JavaScript data types are converted automatically as needed during the course of script execution. This can be quite convenient, and many other programming languages do not allow this. A variable may hold a numeric value at one point of the script and a string at another. The following statements constitute a valid JavaScript script:

var myVar = 12
myVar = "university"

An object’s properties hold its data. Obviously you will want to refer to that data at some point, either to put new data in or to get out what the object’s property contains. You can refer to properties using the following syntax:

objectReference.propertyName

objectReference is the name of the object that the property belongs to, or any other valid reference to the object.

A dot separates each object from its property. A hierarchical object structure, with objects and properties at different levels, uses the same
syntax:

object1.object2Property1.object3Property2.property3

Notice that all the elements in the middle are both objects and properties.

Another important concept is that a property belongs to an object, and to only one object. Different objects may have properties of the same name and type, but they are not the same property.

A variable may be named exactly like a property of an object. This is possible because properties are not of the same scope as variables.
However, a variable cannot have the same name as an object at the same level. For example, the statement var a = a.b.d is not valid (actually it is valid, but the value of a is lost).

You can refer to properties and methods using either the “dot” syntax or the array notation. In array notation, square brackets replace the dots. For example, the following expression refers to a.b.d:

a["b"]["d"]

You can use the array notation for both properties and methods. The general syntax is:

objectReference["propertyName"]
objectReference["methodName"]([arguments])

It is important to understand this alternative syntax, because you cannot always use the traditional dot syntax. For example, the first character of a property name cannot be a digit when using the dot syntax. When you create an array using the built-in Array object, you can only refer to the elements of the array via the array notation (e.g., myArray[0], myArray[99]). You must always use double quotes when you refer to a property of an object that is not an array. Here are some examples for using the array notation to reference methods and properties:

document["write"]("hello!")
window["alert"]("howdy!") // note: alert() == window.alert()
Math["PI"]

Sometimes you can only use the array notation. Suppose the variable str holds the string "write". You can use the following syntax instead of document.

write():
document[str]()

An object does not inherit from other objects, but it can be contained by another object if it is a property of that object.

JavaScript is completely based on dynamic binding. That is, object references are checked at run time.

The following script’s output might surprise you a little:

var num = 4
function funct1()
{
alert(num)
var num = 2
}
funct1()

will give alert message saying 'undefined'.

The term “undefined” means that a variable does not have a value at the desired point, although it has previously been declared. Generally speaking, JavaScript scans the entire script before any execution begins. During this scan, also called parsing, JavaScript evaluates each line of code, testing it for basic syntax errors. It also determines the scope of each variable, regardless of whether or not it is in a function. If it encounters a variable declaration with the keyword var, that variable is considered local, even if a global variable with the same name exists. A variable’s scope can be either the entire script or just one function. In the preceding script segment, a global variable num is declared by initializing it to 4. The function consists of one local variable declaration. Note that the variable num inside the function has no
connection to the global variable num. The function is executed, as usual, from top to bottom. The first statement instructs JavaScript to display the value of num, the local variable inside the function. JavaScript already knows that the local variable is declared inside the function, so it does not generate an error. However, at that point, the variable does not retain any value, so it is undefined.

If you declare global variables inside a function, you must assign an initial value to the variable; otherwise, JavaScript returns an error. The
following script segment and screen capture demonstrate this fact:

function foo()
{
// local variable declarations
var a // without initialization
var b = 0 // with initialization
// global variable declarations
c // without initialization — error!
d = 0 // with initialization
}
foo()

// Runtime error occurs.

Using the arguments Array

JavaScript supports functions that accept a variable number of arguments. The first argument is functionName.arguments[0], the second one is
functionName.arguments[1], the third one is functionName.arguments[2], and so on. The number of arguments handed to the function is
stored in the length property of the arguments object:

functionName.arguments.length

The following script demonstrates this concept:

function calc()
{
document.write("The first argument is ", calc.arguments[0], "
")
document.write("The fourth argument is ", calc.arguments[3], "
")
document.write("There are ", calc.arguments.length, " arguments
")
}
var company = "Yahoo"
calc(2, 999, "internet", company, 0.0)

The script’s output is:

The first argument is 2
The fourth argument is Yahoo
There are 5 arguments

The division operator also performs the usual arithmetic conversion. However, since JavaScript is loosely typed, this operator does not act exactly as in C, Perl, Java and other strictly typed programming languages. In those languages, integer division is different from floating-point division in that the result of integer division is always an integer number. JavaScript, on the other hand, does not explicitly distinguish between integers and real-valued numbers, and therefore, the result of a division operation is not guaranteed to be an integer number. In fact, most floating-point numbers are the result of a division operator. While debugging a script, it may be helpful to remember
that the division operation in JavaScript generates the same value as your pocket calculator. You should also remember that the remainder of a
division operation is never discarded.

When the operands are floating-point numbers and cannot be represented in binary notation, division expressions often evaluate to inaccurate
results.

3 / 4 // evaluates to 0.75
3.6 / 0.1 // evaluates to 36
–20 / 4 // evaluates to –5
11.1 / 2.22 // evaluates to 4.999999999999999

Data Type Operator

typeof operand1
or
typeof (operand1)

JavaScript provides an operator to check the data type of its operand. The operand can be either a literal or a data structure such as a variable, a function, or an object. The operator returns the data type. The expression includes the word typeof followed by the literal or identifier. Here are some examples:

typeof foo == "undefined" // when foo is undefined
typeof eval == "function" // eval is a built-in function
typeof null == "object" // null is an object
typeof 3.14 == "number"
typeof true == "Boolean"
typeof "a string" == "string"
// all of the expressions are true, of course

The typeof operator is very useful for debugging. Until strong debugging tools are available, you must do all debugging by hand, and detecting the data type of a structure is sometimes essential.

Events :
Events are actions that occur in response to a specific user action on the web site. For example, clicking on a form element will trigger a click event. The events occur regardless of whether you provide code to respond to them. JavaScript provides you with a method to respond to these events and to take action based on them. In this way your web page becomes very dynamic, responding to user interaction.

Not all actions that take place in your browser are events. Events are only actions that occur in the area of the HTML page, such as loading images and selecting form elements. If an action occurs directly in the boundary of the browser’s display zone, it is an event as well. In short, an event is only concerned with action on the web page itself, not on the browser.

Event Handlers
Event handlers correspond to their associated events. They are functions that execute automatically when events occur. Many JavaScript functions are called by event handlers. You saw earlier that events are actions that do not have any direct influence; they only serve the event handlers. Each event handler is associated with an event.

Arrays in Javascript:

I found this topic very intresting

In JavaScript, specifying the length of the array or the number of elements is not vital. An array is an object like any other object. There is no explicit array type in JavaScript.

Here are some arrays:

var day = new Array(31)
var month = new Array(12)
var year = new Array() // number of years "not known"

All elements of an array are initially null. This is important because such elements do not have any influence on your script. An element with a null value actually does not exist.

Strongly typed programming languages require that you specify the number of elements in an array. In such languages all elements of an array
must contain values of the same type (int, char, …). An array is an explicit data structure in those languages. From the moment an array is declared, it takes up the required storage area in memory. It does not matter if you initialized its values or not. JavaScript, however, does not require you to initialize the elements in an array when you create it. Theoretically, if you created an array without specifying the number of elements, it would be as if you created one with zero elements. Extending an array in such languages is usually not possible; therefore, you must specify the length in all array declarations.

The null value is given by default to each element of an array in JavaScript. When the value is null, the element is not stored in the computer’s memory. So creating an array with an infinite number of elements is fine in JavaScript. However, doing so is not recommended since it would be confusing to people who read your code, and not particularly useful. Keep in mind that elements holding a null value do not take up space in memory, but they are considered elements in the array, so they are added to the array’s length property.

With JavaScript (unlike C++), it doesn’t matter whether the elements of an array are of the same data type. They can be a mix of numbers, strings, Boolean values, objects, and even arrays (which are actually objects).

Referring to an Array’s Elements Creating an array is fine, but you must be able to use it. To use an array, whether you are putting data in or taking it out, you need to access the elements of that array. Keep in mind that arrays in JavaScript are objects. Like all other objects, they have properties and methods:

arrayObjectName[subscript] // ar1[4]

The subscript follows the array name and is enclosed in square brackets. Subscripts are simple integers that start at zero.

Here is a simple array:

var ar = new Array(5)

This array has five elements: ar[0], ar[1], ar[2], ar[3], and ar[4].

After you create an array you can increase its length by specifying a value for the highest subscript element. The following code creates an array of length zero, then assigns a null value to element 99. This changes the length of the array to 100.

accounts = new Array() // array of zero elements
accounts[99] = null // array of 100 elements

Note that the array does not take up any storage space, even after it is extended.

Creating Dense Arrays

Recall that we stated earlier that you need not initialize the elements in an array before you use it. However, nothing says you cannot initialize them. This is often referred to as a dense array. A dense array is one in which each element has a value. You can construct a dense array of two or more elements starting with index (subscript) 0, if you define initial values for all elements. They are very popular in many scripting languages. You can populate an array by specifying the values of its elements:

var bb = "baseball"
var sports = new Array("football", bb, "basketball", "soccer")

You can refer to the elements of this array with the common syntax:

sports[0] == "football"
sports[1] == "baseball"
var val = 2
sports[val] == "basketball"
sports[3] == "soccer"

Array Types

You must keep in mind that JavaScript is a loosely typed language. It should not be surprising, therefore, that elements of an array can be of different types. Some elements of a given array can be strings, while others can be numbers, Boolean values, and even objects. Basically, there are five types of arrays:

1. String arrays
2. Number arrays
3. Boolean arrays
4. Object arrays (including null arrays, because null is an object)
5. Mixed arrays

Sometimes you want to know what type of array you are dealing with. JavaScript does not include any tool to facilitate this. However, using a prototype we can add a property to all arrays (remember, arrays are objects by which you can create instances) that will return the type of the array. Here is the desired method:

We can improve the efficiency of the above function by changing the loop statement.

The improvement in this function is the type of loop used.

The for...in construct loops only through the existing properties, or elements, not including the null ones. The function works just like the previous one.

At first, the data type of the first element of the array is assigned to arrayType. In every iteration of the loop, if a different type of element is found, the value of arrayType is changed to "mixed" because at least two different data types have been found in the array. Once a "mixed" array is detected, the loop is immediately terminated using a break statement.

Sometimes you want to refer to all elements of a uniform-type array. The following method is designed to be a prototype of the Array object,
returning an array of element subscripts where the specified value has been found. Here is the method:

function getSubscripts(type)
{
var ar = new Array()
var arSub = 0
for (var i = 0; i < this.length; ++i){
if (typeof this[i] == type){
ar[arSub] = this[i];
++arSub;
}
}
return ar
}

Array.prototype.getSubscripts = getSubscripts

Array Properties
Although you can add your own properties to the Array object, not all tasks can be achieved by high-level programming via JavaScript. The only built-in property of the Array object is length. Fortunately, this is also the most commonly needed property for any array. When you create an instance of an object (an array), the number of properties (elements) is stored in the length property. You can refer to it as a regular property.

Array Methods

JavaScript features a number of methods, three of which are built-in methods:

1. join()
2. reverse()
3. sort()

chop()
The chop() method chops off the last character of all strings that are elements of an array. Here is an example:

function chop(){
for (var i in this){
if (typeof this[i] == "string")
this[i] = this[i].substring(0, this[i].length – 1)
}
}

Array.prototype.chop = chop

// EXAMPLE
var line = new Array("red", "green", "blue");
line.chop();
document.write(line.getList(" "));

The script’s output is:
re gree blu

The general syntax is:
arrayInstance.chop()

grep()

The term “grep” is borrowed from the Unix world where grep is a standard search function. We use that same concept here in JavaScript. The grep() method evaluates the expression (expr) for each element of the array. It returns another array consisting of those elements for which the expression evaluated to true (the pattern was matched). To understand this method you should know that if string2 is found in string1,
string1.indexOf(string2) is not equal to –1. Here is the method:

function grep(str){
var ar = new Array()
var arSub = 0
for (var i in this){
if (typeof this[i] == "string" && this[i].indexOf(str) != –1){
ar[arSub] = this[i];
arSub++;
}
}
return ar;
}
Array.prototype.grep = grep
var line = new Array("mask", "Mascot", "mine", "amass", "hot")
document.write(line.grep("mas").getList(" "))
document.write("
")
document.write(line.grep("mas").length)

The output of this script is:
mask amass
2

The general syntax is:
arrayInstance.grep(expr)

Like this you can keep on writing your own prototypes... and add methods and properties dynamically.

Associative Arrays:
Associative arrays use strings as subscripts. For example, an element of the array can be:
color["yellow"] = "FFFF00"

Such arrays group together related data. These arrays are actually objects, except that you use square brackets instead of a dot. Another important difference is that array specification (square brackets) enables you to refer to the value of a variable as the property of method specification rather than the actual literal. For example:

var col = "yellow"
color[col] = "FFFF00"
Here is another interesting example:
var w = "write"
document[w]("Hello!") // prints "Hello!"

If you replace the array notation with the regular dot specification you receive an error:

var w = "write"
document.w("Hello!")

The dot notation requires the actual literal specified, as it does not evaluate the written value. You can use associative arrays to create nested objects resembling multidimensional arrays. For example, you can create an associative array where its subscripts are names of students in a class, so each element of the associative array is an object containing fields such as the student’s grade, age, and so on.

Note that associative arrays cannot be created as instances of the built-in Array object. You must use a constructor function to create one.
Here is an example using students:

function studentClass(){
for (var i = 0; i < arguments.length; ++i){
this[studentClass.arguments[i]] = new student()
}
}

function student(){

// this.grade = null
// this.age = null

}

var students = new studentClass("Bob", "John", "Frank", "Alfred","Sheila", "Mary")

students["Bob "].grade = 40
students["John "].age = 11
students["Frank "].grade = "N/A"
alert(students["Frank "].grade)

Creating an associative array is not difficult. Array elements are created according to the names of the students accepted as parameters by the function studentClass(). The second function is rather strange—it contains no statements. When you create an instance you can use an “empty” constructor function. You may recall from an earlier discussion that objects may be extended by simply assigning values to them. So, the statement this[studentClass.arguments[i]] = new student() just makes sure each element of the associative array is an object. The global statements later create the properties simply by assigning them values.

Another important concept to remember is that associative arrays are not explicit arrays. You can also refer to them using the dot syntax, as in:

students.John.age

The Date Object in Javascript

JavaScript comes with a built-in Date object that allows you to easily work with date and time data and related functions. Both dates and times in JavaScript are derived from the Date object, which behaves much like any other object. To implement the current date or time in your script, you must first create a new instance of the object. You can then extract the desired data from that particular instance. JavaScript handles dates in a manner very similar to Java. Many methods are implemented in both languages, resulting in an observable parallelism.

var dateInstance = new Date()

JavaScript provides JavaScript programmers with a variety of methods to deal with instances of the Date object. However, extracting and manipulating their data makes them one of the most important elements of the language.

getYear()
getMonth() //0 to 11
getDate()
getDay() //Sunday, Monday, Tuesday,...
getHours()
getMinutes()
getSeconds()
getTime()

//setters for the above...

& many more methods.

Time-Related Methods of Other Objects

setTimeout()

The setTimeout() method evaluates an expression after a specified number of milliseconds have elapsed. Its general syntax is:

timeoutID = setTimeout(expression, msec)

timeoutID is an identifier used to identify the current timeout. expression is a string expression or property of an existing object. It is
normally a simple statement that is to be executed after the specified time has ticked off.

msec is a numeric value, a numeric string, or a property of an existing object in millisecond units.

The setTimeout() method evaluates an expression after a specified amount of time. Take a look at the following example:


<HTML>
<HEAD>
<TITLE>setTimeout() method</TITLE>
<SCRIPT LANGUAGE = "JavaScript">
function displayAlert()
{
alert("5 seconds have elapsed since the button was clicked.")
}
</SCRIPT>
</HEAD>
<BODY>
<FORM>
Click the button on the left for a reminder in 5 seconds;
click the button on the right to cancel the reminder before
it is displayed.
<P>
<INPUT TYPE = "button" VALUE = "5-second reminder"
NAME = "remind_button"
onClick = "timerID = setTimeout('displayAlert()',5000)">
</FORM>
</BODY>
</HTML>

When you click the button, the event handler’s script sets a timeout. The timeout specifies that after 5,000 milliseconds, or five seconds, the function displayAlert() is called. Therefore, five seconds after you click the button an alert box is displayed.

This method does not repeatedly execute the specified statement. That is, it does not execute it every five seconds. When the time limit specified has ticked down, the statement is executed and the timeout does not exist anymore. setTimeout() is a method of the window or frame object, depending on the basic structure of the HTML document it is used in.

and also we have some math related methods also like parseInt(), parseFloat() also.

and also we have some string functions like... charAt(), indexOf(), substring(), toString()

The Document Object Model

The Document Object Model (DOM), one of the most powerful tools available to a web developer, is a hierarchy of objects that represent the web
browser, the browser’s history, the currently loaded web page, and other important elements.

hierarchy in DOM is...
1. Window
1.a.navigator
1.b.screen
1.c.history
1.d.location
1.e.document

The window Object

The window object is at the top of the DOM hierarchy. This object represents the browser window. You will find that you don’t often deal directly with the window object, but rather as the container for the other objects you use directly on a regular basis. This doesn’t mean that you never use the window object directly, merely that it is not as commonly used as other objects.

The window object contains properties that apply to the entire window. For example, the status bar of the browser is a property of this object. It also includes a property that is actually the object itself.

few examples of ways you might use the window object.

var newwindow = window.open("http://www.chuckeasttom.com") //Open a new browser
window.newwindow.focus //Set focus to that window.
newwindow.close //Close that window.

The navigator Object

This object provides information about the browser being used. This can be quite useful in gathering information about people who visit your web site. In fact, the amount of information you can derive from this object is really rather astounding.

some of the methods and properties of the navigator object.

appName //The name of the end user’s browser.
appVersion //The version number of the end user’s browser.
cookieEnabled //Whether or not the end user’s browser has cookies enabled.
platform //The end user’s operating system.
javaEnabled() //A method that returns a Boolean telling if the browser has JavaScript enabled.

The document Object

By far the most useful object of the DOM is the document object. It contains properties for the current page loaded in the window. The properties of this object are content-dependent because each and every page has its own outline and elements. Almost everything in the page is a property of the document object, including links, images, forms and their elements, anchors, and more. Because each frame is a window (window object), it contains a document object as well. Even the background and the title are properties of this object.

write() //This is a very commonly used method and writes to the HTML page whatever is passed to the write function.
fileCreatedDate //This property shows when the loaded HTML file was created.
linkColor //This property shows the color of HTML links in the document. It is specified in the BODY tag.
open() //This method opens a new document in a new window.
embeds //An array containing all the plug-ins in a document.

The history Object

The history object is also a property of the window object. It contains properties of the URLs the user has previously visited. This information is stored in a history list, and is accessible through the browser’s menu. If the document consists of child documents in frames, each frame has its own history list, or history object. This object also contains methods enabling you to send the user’s browser to a URL found in the history list.

some of the history object’s most important properties and methods are below.

current //The current document URL.
previous //The URL of the last document in the history list.
next //The URL of the next document in the history list.
length //The number of entries currently stored in the history object.

The location Object

The location object contains properties of the current URL. Although you may think of URLs as simple standard structures, they are far more than
that. There are many types of protocols and various sections in every URL. There are also optional sections in the URL, such as anchor names and queries.

host //The URL hostname and port.
href // The entire URL.
port //The port being used.
search //The URL query string section (i.e., the section after and including the question mark).
reload //The location.reload method forces a reload of the window’s current document.
replace //The replace() method is also a property of the location, or window.location, object. It overwrites the current history entry with the specified URL.

Each property of the location object represents a different portion of the URL. The following syntax of a URL shows the relationship between the object’s properties:

protocol//hostname:port pathname search hash

Since the Document Object Model is a W3C specification, this means its behavior and usage are not dependent on a particular vendor. The DOM should be the same with Internet Explorer, Mozilla, or any browser. An important objective for any W3C standard and for the Document Object Model is to provide a standard that can be used in a wide variety of environments and applications. The DOM is designed to be used with any programming language.

Hope it will be useful...

Class Loaders in Java

2009-02-06T08:47:00.000-08:00

Yesterday I was to know about Class Loaders and I found it very interesting. I would like to share with you the same.

The Class loader concept, one of the cornerstones of the Java virtual machine, describes the behavior of converting a named class into the bits responsible for implementing that class. Because class loaders exist, the Java run time does not need to know anything about files and file systems when running Java programs.

Class loaders are hierarchical. Classes are introduced into the JVM as they are referenced by name in a class that is already running in the JVM. So how is the very first class loaded? The very first class is specially loaded with the help of static main() method declared in your class. All the subsequently loaded classes are loaded by the classes, which are already loaded and running. A class loader creates a namespace. All JVMs include at least one class loader that is embedded within the JVM called the primordial (or bootstrap) class loader. It is somewhat special because the virtual machine assumes that it has access to a repository of trusted classes which can be run by the VM without verification.

When a new JVM instance is started , the bootstrap class loader is responsible for loading key java classes like java.lang.Object and other runtime code into memory. The runtime classes are packaged inside jre/lib/rt.jar file. We cannot find the details of the bootstrap class loader in the java language specification, since this is a native implementation. For this reason the behavior of the bootstrap class loader will differ across JVMs.

Java can change its class storage model simply by changing the set of functions that implements the class loader.

Now let’s look at non-primordial class loaders. The JVM has hooks in it to allow user defined class loaders to be used in place of primordial class loader.

ex : Bootstrap (primordial) Loads JDK internal classes, java.* packages. (as defined in the sun.boot.class.path system property, typically loads rt.jar and i18n.jar) and is the parent in the Class loaders hierarchy.

next comes the Extensions (Loads jar files from JDK extensions directory (as defined in the java.ext.dirs system property – usually lib/ext directory of the JRE) and then System (Loads classes from system classpath (as defined by the java.class.path property, which is set by the CLASSPATH environment variable or –classpath or –cp command line options) ClassLoaders.

Classes loaded by Bootstrap class loader have no visibility into classes loaded by its descendants (ie Extensions and Systems class loaders).

The classes loaded by system class loader have visibility into classes loaded by its parents (ie Extensions and Bootstrap class loaders).

If there were any sibling class loaders they cannot see classes loaded by each other. They can only see the classes loaded by their parent class loader. For example Sibling1 class loader cannot see classes loaded by
Sibling2 class loader

Both Sibling1 and Sibling2 class loaders have visibilty into classes loaded by their parent class loaders (eg: System, Extensions, and Bootstrap)

Class loaders are hierarchical and use a delegation model when loading a class. Class loaders request their parent to load the class first before attempting to load it themselves. When a class loader loads a class, the child class loaders in the hierarchy will never reload the class again. Hence uniqueness is maintained. Classes loaded by a child class loader have visibility into classes loaded by its parents up the hierarchy but the reverse is not true

Note : Two objects loaded by different class loaders are never equal even if they carry the same values, which mean a class is uniquely identified in the context of the associated class loader. This applies to singletons too, where each class loader will have its own singleton.

At its simplest, a class loader creates a flat name space of class bodies that are referenced by a string name. The method definition is:

Class r = loadClass(String className, boolean resolveIt);

The variable className contains a string that is understood by the class loader and is used to uniquely identify a class implementation. The variable resolveIt is a flag to tell the class loader that classes referenced by this class name should be resolved (that is, any referenced class should be loaded as well).

We can build our own ClassLoader by being a subclass of java.lang.ClassLoader. The only abstract method that must be implemented is loadClass().

Static Class Loading :

Classes are statically loaded with Java’s 'new' operator.


class MyClass {
 public static void main(String args[]) {
  Car c = new Car();
 }
}

A NoClassDefFoundException is thrown if a class is referenced with Java’s 'new' operator (i.e. static loading) but the runtime system cannot find the referenced class.

Dynamic class loading:

Dynamic loading is a technique for programmatically invoking the functions of a class loader at run time.

we can load classes dynamically by...


Class.forName (String className); //static method which returns a Class

The above static method returns the class object associated with the class name. The string className can be supplied dynamically at run time. Unlike the static loading, the dynamic loading will decide whether to load the class Car or the class Jeep at runtime based on a properties file and/or other runtime conditions. Once the class is dynamically loaded the following method returns an instance of the loaded class. It’s just like creating a class object with no arguments.


class.newInstance (); //A non-static method, which creates an instance of a class (i.e. creates an object).
Jeep myJeep = null ;

//myClassName should be read from a properties file or Constants interface.

//stay away from hard coding values in your program. 
String myClassName = "au.com.Jeep" ;
Class vehicleClass = Class.forName(myClassName) ;
myJeep = (Jeep) vehicleClass.newInstance();
myJeep.setFuelCapacity(50);

A ClassNotFoundException is thrown when an application tries to load in a class through its string name using the following methods but no definition for the class with the specified name could be found:
1. The forName(..) method in class - Class.
2. The findSystemClass(..) method in class - ClassLoader.
3. The loadClass(..) method in class - ClassLoader.

The Java virtual machine has hooks in it to allow a user-defined class loader to be used in place of the primordial one. Furthermore, since the user class loader gets first crack at the class name, the user is able to implement any number of interesting class repositories, not the least of which is HTTP servers -- which got Java off the ground in the first place.

There is a cost, however, because the class loader is so powerful (for example, it can replace java.lang.Object with its own version), Java classes like applets are not allowed to instantiate their own loaders. (This is enforced by the class loader, by the way.) This column will not be useful if you are trying to do this stuff with an applet, only with an application running from the trusted class repository (such as local files).

Hope it will be useful...

Generics in the Java Programming Language by Gilid Bracha

2009-01-26T04:08:00.000-08:00

Yesterday I read Generics in the Java Programming Language by Gilid Bracha.

I would like to thank author for producing such an excellent information.

I really enjoyed reading each and every point and would like to share them with you.


List<Integer> myIntList = new LinkedList<Integer>(); 
myIntList.add(new Integer(0)); 
Integer x = myIntList.iterator().next();

Notice the type declaration for the variable myIntList. It specifies that this is not just an arbitrary List, but a List of Integer, written List. We say that List is a generic interface that takes a type parameter - in this case, Integer. We also specify a type parameter when creating the list object.


public interface List<E> { 
 void add(E x);
 Iterator<E> iterator();
}
public interface Iterator<E> { 
 E next();
 boolean hasNext();
}

Type parameters can be used throughout the generic declaration, pretty much where you would use ordinary types.

As we saw invocations of the generic type declaration List, such as List. In the invocation (usually called a parameterized type), all occurrences of the formal type parameter (E in this case) are replaced by the actual type argument (in this case, Integer). You might imagine that List stands for a version of List where E has been uniformly replaced by Integer:


public interface IntegerList { 
 void add(Integer x)
 Iterator<Integer> iterator();
}

A generic type declaration is compiled once and for all, and turned into a single class file, just like an ordinary class or interface declaration.

Type parameters are analogous to the ordinary parameters used in methods or constructors. Much like a method has formal value parameters that describe the kinds of values it operates on, a generic declaration has formal type parameters. When a method is invoked, actual arguments are substituted for the formal parameters, and the method body is evaluated. When a generic declaration is invoked, the actual type arguments
are substituted for the formal type parameters.

Generics and Subtyping

What about the below code???


List<String> ls = new ArrayList<String>(); 
List<Object> lo = ls;

Line 1 is certainly legal. The trickier part of the question is line 2.
The Java compiler will prevent this from happening of course. Line 2 will cause a compile time error.
This boils down to the question: is a List of String a List of Object. Most people’s instinct is to answer:
“sure!”.
Well, take a look at below code:


lo.add(new Object()); 
String s = ls.get(0);

Here we’ve aliased ls and lo. Accessing ls, a list of String, through the alias lo, we can insert arbitrary objects into it. As a result ls does not hold just Strings anymore, and when we try and get something out of it, we get a rude surprise.

In general, if Foo is a subtype (subclass or subinterface) of Bar, and G is some generic type declaration, it is not the case that G is a subtype of G. This is probably the hardest thing you need to learn about generics, because it goes against our deeply held intuitions.

We will look further how to cope with this sort of situation

Wildcards

Consider the problem of writing a routine that prints out all the elements in a collection.

Here’s how you might write it in an older version of the language:


void printCollection(Collection c) {
 Iterator i = c.iterator();
 for (k = 0; k < c.size(); k++) {
  System.out.println(i.next());
 }
}

And here is a naive attempt at writing it using generics (and the new for loop syntax):


void printCollection(Collection<Object> c) {
 for (Object e : c) {
 System.out.println(e);
 }
}

The problem is that this new version is much less useful than the old one. Whereas the old code could be called with any kind of collection as a parameter, the new code only takes Collection<Object>, which, as we’ve just demonstrated, is not a supertype of all kinds of collections!

So what is the supertype of all kinds of collections? It’s written Collection (pronounced “collection of unknown”) , that is, a collection whose element type matches anything. It’s called a wildcard type for obvious reasons. We can write:


void printCollection(Collection<?> c) {
 for (Object e : c) {
 System.out.println(e);
 }
}

and now, we can call it with any type of collection. Notice that inside printCollection(), we can still read elements from c and give them type Object. This is always safe, since whatever the actual type of the collection, it does contain objects. It isn’t safe to add arbitrary objects to it however:


Collection<?> c = new ArrayList<String>();
c.add(new Object()); // compile time error

Since we don’t know what the element type of c stands for, we cannot add objects to it. The add() method takes arguments of type E, the element type of the collection. When the actual type parameter is ?, it stands for some unknown type. Any parameter we pass to add would have to be a subtype of this unknown type. Since we don’t know what type that is, we cannot pass anything in. The sole exception is null, which is a
member of every type.

On the other hand, given a List, we can call get() and make use of the result. The result type is an unknown type, but we always know that it is an object. It is 5 therefore safe to assign the result of get() to a variable of type Object or pass it as a parameter where the type Object is expected.

Bounded Wildcards

Consider a simple drawing application that can draw shapes such as rectangles and circles.

To represent these shapes within the program, you could define a class hierarchy such as this:


public abstract class Shape {
 public abstract void draw(Canvas c);
}

public class Circle extends Shape {
 private int x, y, radius;
 public void draw(Canvas c) { ... }
}

public class Rectangle extends Shape {
 private int x, y, width, height;
 public void draw(Canvas c) { ... }
}

These classes can be drawn on a canvas:

public class Canvas { 
 public void draw(Shape s) {
  s.draw(this);
 }
}

Any drawing will typically contain a number of shapes. Assuming that they are represented as a list, it would be convenient to have a method in Canvas that draws them all:


public void drawAll(List<Shape> shapes) { 
 for (Shape s: shapes) {
  s.draw(this);
 }
}

Now, the type rules say that drawAll() can only be called on lists of exactly Shape: it cannot, for instance, be called on a List. That is unfortunate, since all the method does is read shapes from the list, so it could just as well be called on a List. What we really want is for the method to accept a list of any kind of shape:


public void drawAll(List<? extends Shape> shapes) { ... }

There is a small but very important difference here: we have replaced the type List with List. Now drawAll() will accept lists of any subclass of Shape, so we can now call it on a List if we want.

List is an example of a bounded wildcard. The ? stands for an unknown type, just like the wildcards we saw earlier. However, in this case, we know that this unknown type is in fact a subtype of Shape1. We say that Shape is the upper bound of the wildcard.

There is, as usual, a price to be paid for the flexibility of using wildcards. That price is that it is now illegal to write into shapes in the body of the method. For instance, this is not allowed:


public void addRectangle(List<? extends Shape> shapes) {
 shapes.add(0, new Rectangle()); // compile-time error!
}

You should be able to figure out why the code above is disallowed. The type of the second parameter to shapes.add() is ? extends Shape - an unknown subtype of Shape. Since we don’t know what type it is, we don’t know if it is a supertype of Rectangle; it might or might not be such a supertype, so it isn’t safe to pass a Rectangle there.

Generic Methods

Consider writing a method that takes an array of objects and a collection and puts all objects in the array into the collection.

Here is a first attempt:


static void fromArrayToCollection(Object[] a, Collection<?> c) {
 for (Object o : a) { 
  c.add(o); // compile time error
 }
}

By now, you will have learned to avoid the beginner’s mistake of trying to use Collection<Object> as the type of the collection parameter. You may or may not have recognized that using Collection<?> isn’t going to work either. Recall that you cannot just shove objects into a collection of unknown type.

The way to do deal with these problems is to use generic methods. Just like type declarations, method declarations can be generic - that is, parameterized by one or more type parameters.


static <T> void fromArrayToCollection(T[] a, Collection<T> c) {
 for (T o : a) {
  c.add(o); // correct
 }
}

We can call this method with any kind of collection whose element type is a supertype of the element type of the array.

Notice that we don’t have to pass an actual type argument to a generic method. The compiler infers the type argument for us, based on the types of the actual arguments. It will generally infer the most specific type argument that will make the call type-correct.

when should I use generic methods, and when should I use wildcard types?

To understand the answer, let’s examine a few methods from the Collection libraries.


interface Collection<E> { public boolean containsAll(Collection<?> c);
 public boolean addAll(Collection<? extends E> c);
}

We could have used generic methods here instead:


interface Collection<E> { public <T> boolean containsAll(Collection<T> c);
 public <T extends E> boolean addAll(Collection<T> c);
}

type variables can have bounds too!

However, in both containsAll and addAll, the type parameter T is used only once. The return type doesn’t depend on the type parameter, nor does any other argument to the method (in this case, there simply is only one argument). This tells us that the type argument is being used for polymorphism; its only effect is to allow a variety of actual argument types to be used at different invocation sites. If that is the case, one
should use wildcards. Wildcards are designed to support flexible subtyping, which is what we’re trying to express here.

Generic methods allow type parameters to be used to express dependencies among the types of one or more arguments to a method and/or its return type. If there isn’t such a dependency, a generic method should not be used.

It is possible to use both generic methods and wildcards in tandem.

Using Legacy Code in Generic Code

Calling legacy code from generic code is inherently dangerous; once you mix generic code with non-generic legacy code, all the safety guarantees that the generic type system usually provides are void. However, you are still better off than you were without using generics at all. At least you know the code on your end is consistent.

At the moment there’s a lot more non-generic code out there then there is generic code, and there will inevitably be situations where they have to mix.
If you find that you must intermix legacy and generic code, pay close attention to the unchecked warnings. Think carefully how you can justify the safety of the code that gives rise to the warning.

What happens if you still made a mistake, and the code that caused a warning is indeed not type safe? Let’s take a look at such a situation. In the process, we’ll get some insight into the workings of the compiler.

Erasure and Translation


public String loophole(Integer x) { List<String> ys = new LinkedList<String>();
 List xs = ys;
 xs.add(x); // compile-time unchecked warning
 return ys.iterator().next();
}

Here, we’ve aliased a list of strings and a plain old list. We insert an Integer into the list, and attempt to extract a String. This is clearly wrong. If we ignore the warning and try to execute this code, it will fail exactly at the point where we try to use the wrong type. At run time, this code behaves like:


public String loophole(Integer x) { List ys = new LinkedList;
 List xs = ys;
 xs.add(x);
 return (String) ys.iterator().next(); // run time error
}

When we extract an element from the list, and attempt to treat it as a string by casting it to String, we will get a ClassCastException. The exact same thing happens with the generic version of loophole(). The reason for this is, that generics are implemented by the Java compiler as a front-end conversion called erasure. You can (almost) think of it as a source-to-source translation, whereby the generic version of loophole() is converted to the non-generic version.

As a result, the type safety and integrity of the Java virtual machine are never at risk, even in the presence of unchecked warnings. Basically, erasure gets rid of (or erases) all generic type information. All the type information betweeen angle brackets is thrown out, so, for example, a parameterized type like List is converted into List. All remaining uses of type variables are replaced by the upper bound of the type variable (usually Object). And, whenever the resulting code isn’t type-correct, a cast to the appropriate type is inserted, as in the last
line of loophole.

A Generic Class is Shared by all its Invocations.


List <String> l1 = new ArrayList<String>();
List<Integer> l2 = new ArrayList<Integer>();
System.out.println(l1.getClass() == l2.getClass());

It prints true, because all instances of a generic class have the same run-time class, regardless of their actual type parameters.

Indeed, what makes a class generic is the fact that it has the same behavior for all of its possible type parameters; the same class can be viewed as having many different types.

As consequence, the static variables and methods of a class are also shared among all the instances. That is why it is illegal to refer to the type parameters of a type declaration in a static method or initializer, or in the declaration or initializer of a static variable.

Generic class is shared among all its instances, is that it usually makes no sense to ask an instance if it is an instance of a particular
invocation of a generic type:


Collection cs = new ArrayList<String>();
if (cs instanceof Collection<String>) { ...} // illegal

similarly, a cast such as


Collection<String> cstr = (Collection<String>) cs; // unchecked warning

gives an unchecked warning, since this isn’t something the run time system is going to check for you. The same is true of type variables


<T> T badCast(T t, Object o) {return (T) o; }// unchecked warning

Type variables don’t exist at run time. This means that they entail no performance overhead in either time nor space, which is nice. Unfortunately, it also means that you can’t reliably use them in casts.

Arrays

The component type of an array object may not be a type variable or a parameterized type, unless it is an (unbounded) wildcard type.You can declare array types whose element type is a type variable or a parameterized type, but not array objects.

This is annoying, to be sure. This restriction is necessary to avoid situations like:


List<String>[] lsa = new List<String>[10]; // not really allowed
Object o = lsa;
Object[] oa = (Object[]) o;
List<Integer> li = new ArrayList<Integer>();
li.add(new Integer(3));
oa[1] = li; // unsound, but passes run time store check
String s = lsa[1].get(0); // run-time error - ClassCastException

If arrays of parameterized type were allowed, the example above would compile without any unchecked warnings, and yet fail at run-time. We’ve had type-safety as a primary design goal of generics. In particular, the language is designed to guarantee that if your entire application has been compiled without unchecked warnings using javac -source 1.5, it is type safe.

However, you can still use wildcard arrays. Here are two variations on the code above. The first forgoes the use of both array objects and array types whose element type is parameterized. As a result, we have to cast explicitly to get a String out of the array.


List<?>[] lsa = new List<?>[10]; // ok, array of unbounded wildcard type
Object o = lsa;
Object[] oa = (Object[]) o;
List<Integer> li = new ArrayList<Integer>();
li.add(new Integer(3));
oa[1] = li; // correct
String s = (String) lsa[1].get(0); // run time error, but cast is explicit

In the next variation, we refrain from creating an array object whose element type is parameterized, but still use an array type with a parameterized element type. This is legal, but generates an unchecked warning. Indeed, the code is unsafe, and eventually an error occurs.


List<String>[] lsa = new List<?>[10]; // unchecked warning - this is unsafe!
Object o = lsa;
Object[] oa = (Object[]) o;
List<Integer> li = new ArrayList<Integer>();
li.add(new Integer(3));
oa[1] = li; // correct
String s = lsa[1].get(0); // run time error, but we were warned

Similarly, attempting to create an array object whose element type is a type variable causes a compile-time error:


<T> T[] makeArray(T t) { 
 return new T[100]; // error
}

Since type variables don’t exist at run time, there is no way to determine what the actual array type would be.

More Fun with Wildcards

We’ve seen several examples where bounded wildcards were useful when reading from a data structure. Now consider the inverse, a write-only data structure.

The interface Sink is a simple example of this sort.


interface Sink<T> {
 flush(T t);
}

We can imagine using it as demonstrated by the code below. The method writeAll() is designed to flush all elements of the collection coll to the sink snk, and return the last element flushed.


public static <T> T writeAll(Collection<T> coll, Sink<T> snk){ T last;
 for (T t : coll) {
  last = t;
  snk.flush(last);
 }
 return last;
}
...
Sink<Object> s;
Collection<String> cs;
String str = writeAll(cs, s); // illegal call

As written, the call to writeAll() is illegal, as no valid type argument can be inferred; neither String nor Object are appropriate types for T, because the Collection element and the Sink element must be of the same type.

We can fix this by modifying the signature of writeAll() as shown below, using a wildcard.


public static <T> T writeAll(Collection<? extends T>, Sink<T>){...}
...
String str = writeAll(cs, s); // call ok, but wrong return type

The call is now legal, but the assignment is erroneous, since the return type inferred is Object because T matches the element type of s, which is Object.

The solution is to use a form of bounded wildcard we haven’t seen yet: wildcards with a lower bound. The syntax ? super T denotes an unknown type that is a supertype of T. It is the dual of the bounded wildcards we’ve been using, where we use ? extends T to denote an unknown type that is a subtype of T.


public static <T> T writeAll(Collection<T> coll, Sink<? super T> snk){...}
...
String str = writeAll(cs, s); // Yes!

Using this syntax, the call is legal, and the inferred type is String, as desired.

Wildcard Capture


Set<?> unknownSet = new HashSet<String>();
...

/** Add an element t to a Set s */
public static <T> void addToSet(Set<T> s, T t) {...}

The call below is illegal.

addToSet(unknownSet, “abc”); // illegal

It makes no difference that the actual set being passed is a set of strings; what matters is that the expression being passed as an argument is a set of an unknown type, which cannot be guaranteed to be a set of strings, or of any type in particular.

Now, consider


class Collections {
...
 <T> public static Set<T> unmodifiableSet(Set<T> set) { ... }
}
...
Set<?> s = Collections.unmodifiableSet(unknownSet); // this works! Why?

It seems this should not be allowed; yet, looking at this specific call, it is perfectly safe to permit it. After all, unmodifiableSet() does work for any kind of Set, regardless of its element type.

Because this situation arises relatively frequently, there is a special rule that allows such code under very specific circumstances in which the code can be proven to be safe. This rule, known as wildcard capture, allows the compiler to infer the unknown type of a wildcard as a type argument to a generic method.

Converting Legacy Code to Use Generics

Let us look at “generifying” old code.

If you decide to convert old code to use generics, you need to think carefully about how you modify the API.

You need to make certain that the generic API is not unduly restrictive; it must continue to support the original contract of the API. Consider again some examples from java.util.Collection.


//The pre-generic API looks like:
interface Collection { 
 public boolean containsAll(Collection c);
 public boolean addAll(Collection c);
}

//A naive attempt to generify it is:
interface Collection<E> { 
 public boolean containsAll(Collection<E> c);
 public boolean addAll(Collection<E> c);
}

While this is certainly type safe, it doesn’t live up to the API’s original contract. The containsAll() method works with any kind of incoming collection. It will only succeed if the incoming collection really contains only instances of E, but:

1. The static type of the incoming collection might differ, perhaps because the caller doesn’t know the precise type of the collection being passed in, or perhaps because it is a Collection<S>,where S is a subtype of E.

2. It’s perfectly legitimate to call containsAll() with a collection of a different type. The routine should work, returning false.

In the case of addAll(), we should be able to add any collection that consists of instances of a subtype of E. We already saw how to handle this situation correctly.

You also need to ensure that the revised API retains binary compatibility with old clients. This implies that the erasure of the API must be the same as the original, ungenerified API. In most cases, this falls out naturally, but there are some subtle cases. We’ll examine one of the subtlest cases we’ve encountered, the method Collections.max().


//signature for max() is:
public static <T extends Comparable<? super T>>
T max(Collection<T> coll)

This is fine, except that the erasure of this signature is


public static Comparable max(Collection coll)

which is different than the original signature of max():


public static Object max(Collection coll)

One could certainly have specified this signature for max(), but it was not done, and all the old binary class files that call Collections.max() depend on a signature that returns Object.

We can force the erasure to be different, by explicitly specifying a superclass in the bound for the formal type parameter T.


public static <T extends Object & Comparable<? super T>>
T max(Collection<T> coll)

This is an example of giving multiple bounds for a type parameter, using the syntax T1& T2 ... & Tn. A type variable with multiple bounds is known to be a subtype of all of the types listed in the bound. When a multiple bound is used, the first type mentioned in the bound is used as the erasure of the type variable.

Finally, we should recall that max only reads from its input collection, and so is applicable to collections of any subtype of T.

This brings us to the actual signature used in the JDK:


public static <T extends Object & Comparable<? super T>>
T max(Collection<? extends T> coll)

It’s very rare that anything so involved comes up in practice, but expert library designers should be prepared to think very carefully when converting existing APIs.

Hope it will be useful...

Visitor Pattern in Java

2009-01-18T23:44:00.000-08:00

Visitor Pattern is a way of separating an algorithm from an object structure upon which it operates. A practical result of this separation is the ability to add new operations to existing object structures without modifying those structures. Thus, using the visitor pattern helps conformance with the open/closed principle.

The Visitor must visit each element of the Composite that functionally is in a Traverser object.

Visitor is guided by the Traverser to gather state from all of the objects in the Composite.

Once the state has been gathered, the Client can have the Visitor perform various operations on the state. When new functionality is required, only the Visitor must be enhanced.

When to use Visitor Pattern:
1. Use Visitor Pattern when you want to add capabilities to a composite of objects and encapsulation is not important.

Visitor Benifits:
1. Allows you to add operations to a Composite structure without changing the structure iteself.
2. Adding new operations is relatively easy.
3. The code for operations performed by the Visitor is centralized.

Visitor Drawbacks:
1. Encapsulation of the Composite classes is broken when the Visitor is used.
2. Because the traversal function is involved, changes to the Composite structure are more difficult.

To implement the Visitor pattern, you create a Visitor interface for the visitor, and a Visitable interface for the collection to be visited. You then have concrete classes that implement the Visitor and Visitable interfaces.

Let us look at an example...


// Visitor
public interface JavaFeatureVisitor {
 void visit(Collections collections);
 void visit(Generics generics);
 void visitJavaFeatures(Java java);
}

// Visitable
public interface JavaFeature {
 void accept(JavaFeatureVisitor visitor);
}


// Concrete Visitables
class Collections implements JavaFeature{

 private String name;
 
 Collections(String name) {
  this.name = name;
 }
 String getName() {
  return this.name;
 }
 public void accept(JavaFeatureVisitor visitor) {
  visitor.visit(this);
 }
}


class Generics implements JavaFeature{
 
 public void accept(JavaFeatureVisitor visitor) {
  visitor.visit(this);
 }
}

public class Java {
 
 JavaFeature[] javaFeatures;
 
 public JavaFeature [] getJavaFeatures(){
  return javaFeatures.clone();
 }
 public Java() {
  this.javaFeatures = new JavaFeature[]
                                 { new Collections(" List "), new Collections(" Set "),
    new Collections(" Map ") ,new Generics()};
 }
}

// Concrete Visitors
public class JavaFeatureReadVisitor implements JavaFeatureVisitor {
 
 public void visit(Collections collections) {      
  System.out.println("Going through "+ collections.getName()
    + " Collections");
 }
 public void visit(Generics generics) {
  System.out.println("Going through  generics");
 }
 public void visitJavaFeatures(Java java) {
  System.out.println("\nLearning Java");
  for(JavaFeature javaFeature : java.getJavaFeatures()) {
   javaFeature.accept(this);
  }
  System.out.println("Got an Idea of Java Language");
 }
}

public class JavaFeatureImplVisitor implements JavaFeatureVisitor {
 
 public void visit(Collections collections) {
  System.out.println("using Collections "+ collections.getName());
 }
 public void visit(Generics generics) {
  System.out.println("using Generics");
 }
 public void visitJavaFeatures(Java java) {
  System.out.println("\nImplementing Java Features");
  for(JavaFeature javaFeature : java.getJavaFeatures()) {
   javaFeature.accept(this);
  }
  System.out.println("Very useful features");
 }
 
}


public class VisitorDemo {
 static public void main(String[] args){
  Java java = new Java();
  JavaFeatureVisitor learnJavaFeature = new JavaFeatureReadVisitor();
  JavaFeatureVisitor implJavaFeature = new JavaFeatureImplVisitor();
  learnJavaFeature.visitJavaFeatures(java);
  implJavaFeature.visitJavaFeatures(java);
 }
}

Hope it will be useful...

Flyweight Patternin Java

2009-01-17T14:29:00.000-08:00

A Flyweight is an object that minimizes memory occupation by sharing as much data as possible with other similar objects.

The reusable and variable parts of a class are broken into two classes to save resources.

Problem:
Designing objects down to the lowest levels of system "granularity" provides optimal flexibility,but can be unacceptably expensive in terms of performance and memory usgae.

Structure Summary:
1) Choose a class from which so many instances will be created that performance will suffer.
2) Identify the state associated with the class that will not vary from one instance to another,and the state that is peculiar to each individual instance.
3) State that is peculiar i.e cannot be shared will be maintained and supplied by client.
4) Hundreds of objects can now be exercised by caching and reusing a few "flyweight" objects.

Flyweight pattern describes how to share objects to allow their use at fine granularities without prohibitive cost.Each "Flyweight" object is divided into 2 pieces.
The state dependent(extrensic) part and the state-independent(intrinsic) part.

Intrinsic state is stored(shared) in the Flyweight object.
Extrensic state is stored or computed by client objects,and passed to the Flyweight when its operations are invoked.

Flyweights are shared objects and that using them can result in substantial performance gains.
Flyweights are typically instantiated by a flyweight factory that creates a limited number of flyweights and doles them out,one at a time to clients.

For example, you might have a pool of line objects that know how to draw lines. In that case, the flyweight factory could create one line object for each line color, such as one object for white lines and another for blue lines.
Those lines, which are flyweights, get reused whenever you draw white or blue lines.
If you have a drawing with 1,000 white lines and 6,000 blue lines, only two lines—instead of 7,000—are actually instantiated.

In java strings specified at compile-time are flyweights—strings that contain the same character sequence are shared. That sharing can greatly reduce memory footprints, and therefore, increase performance. Strings computed at runtime, are not flyweights by default; however, you can force the issue with the String.intern() which returns flyweights for strings computed at runtime.

Flyweights are stored in a Factory's repository.
The client restrains themselves from creating Flyweighs directly,and requests them from the Factory.
Each Flyweight cannot stand on its own.
Any Attributes that would make sharing impossible must be supplied by the client whenever a request is made of the Flyweight.
If the context lends itself to "economy of scale"(i.e the client can easily compute or look-up the necessary attributes),then the Flyweight pattern offers appropriate leverage.

CheckList:
1) Ensure the object overhead is an issue needing attention,and the client of the class is able and willing to absorb responsibility realignment.
2) Divide the target class's state into: shareable(intrinsic) state,and non-shareable(extrensic) state.
3) Remove the non-shareable state from the class attributes,and add it to the calling argument list of affected methods.
4) Create a factory that can cache and reuse existing class instances.
5) The client must use the Factory instead of the new operator to request objects.
6) The client(or a third party) must look-up or compute the non-shareable state,and supply that state to class methods.

Flyweight Considerations:
The effectiveness of Flyweight pattern as a caching mechanism depends heavily on certain characteristics of the data we are caching.

-> Application uses a large number of objects.
-> Storage(Memory) Cost is high to replicate this large number of multiple users.
-> Either the objects are immutable or their state can be made external.
-> Relatively few shared objects may replace many groups of objects.
-> Application does not depend on object identity.While the user may think they are getting a unique object, they actually have a reference from the cache.

The flyweight design pattern is not recommended when the objects in the cache change rapidly or unexpectedly.

Rules Of Thumb:
Whereas flyweight shows how to make lots of little objects,Facade shows how to make a single object represent an entire subsystem.[GoF,p138]

Flyweight is often combined with Composite to implement shared leaf nodes.[GoF,p206]

Terminal symbols within Interpreter's abstract syntax tree can be shared with Flyweight. [GoF. p255]

Flyweights explain when and how State objects can be shared.[GoF,p313]

Below is an example implemented using "FlyWeight" Pattern to book admissions in a school.


public class AdmissionContext {
 int std;
 
 public AdmissionContext(int std){
  this.std = std;  
 }

 public int getStd() {
  return std;
 }
 
}

public abstract class Admission {
 public abstract void admitStudent(AdmissionContext admissionContext);
}

public class GeneralAdmission extends Admission{
 String admissionType = null;
 
 public GeneralAdmission(String admissionType){
  this.admissionType = admissionType;
 }

 public String getAdmissionType() {
  return admissionType;
 }

 public void admitStudent(AdmissionContext admissionContext){
  System.out.println("Admissions type = "+admissionType+" for std "+admissionContext.getStd());
 }
}

public class GeneralAdmissionFactory {
 
 GeneralAdmission[] admissions = new GeneralAdmission[10];
 
 int seats = 0;
 
 public GeneralAdmission getGeneralAdmission(String admissionType){
  if(seats > 0){
   for(int i=0;i<seats;i++){
    if(admissionType.equals(admissions[i].getAdmissionType()))
     return admissions[i];
   }
  }
  admissions[seats] = new GeneralAdmission(admissionType);
  return admissions[seats++];
 }

 public GeneralAdmission[] getAdmissions() {
  return admissions;
 }

 public void setAdmissions(GeneralAdmission[] admissions) {
  this.admissions = admissions;
 }

 public int getSeats() {
  return seats;
 }

 public void setSeats(int seats) {
  this.seats = seats;
 }
 
 
}

public class FlightweightPatternDemo {
 
 static GeneralAdmission[] generalAdmissions = new GeneralAdmission[20];
 
 static AdmissionContext[] admissionContexts = new AdmissionContext[20];
 
 static int seatRequest = 0;
 
 static GeneralAdmissionFactory generalAdmissionFactory;
 
 static void apply(int std, String admissionType){
  generalAdmissions[seatRequest] = generalAdmissionFactory.getGeneralAdmission(admissionType);
  admissionContexts[seatRequest++] = new AdmissionContext(std);
 }
 
 public static void main(String[] args) {
  generalAdmissionFactory = new GeneralAdmissionFactory();
  apply(2,"General");
  apply(5,"VIP");
  
  for(int i = 0;i<seatRequest;i++){
   generalAdmissions[i].admitStudent(admissionContexts[i]);
  }
  
  System.out.println("Total seat Requests = "+generalAdmissionFactory.getSeats());
 }
}

When to use Flightweight Pattern:
1. Use the Flightweight Pattern when one instance of a class can be used to provide many virtual instances.
2. Flightweight Pattern is used when a class has many instances, and they all can be controlled identically.

Benifits of Flightweight Pattern:
1. Reduces the number of object instances at runtime saving memory.
2. Centralizes state for many virtual objects into a single location.

Drawbacks of Flightweight Pattern:
1. Drawback is that once you implemented it, single logical instances of the class will not be able to behave independently from the other instances.

Related Patterns:
Abstract Factory,Singleton and Template Method patterns fall under this category.Flyweight pattern is often combined with the Composite Pattern to implement a logically hierarchical structure in terms of a directed-acyclic graph with shared lead nodes.Flyweight is a strategy in which you keep a pool of objects available and create references into the pool of objects for particular views.It uses the idea of canonical objects.A canonical object is a single representative object that represents all other objects for particular type.

Hope it will be useful...