Java Enterprise Edition (Java EE)

Wednesday 16th of April 2014 05:46:52 PM


  Toggle Advanced Options



WAR files

Directory structure

  • WebApplication root
    • META-INF
      • MANIFEST.MF
      • Container resources
    • WEB-INF
      • Classes
        • META-INF
          • Application resources
        • Java .class files and resources
      • i18n
        • Internationalization files
      • lib
        • Bundled JAR files
      • tags
        • JSP tag files
      • tld
        • JSP tag library descriptors
    • Other web-accessible files

The deployment descriptor (/WEB-INF/web.xml)

Empty web.xml file

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
        http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
        version="3.1">
    <display-name>Hello World Application</display-name>
</web-app>

Enterprise archives (EAR files)

Directory structure

  • EnterpriseApplication.ear
    • META-INF
      • application.xml
      • MANIFEST.MF
    • Module1.war
    • Module2.war
    • SharedClasses.jar
    • ThirdParty.jar

Web containers

Class loader architecture

  • Parent-first class loader delegation model
  • Parent-last class loader delegation model

Servlets

  • javax.servlet.GenericServlet.GenericServlet
  • javax.servlet.http.HttpServlet

HttpServlet provides all the tools you need to selectively accept and respond to different types of HTTP requests, and its methods accept javax.servlet.http.HttpServletRequest and javax.servlet.http.HttpServletResponse arguments.

Empty Implementations for HTTP Method Types

Method Servlet method Purpose
GET doGet() Retrieves the resource at the specified URL
HEAD doHead() Identical to GET, except only the headers are returned
POST doPost() Typically used for web form submission
PUT doPut() Stores the supplied entity at the URL
DELETE doDelete() Deletes the resource identified by the URL
OPTIONS doOptions() Returns which HTTP methods are allowed
TRACE dotrace() Used for diagnostic purposes

Canonical HttpServlet implementation

import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

public class HelloServlet extends HttpServlet {

    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response) 
            throws ServletException, IOException {
        response.getWriter().println("Hello, World!");
    }
}

HttpServletRequest

HttpServletResponse

Context init parameters

Servlet init parameters

Multithreading considerations

Requests, threads, and method execution

Generally speaking, web containers have a thread pool (often called either a connector pool or executor pool). When a container receives a request it obtains an available thread from the pool. If the thread pool has already allocated the maximum number of threads then the request enters a (FIFO) queue and waits for an available thread.

In a normal request, the thread and the request will be linked throughout the life of the request. Only when the request has completed and the content of your response has been written back to the client will the thread be returned to the pool to service another request.

Hence, numerous threads (up to maximum pool size - by default, 200 in Tomcat) could be executing the same method in your code on the same instance of that code simultaneously.

Protecting shared resources

Within a multithreaded application the access of shared resources is the most typical complication. Objects and variables created during the execution of a method are safe as long as the method is executing - other threads do not have access to them. However, static and instance variables could be accessed by multiple threads simultaneously.

The volatile keyword
Synchronized code blocks or methods

Putting actions within a synchronized block (that is, a synchronized statement) guarantees that no other thread can execute said code block at the same time; that is, the thread currently executing the block of code has exclusive access to execute the block until it completes.

Unlike synchronized methods, synchronized statements must specify the object that provides the intrinsic lock.

Special care should be taken when using synchronized code blocks or methods because the incorrect application of synchronization can result in starvation, livelock, or a deadlock.

JSPs

Filters

HTTP sessions

Session cookies

URL rewriting (session IDs in the URL)

WebSockets




Comments

Acknowledgement@14-04-11 10:47:15 by Brett Kromkamp

This page is based on the book Professional Java for Web Applications (WROX) by Nicholas S. Williams.






Google