The web.xml is the deployment descriptor for WAR file which is located in the WEB-INF directory of the web application. It is used to configure Servlet and other server side resources used in the web application. Each servlet must appear in a web.xml file , to add a servlet to an existing context, add a servlet and servlet-mapping element to the context.

<?xml version=”1.0″ encoding=”UTF-8″?>

<!DOCTYPE web-app

     PUBLIC “-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN”

     “http://java.sun.com/j2ee/dtds/web-app_2_4.dtd“>

 <web-app>

     <servlet>

         <servlet-name>HelloServlet</servlet-name>

         <servlet-class>com.demo.HelloServlet</servlet-class>

     </servlet>

      <servlet-mapping>

         <servlet-name>HelloServlet</servlet-name>

         <url-pattern>/HelloServlet</url-pattern>

     </servlet-mapping>

</web-app>

The first entry, under the root servlet element in web.xml, defines a name for the servlet and specifies the compiled class that executes the servlet. The servlet element also contains definitions for initialization attributes and security roles for the servlet.

The second entry in web.xml, under the servlet-mapping element, defines the URL pattern that calls this servlet.

Web Applications are packaged into Web ARchive (WAR) file. A web application exists as a structured hierarchy of directories. The root of this hierarchy serves as the document root for files that are part of the application. The top-level directory of a web application is the document root of the application. The document root is where JSP pages, client-side classes and archives, and static web resources, such as html pages and images, are stored.

The document root contains a subdirectory named WEB-INF, which contains the following files and directories:

• xml: The web application deployment descriptor
• classes: A directory that contains server-side classes: Servlets and other utility classes
• lib: A directory that contains JAR archives of libraries called by Servlets and other server side classes

If your web application does not contain any servlets, filter, or listener components then it does not need a web application deployment descriptor. In other words, if your web application only contains JSP pages and static files then you are not required to include a web.xml file. With Servlet 3.0 annotations, we can remove a lot of clutter from web.xml by configuring servlets, filters and listeners using annotations.

The ServletContext interface defines a servlet’s view of the Web application within which the servlet is running. Using the ServletContext object, a servlet can log events, obtain URL references to resources, and set and store attributes that other servlets in the context can access.

A ServletContext is rooted at a known path within a Web server. For example, a servlet context could be located at http://www.example.com/demos. All requests that begin with the /demos request path, known as the context path, are routed to the web application associated with the ServletContext.

When the servlet container determines that a servlet should be removed from service, it calls the destroy() method of the Servlet interface to allow the servlet to release any resources it is using and save any persistent state. For example, the container may do this when it wants to conserve memory resources, or when it is being shut down.

Before the servlet container calls the destroy method, it allows any threads that are currently running in the service method of the servlet to complete execution. Once the destroy method is called on a servlet instance, the instance is no longer available for servicing any requests. If the container needs to enable the servlet again, it must do so with a new instance of the servlet’s class.

After the destroy method completes, the servlet container must release the servlet instance so that it is eligible for garbage collection.

A Servlet is managed  through a well-defined life cycle that defines how it is loaded and instantiated, is initialized, handles requests from clients, and is taken out of service. This life cycle is expressed in the Servlet API by the init, service, and destroy methods of the javax.servlet.Servlet interface.

• • Loading and Instantiation – The servlet container is responsible for loading and instantiating servlets. The servlet container loads the servlet class using normal Java class loading facilities. The loading may happen when the servlet engine itself is started, or later when a client request is actually delegated to the servlet. After loading the Servlet class, the container instantiates it for use.

• • Initialization – After the servlet object is instantiated, the container will initialize the servlet before it can handle requests from clients. The container initializes the servlet instance by calling the init() method of the Servlet interface with a unique (per servlet declaration) object implementing the ServletConfig interface. In the init() method, the servlet can read configuration parameters using ServletConfig interface from the deployment descriptor or perform any other one-time activities, so the init() method is invoked once and only once by the servlet container.

• • Request Handling – After a servlet is properly initialized, the servlet container may use it to handle client requests using the service() method of the Servlet interface. Requests are represented by request objects of type ServletRequest. The servlet fills out response to requests by calling methods of a provided object of type ServletResponse. These objects are passed as parameters to the service() method of the Servlet interface. In the case of an HTTP request, the objects  are of types HttpServletRequest and HttpServletResponse.

End of Service – When the servlet container determines that a servlet should be removed from service, it calls the destroy() method of the Servlet interface to allow the servlet to release any resources it is using and save any persistent state.

Consider the following text in JSON file emp.json for reading:

{

“empname”:”James”,

“age”: 25,

“location”:”Bangalore”,

“skills”:[“Java”, “Spring”, “Hibernate”, “WebServices”]

}

To read this file in Java, first JSON.simple API and parsers have to be installed. The following Java code will read the content from JSON file and display appropriately.

public class JsonExample {

public static void main(String[] args) {

// Parser from JSON.simple

JSONParser parser = new JSONParser();

try {

Object obj = parser.parse(new FileReader("c:\\Users\\username\\Desktop\\emp.json"));

// JSONObject - API from JSON.simple

JSONObject jsonObject = (JSONObject) obj;

String empname = (String)jsonObject.get("empname");

System.out.println(empname);

long age = (Long) jsonObject.get("age");

System.out.println(age);

String location = (String) jsonObject.get("location");

System.out.println(location);

// JSONArray - API for array

JSONArray skills = (JSONArray) jsonObject.get("skills");

Iterator<String> iterator = skills.iterator();

while (iterator.hasNext()) {

System.out.println(iterator.next());

}

} catch (FileNotFoundException e) { e.printStackTrace(); }

catch (IOException e) { e.printStackTrace(); }

catch (ParseException e) { e.printStackTrace(); }

}

}

There are many parsers (open source) available for processing JSON in Java. Other than the Java API for JSON Processing, some of the popular ones are:

• Google Gson – Google Parser for JSON, simple and powerful
• Jackson JSON Parser – A high performance JSON processor
• Jettison – A JSON StAX Implementation
• simple –  Simple Java library for JSON, to read and write JSON data (from org.json).

There are two programming models which are used for parsing and generating JSON data in Java EE. They are:

1. Object model – The object model creates a tree that represents the JSON data in memory. The tree can then be navigated, analyzed, or modified. This approach is the most flexible and allows for processing that requires access to the complete contents of the tree. However, it is often slower than the streaming model and requires more memory. The object model generates JSON output by navigating the entire tree at once.

2. Streaming model – The streaming model uses an event-based parser that reads JSON data one element at a time. The parser generates events and stops for processing when an object or an array begins or ends, when it finds a key, or when it finds a value. Each element can be processed or discarded by the application code, and then the parser proceeds to the next event. The streaming model generates JSON output to a given stream by making a function call with one element at a time.

Java EE includes support for JSR 353 (Java API for JSON Processing), which provides an API to parse, transform, and query JSON data using two programming models – Object model and Streaming model. The Java API for JSON Processing contains the following packages which is used to parse, transform and query JSON data.

1. The javax.json package contains a reader interface (JsonReader), a writer interface (JsonWriter), and a model builder interface (JsonObjectBuilder) for the object model. This package also contains other utility classes and Java types for JSON elements.

2. The javax.json.stream package contains a parser interface (JsonParser) which represents an event based parser that can read JSON data from a stream model or from an object model and a generator interface (JsonGenerator) which can write JSON data to a stream one element at a  time.

JSON-RPC is a simple RPC protocol built on JSON, as a replacement for XML-RPC or SOAP. It is a simple protocol that defines only a handful of data types and commands. There is a Java implementation of this protocol and it is referred as JSON-RPC-Java.