directives

JSP Directives control the processing of an entire page. Directive examples include setting a scripting language, setting an error page, including other sections, and setting a character encoding.

JSP Directives

<%@ page language="lang" %>

Sets the JSP script language to lang. Defaults to Java. All JSP 1.0 implementations must support Java. Some implementations, like Resin, may support other scripting languages, e.g. JavaScript.

<%@ page import="package" %>

Adds to the Java package import list for the generated Java file.

Note

Only relevant when using Java.

<%@ page errorPage="path" %>

Defines a page to display if an error occurs in the JSP page.

Robust applications can return informative error pages when something goes wrong in a file, for example if a database is overloaded. path is returned as the response file. The error page can use the additional implicit variable exception containing the thrown exception.

path is relative to the current page. Its root is relative to the application root.

The error page itself can be a JSP page. If the error page is a JSP page, it can use the implicit variable exception to get information about the thrown exception.

<%@ page isErrorPage="true" %>

Gives an error page access to the exception implicit variable. Default to false.

errorpage.jsp

          &lt%@ page isErrorPage="true" %>
          <h1>Received error <%= exception.message %></h1>

<%@ include file="path" %>

Includes the raw file path at translation time.

The include directive is a replacement for an SSI include (or the C '#include'). It includes the contents of the file at path into the JSP file. The included file is parsed as JSP, so it can have active elements like expressions, declarations and scriptlets.

path is relative to the current page, and its root is the application root.

header.jsp

          <html><head>
          <title>&lt%= title %></title>
          </head>
          <body color=white>

page.jsp

          <% var title = "Hello, World"; %>
          <%@ include file='header.jsp' %>

          <h1><%= title %></h1>

<%@ page buffer=sizekb %>

Gives the size of the page buffer in kb or none for no buffer. Default 8kb. If buffer is none, all output is immediately flushed.

JSP 1.0 gives page writers flexibility by buffering its output before sending the response to HTTP. The buffering allows error recovery and forwarding, even after generating some content. Once the buffer has filled, it will be flushed. So applications must still detect their errors early.

The following example generates an XML section (for variety). If the form's query is missing the 'name' parameter, it will redirect the results.

          <?xml version='1.0'?>
          <form>
          <%
          if (request.form["name"] == null)
          pageContext.forward("redo-form.jsp");

          for (var name in request.form) {
          out.print("<" + name + ">");
          out.print(request.form[name]);
          out.println("</" + name + ">");
          }
          %>
          </form>

<%@ page autoFlush="true" %>

Tells JSP to flush the page buffer when it fills. Default is true.

If autoFlush is false, the JSP engine will throw an exception if the buffer overflows.

<%@ page session="true" %>

Tells JSP that the page participates in a session. Defaults to true.

The session declaration makes the session implicit variable available to a JSP page.

If the page doesn't use sessions, it should set session to false.

          <%@ page session="true" %>
          <% 
          session.value.count++;
          %>
          <h1>Welcome, visitor <%= count %></h1;>

<%@ page isThreadSafe="true" %>

Tells the JSP that multiple pages can execute in parallel. Defaults to true.

JSP pages are always responsible for synchronization of shared variables, such as the session and application variables. In some rare cases, a page may use servlet variables (created with a declaration), and be too lazy to handle the synchronization.

Even with isThreadSafe=false, the JSP engine may create multiple instances of the JSP servlet. So the page author can never absolve herself of synchronization issues.

In the following example, a JSP engine might create 3 servlet instances of the page. So three calls to the same page may return counts of 17, 3 and 398. In addition, the JSP engine is free to destroy and recreate the servlet at any time, essentially resetting the counter to 0.

          <%@ page isThreadSafe="false" %>
          <%! var count = 0; %>
          <h1>Welcome, visitor <%= count++ %>

<%@ page info="description" %>

Gives a brief description for the page.

<%@ page contentType="description" %>

Sets the content type and character encoding of the page.

contentType can also set the character encoding, for example to utf-8.

          <%@ page contentType="text/plain; charset=utf-8" %>
          <%! var count = 0; %>
          <h1>Welcome, visitor <%= count++ %>

<%@ page extends="Java class" %>

Changes the generated servlet's class.

In general, a filter is a better solution than using the extends directive.

<%@ taglib prefix="x" uri="foo" %>

Configures tags with prefix x to use the tag library foo.

          <%@ taglib prefix='x' uri='http://www.caucho.com/mytag/test' %>
          <x:mytag/>

Copyright © 1998-2015 Caucho Technology, Inc. All rights reserved. Resin ^® is a registered trademark. Quercus^tm, and Hessian^tm are trademarks of Caucho Technology.

Cloud-optimized Resin Server is a Java EE certified Java Application Server, and Web Server, and Distributed Cache Server (Memcached).
Leading companies worldwide with demand for reliability and high performance web applications including SalesForce.com, CNET, DZone and many more are powered by Resin.

home company docs
app server

Resin Documentation