JSP.3.2 JSP Page Implementation Class

The JSP container creates a JSP page implementation class for each JSP page. The name of the JSP page implementation class is implementation dependent.

The creation of the implementation class for a JSP page may be done solely by the JSP container, or it may involve a superclass provided by the JSP page author through the use of the extends attribute in the jsp directive. The extends mechanism is available for sophisticated users and it should be used with extreme care as it restricts some of the decisions that a JSP container can take, e.g., to improve performance.

The JSP page implementation class will implement Servlet and the Servlet protocol will be used to deliver requests to the class.

A JSP page implementation class may depend on some support classes; if it does, and the JSP page implementation class is packaged into a WAR, those classes will have to be included in the packaged WAR so that it will be portable across all JSP containers.

A JSP page author writes a JSP page expecting that the client and the server will communicate using a certain protocol. The JSP container must then guarantee that requests from and responses to the page use that protocol. Most JSP pages use HTTP, and their implementation classes must implement the HttpJspPage interface, which extends JspPage . If the protocol is not HTTP, then the class will implement an interface that extends JspPage .

JSP.3.2.1 API Contracts

The contract between the JSP container and a Java class implementing a JSP page corresponds to the Servlet interface; refer to the servlet specification for details.

The contract between the JSP container and the JSP page author is described in Table JSP.3-1. The responsibility for adhering to this contract rests only on the JSP container implementation if the JSP page does not use the extends attribute of the jsp directive; otherwise , the JSP page author guarantees that the superclass given in the extends attribute supports this contract.

Table JSP.3-1. How the JSP Container Processes JSP Pages

Comments	Methods the JSP Container Invokes
Method is optionally defined in JSP page. Method is invoked when the JSP page is initialized . When method is called, all the methods in servlet, including getServletConfig() , are available.	void jspInit ()
Method is optionally defined in JSP page. Method is invoked before destroying the page.	void jspDestroy ()
Method may not be defined in JSP page. The JSP container automatically generates this method, based on the contents of the JSP page. Method invoked at each client request.	void _ jspService (<ServletRequestSubtype>, <ServletResponseSubtype>) throws IOException, ServletException

JSP.3.2.2 Request and Response Parameters

As shown in Table JSP.3-1, the methods in the contract between the JSP container and the JSP page require request and response parameters.

The formal type of the request parameter (which this specification calls <ServletRequestSubtype> ) is an interface that extends javax.servlet.ServletRequest . The interface must define a protocol-dependent request contract between the JSP container and the class that implements the JSP page.

Likewise, the formal type of the response parameter (which this specification calls <ServletResponseSubtype> ) is an interface that extends javax.servlet.ServletResponse . The interface must define a protocol-dependent response contract between the JSP container and the class that implements the JSP page.

The request and response interfaces together describe a protocol-dependent contract between the JSP container and the class that implements the JSP page. The contract for HTTP is defined by the javax.servlet.http.HttpServletRequest and javax.servlet.http.HttpServletResponse interfaces.

The JspPage interface refers to these methods but cannot describe syntactically the methods involving the Servlet(Request,Response) subtypes . However, interfaces for specific protocols that extend JspPage can, just as HttpJspPage describes them for the HTTP protocol.

Note

JSP containers that conform to this specification (in both JSP page implementation classes and JSP container runtime) must implement the request and response interfaces for the HTTP protocol as described in this section.

JSP.3.2.3 Omitting the extends Attribute

If the extends attribute of the language directive (see Section JSP.2.7.1, "The page Directive") in a JSP page is not used, the JSP container can generate any class that satisfies the contract described in Table JSP.3-1 when it transforms the JSP page.

In the following code examples, Code Example JSP.3-1 illustrates a generic HTTP superclass named ExampleHttpSuper . Code Example JSP.3-2 shows a subclass named _ jsp1344 that extends ExampleHttpSuper and is the class generated from the JSP page. By using separate _jsp1344 and ExampleHttpSuper classes, the JSP page translator need not discover if the JSP page includes a declaration with jspInit() or jspDestroy(); this simplifies the implementation very significantly.

Code Example 3.2 A Generic HTTP Superclass

 imports javax.servlet.*;  imports javax.servlet.http.*;  imports javax.servlet.jsp.*;  /**   * An example of a superclass for an HTTP JSP class   */  abstract class ExampleHttpSuper implements HttpJspPage {      private ServletConfig config;  final public void init(ServletConfig config) throws ServletException {      this.config = config;       jspInit();  }  final public ServletConfig getServletConfig() {      return config;  }  // This one is not final so it can be overridden  // by a more precise method  public String getServletInfo() {      return "A Superclass for an HTTP JSP"; // maybe better?  }  final public void destroy() {      jspDestroy();  }  /**  * The entry point into service.  */  final public void service(ServletRequest req, ServletResponse res)       throws ServletException, IOException {      // casting exceptions will be raised if an internal error.       HttpServletRequest request = (HttpServletRequest) req;       HttpServletResponse response = (HttpServletResponse) res;       _jspService(request, response);  /**  * abstract method to be provided by the JSP processor in the subclass  * Must be defined in subclass.  */  abstract public void _jspService(HttpServletRequest request,       HttpServletResponse response) throws ServletException, IOException;  } 

Code Example 3.3 The Java Class Generated from a JSP Page

 imports javax.servlet.*;  imports javax.servlet.http.*;  imports javax.servlet.jsp.*;  /**   * An example of a class generated for a JSP.   *   * The name of the class is unpredictable.   * We are assuming that this is an HTTP JSP page   * (like almost all are)   */  class _jsp1344 extends ExampleHttpSuper { // Next code inserted directly via declarations.  // Any of the following pieces may or not be present  // if they are not defined here the superclass methods  // will be used.       public void jspInit() {....}       public void jspDestroy() {....}       // The next method is generated automatically by the       // JSP processor.       // body of JSP page       public void _jspService(HttpServletRequest request,            HttpServletResponse response)            throws ServletException, IOException {           // initialization of the implicit variables            HttpSession session = request.getSession();            ServletContext context =                 getServletConfig().getServletContext();            // for this example, we assume a buffered directive            JSPBufferedWriter out = new                 JSPBufferedWriter(response.getWriter());            // next is code from scriptlets, expressions,            // and static text.       }  } 

JSP.3.2.4 Using the extends Attribute

If the JSP page author uses extends , the generated class is identical to the one shown in code example JSP.3-2, except that the class name is the one specified in the extends attribute.

The contract on the JSP page implementation class does not change. The JSP container should check (usually through reflection) that the provided superclass:

• Implements HttpJspPage if the protocol is HTTP, or JspPage otherwise.

• All of the methods in the Servlet interface are declared final.

Additionally, it is the responsibility of the JSP page author that the provided superclass satisfies:

• The service() method of the servlet API invokes the _jspService () method.

• The init(ServletConfig) method stores the configuration, makes it available as getServletConfig , then invokes jspInit .

• The destroy method invokes jspDestroy .

A JSP container may give a fatal translation error if it detects that the provided superclass does not satisfy these requirements, but most JSP containers will not check them.