GTM

miércoles, 23 de enero de 2013

Servlet


1. Introduction

If you've ever used a Web search engine, visited an on-line bookstore, tracked stocks on-line, or asked a Web-based site for quotes on plane tickets, you've probably seen funny looking URLs likehttp://host/path?user=Marty+Hall&origin=bwi&dest=lax. The part after the question mark (i.e. user=Marty+Hall&origin=bwi&dest=lax) is known as form data, and is the most common way to get data from a Web page to a server-side program. It can be attached to the end of the URL after a question mark (as above), for GET requests, or sent to the server on a separate line, for POSTrequests.Extracting the needed information from this form data is traditionally one of the most tedious parts of CGI programming. First of all, you have to read the data one way for GET requests (in traditional CGI, this is usually via the QUERY_STRING environment variable), and another way for POST requests (usually by reading the standard input). Second, you have to chop the pairs at the ampersands, then separate the parameter names (left of the equals signs) from the parameter values (right of the equals signs). Third, you have to URL-decode the values. Alphanumeric characters get sent unchanged, but spaces get converted to plus signs and other characters get converted to %XX where XX is the ASCII (or ISO Latin-1) value of the character, in hex. For example, if someone entered a value of "~hall, ~gates, and ~mcnealy" into a textfield with the name "users" in an HTML form, the data would get sent as "users=%7Ehall%2C+%7Egates%2C+and+%7Emcnealy". Finally, the fourth reason that parsing form data is tedious is that values can be omitted (e.g. param1=val1&param2=&param3=val3) and a parameter can have more than one value in that the same parameter can appear more than once (e.g.param1=val1&param2=val2&param1=val3).
One of the nice features of Java servlets is that all of this form parsing is handled automatically. You simply call the getParameter method of the HttpServletRequest, supplying the parameter name as an argument. Note that parameter names are case sensitive. You do this exactly the same way when the data is sent via GET as you do when it is sent via POST. The return value is a String corresponding to the uudecoded value of the first occurrence of that parameter name. An empty String is returned if the parameter exists but has no value, and null is returned if there was no such parameter. If the parameter could potentially have more than one value, as in the example above, you should call getParameterValues instead of getParameter. This returns an array of strings. Finally, although in real applications your servlets probably have a specific set of parameter names they are looking for, for debugging purposes it is sometimes useful to get a full list. Use getParameterNames for this, which returns anEnumeration, each entry of which can be cast to a String and used in a getParameter call.

2. Example: Reading Three Parameters

Here's a simple example that reads parameters named param1param2, and param3, listing their values in a bulleted list. Note that, although you are required to specify response settings (content type, status line, other HTTP headings) before beginning to generate the content, there is no requirement that you read the request parameters at any particular time.Also note you can easily make servlets that can handle both GET and POST data, simply by having its doPost method call doGet or by overriding service (which calls doGetdoPostdoHead, etc.). This is good standard practice, since it requires very little extra work and permits flexibility on the part of the client. If you're used to the traditional CGI approach where you read POST data via the standard input, you should note that there is a similar way with servlets by first calling getReader or getInputStream on the HttpServletRequest. This is a bad idea for regular parameters, but might be of use for uploaded files or POST data being sent by custom clients rather than via HTML forms. Note, however, that if you read the POST data in that manner, it might no longer be found by getParameter.

2.1 ThreeParams.java

You can also download the source or try it on-line. Note: also uses ServletUtilities.java, shown earlier.
package hall;

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
import java.util.*;

public class ThreeParams extends HttpServlet {
  public void doGet(HttpServletRequest request,
                    HttpServletResponse response)
      throws ServletException, IOException {
    response.setContentType("text/html");
    PrintWriter out = response.getWriter();
    String title = "Reading Three Request Parameters";
    out.println(ServletUtilities.headWithTitle(title) +
                "<BODY>\n" +
                "<H1 ALIGN=CENTER>" + title + "</H1>\n" +
                "<UL>\n" +
                "  <LI>param1: "
                + request.getParameter("param1") + "\n" +
                "  <LI>param2: "
                + request.getParameter("param2") + "\n" +
                "  <LI>param3: "
                + request.getParameter("param3") + "\n" +
                "</UL>\n" +
                "</BODY></HTML>");
  }

  public void doPost(HttpServletRequest request,
                     HttpServletResponse response)
      throws ServletException, IOException {
    doGet(request, response);
  }
}

2.2 ThreeParams Output

Servlet Reading Three Parameters

3. Example: Listing All Form Data

Here's an example that looks up all the parameter names that were sent and puts them in a table. It highlights parameters that have zero values as well as ones that have multiple values. First, it looks up all the parameter names via the getParameterNames method of HttpServletRequest. This returns an Enumeration. Next, it loops down the Enumeration in the standard manner, using hasMoreElements to determine when to stop and using nextElement to get each entry. Since nextElement returns an Object, it casts the result to a String and passes that to getParameterValues, yielding an array ofStrings. If that array is one entry long and contains only an empty string, then the parameter had no values, and the servlet generates an italicized "No Value" entry. If the array is more than one entry long, then the parameter had multiple values, and they are displayed in a bulleted list. Otherwise the one main value is just placed into the table.

3.1 ShowParameters.java

You can also download the source or try it on-line. Note: also uses ServletUtilities.java, shown earlier.
package hall;

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
import java.util.*;

/** Shows all the parameters sent to the servlet via either
 *  GET or POST. Specially marks parameters that have no values or
 *  multiple values.
 *  
 *  Part of tutorial on servlets and JSP that appears at
 *  http://www.apl.jhu.edu/~hall/java/Servlet-Tutorial/
 *  1999 Marty Hall; may be freely used or adapted.
 */

public class ShowParameters extends HttpServlet {
  public void doGet(HttpServletRequest request,
                    HttpServletResponse response)
      throws ServletException, IOException {
    response.setContentType("text/html");
    PrintWriter out = response.getWriter();
    String title = "Reading All Request Parameters";
    out.println(ServletUtilities.headWithTitle(title) +
                "<BODY BGCOLOR=\"#FDF5E6\">\n" +
                "<H1 ALIGN=CENTER>" + title + "</H1>\n" +
                "<TABLE BORDER=1 ALIGN=CENTER>\n" +
                "<TR BGCOLOR=\"#FFAD00\">\n" +
                "<TH>Parameter Name<TH>Parameter Value(s)");
    Enumeration paramNames = request.getParameterNames();
    while(paramNames.hasMoreElements()) {
      String paramName = (String)paramNames.nextElement();
      out.println("<TR><TD>" + paramName + "\n<TD>");
      String[] paramValues = request.getParameterValues(paramName);
      if (paramValues.length == 1) {
        String paramValue = paramValues[0];
        if (paramValue.length() == 0)
          out.print("<I>No Value</I>");
        else
          out.print(paramValue);
      } else {
        out.println("<UL>");
        for(int i=0; i<paramValues.length; i++) {
          out.println("<LI>" + paramValues[i]);
        }
        out.println("</UL>");
      }
    }
    out.println("</TABLE>\n</BODY></HTML>");
  }

  public void doPost(HttpServletRequest request,
                     HttpServletResponse response)
      throws ServletException, IOException {
    doGet(request, response);
  }
}

3.2 Front End to ShowParameters

Here's an HTML form that sends a number of parameters to this servlet. Right click on the source code link to download the HTML. Left click on the link to try it out on-line. It uses POST to send the data (as should all forms that have PASSWORD entries), demonstrating the value of having servlets include both a doGet and a doPost. However, just for the sake of illustration, a version using GET can also be downloaded or tried out on-line.

PostForm.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
  <TITLE>A Sample FORM using POST</TITLE>
</HEAD>

<BODY BGCOLOR="#FDF5E6">
<H1 ALIGN="CENTER">A Sample FORM using POST</H1>

<FORM ACTION="/servlet/hall.ShowParameters"
      METHOD="POST">
  Item Number:
  <INPUT TYPE="TEXT" NAME="itemNum"><BR>
  Quantity:
  <INPUT TYPE="TEXT" NAME="quantity"><BR>
  Price Each:
  <INPUT TYPE="TEXT" NAME="price" VALUE="$"><BR>
  <HR>
  First Name:
  <INPUT TYPE="TEXT" NAME="firstName"><BR>
  Last Name:
  <INPUT TYPE="TEXT" NAME="lastName"><BR>
  Middle Initial:
  <INPUT TYPE="TEXT" NAME="initial"><BR>
  Shipping Address:
  <TEXTAREA NAME="address" ROWS=3 COLS=40></TEXTAREA><BR>
  Credit Card:<BR>
    <INPUT TYPE="RADIO" NAME="cardType"
                     VALUE="Visa">Visa<BR>
    <INPUT TYPE="RADIO" NAME="cardType"
                     VALUE="Master Card">Master Card<BR>
    <INPUT TYPE="RADIO" NAME="cardType"
                     VALUE="Amex">American Express<BR>
    <INPUT TYPE="RADIO" NAME="cardType"
                     VALUE="Discover">Discover<BR>
    <INPUT TYPE="RADIO" NAME="cardType"
                     VALUE="Java SmartCard">Java SmartCard<BR>
  Credit Card Number:
  <INPUT TYPE="PASSWORD" NAME="cardNum"><BR>
  Repeat Credit Card Number:
  <INPUT TYPE="PASSWORD" NAME="cardNum"><BR><BR>
  <CENTER>
    <INPUT TYPE="SUBMIT" VALUE="Submit Order">
  </CENTER>
</FORM>

</BODY>
</HTML>
Front End to ShowParameters Servlet

3.3 Submission Result

Result of Sending Data to ShowParameters

martes, 22 de enero de 2013

What is the web.xml ?


All you need to know about web.xml is here !!!!!!!


A web.xml Deployment Descriptor Elements

The following sections describe the deployment descriptor elements defined in the web.xml schema under the root element <web-app>.
With Java EE annotations, the standard web.xml deployment descriptor is optional. According to the Servlet 2.5 specification, athttp://java.sun.com/products/servlet/index.jsp annotations can be defined on certain Web components, such as servlets, filters, listeners, and tag handlers. The annotations are used to declare dependencies on external resources. See Chapter 8, "WebLogic Annotation for Web Components".

web.xml Namespace Declaration and Schema Location

The correct text for the namespace declaration and schema location for the web.xml file is as follows.
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" 
id="WebApp_ID" version="2.5">
To view the schema for web.xml, go to http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd.

icon

The icon element specifies the location within the Web application for a small and large image used to represent the Web application in a GUI tool. (The servletelement also has an element called the icon element, used to supply an icon to represent a servlet in a GUI tool.)
The following table describes the elements you can define within an icon element.
Table A-1 Icon Elements
ElementRequired/ OptionalDescription
<small-icon>
OptionalLocation for a small (16x16 pixel) .gif or .jpg image used to represent the Web application in a GUI tool. Currently, this is not used by WebLogic Server.
<large-icon>
OptionalLocation for a large (32x32 pixel) .gif or .jpg image used to represent the Web application in a GUI tool. Currently, this element is not used by WebLogic Server.

display-name

The optional display-name element specifies the Web application display name, a short name that can be displayed by GUI tools.
Table A-2 display-name Elements
ElementRequired/ OptionalDescription
<display-name>
OptionalCurrently, this element is not used by WebLogic Server.

description

The optional description element provides descriptive text about the Web application.
Table A-3 description Elements
ElementRequired/ OptionalDescription
<description>
OptionalCurrently, this element is not used by WebLogic Server.

distributable

The distributable element is not used by WebLogic Server.
Table A-4 description Elements
ElementRequired/ OptionalDescription
<distributable>
OptionalCurrently, this element is not used by WebLogic Server.

context-param

The optional context-param element contains the declaration of a Web application's servlet context initialization parameters.
Table A-5 context-parameter Elements
ElementRequired/OptionalDescription
weblogic.httpd.
clientCertProxy
optionalThis attribute specifies that certifications from clients of the Web application are provided in the special WL-Proxy-Client-Cert header sent by a proxy plug-in or HttpClusterServlet.
This setting is useful if user authentication is performed on a proxy server—settingclientCertProxy causes the proxy server to pass on the certs to the cluster in a special header,WL-Proxy-Client-Cert.
WL-Proxy-Client-Cert header could be provided by any client with access to WebLogic Server. WebLogic Server takes the certificate information from that header, trusting that is came from a secure source (the plug-in) and uses that information to authenticate the user.
For this reason, if you set clientCertProxy, use a connection filter to ensure that WebLogic Server accepts connections only from the machine on which the plug-in is running.
In addition to setting this attribute for an individual Web application, you can define this attribute:
For all Web applications hosted by a server instance, on the Server-->Configuration-->General page in the Administration Console. For all Web applications hosted by server instances in a cluster, on the Cluster-->Configuration-->General page.
The following table describes the reserved context parameters used by the Web application container, which have been deprecated and have replacements in weblogic.xml.
Table A-6 Deprecated context-param Elements
Deprecated ParameterDescriptionReplacement Element in weblogic.xml
weblogic.httpd.inputCharsetDefines code set behavior for non-unicode operations.input-charset (defined within charset-param) in weblogic.xml. See input-charset.
weblogic.httpd.servlet.reloadCheckSecsDefine how often WebLogic Server checks whether a servlet has been modified, and if so, reloads it. A value of -1 is never reload, 0 is always reload. The default is set to 1 second.servlet-reload-check-secs(defined withincontainer-descriptorin weblogic.xml.See auth-filter.
weblogic.httpd.servlet.classpathWhen this values has been set, the container appends this path to the Web application classpath. This is not a recommended method and is supported only for backward compatibility.No replacement. Use other means such as manifest classpath or WEB-INF/lib or WEB-INF/classes or virtual directories.
weblogic.httpd.defaultServletSets the default servlet for the Web application. This is not a recommended
method and is supported only for backward compatibility.
No replacement. Instead use the servlet andservlet-mapping elements in web.xml to define a default servlet. The URL pattern fordefault-servlet should be "/". See servlet-mapping. For additional examples of servlet mapping, see Servlet Mapping.

filter

The filter element defines a filter class and its initialization attributes. For more information on filters, see Configuring Filters.
The following table describes the elements you can define within a filter element.
Table A-7 filter Elements
ElementRequired/OptionalDescription
<icon>
OptionalSpecifies the location within the Web application for a small and large image used to represent the filter in a GUI tool. Contains a small-icon and large-icon element.
Currently, this element is not used by WebLogic Server.
<filter-name>
RequiredDefines the name of the filter, used to reference the filter definition elsewhere in the deployment descriptor.
<display-name>
OptionalA short name intended to be displayed by GUI tools.
<description>
OptionalA text description of the filter.
<filter-class>
RequiredThe fully-qualified class name of the filter.
<init-param>
OptionalContains a name/value pair as an initialization attribute of the filter.
Use a separate set of <init-param> tags for each attribute.

filter-mapping

The following table describes the elements you can define within a filter-mapping element.
Table A-8 filter-mapping Elements
ElementRequired/OptionalDescription
<filter-name>
RequiredThe name of the filter to which you are mapping a URL pattern or servlet. This name corresponds to the name assigned in the <filter> element with the <filter-name> element.
<url-pattern>
Required - or map by<servlet>Describes a pattern used to resolve URLs. The portion of the URL after the http://host:port +ContextPath is compared to the <url-pattern> by WebLogic Server. If the patterns match, the filter mapped in this element is called.
Example patterns:
/soda/grape/*
/foo/* 
/contents
*.foo
The URL must follow the rules specified in the Servlet 2.3 Specification.
<servlet>Required - or map by<url-pattern>The name of a servlet which, if called, causes this filter to execute.

listener

Define an application listener using the listener element.
Table A-9 listener Elements
ElementRequired/OptionalDescription
<listener-class>
OptionalName of the class that responds to a Web application event.
For more information, see Configuring an Event Listener Class.

servlet

The servlet element contains the declarative data of a servlet.
If a jsp-file is specified and the <load-on-startup> element is present, then the JSP is precompiled and loaded when WebLogic Server starts.
The following table describes the elements you can define within a servlet element.
Table A-10 servlet Elements
ElementRequired/OptionalDescription
<icon>
OptionalLocation within the Web application for a small and large image used to represent the servlet in a GUI tool. Contains a small-icon and large-icon element.
Currently, this element is not used by WebLogic Server.
<servlet-name>
RequiredDefines the canonical name of the servlet, used to reference the servlet definition elsewhere in the deployment descriptor.
<display-name>
OptionalA short name intended to be displayed by GUI tools.
<description>
OptionalA text description of the servlet.
<servlet-class>
Required (or use<jsp-
file>)
The fully-qualified class name of the servlet.
Use only one of either the <servlet-class> tags or <jsp-file> tags in your servlet body.
<jsp-file>
Required (or use<servlet-
class>)
The full path to a JSP file within the Web application, relative to the Web application root directory.
Use only one of either the <servlet-class> tags or <jsp-file> tags in your servlet body.
<init-param>
OptionalContains a name/value pair as an initialization attribute of the servlet.
Use a separate set of <init-param> tags for each attribute.
<load-on-startup>
OptionalWebLogic Server initializes this servlet when WebLogic Server starts up. The optional content of this element must be a positive integer indicating the order in which the servlet should be loaded. Lower integers are loaded before higher integers. If no value is specified, or if the value specified is not a positive integer, WebLogic Server can load the servlet in any order during application startup.
<run-as>OptionalSpecifies the run-as identity to be used for the execution of the Web application. It contains an optional description and the name of a security role.
<security-role-
ref>
OptionalUsed to link a security role name defined by <security-role> to an alternative role name that is hard coded in the servlet logic. This extra layer of abstraction allows the servlet to be configured at deployment without changing servlet code.

icon

This is an element within the servlet.
The icon element specifies the location within the Web application for small and large images used to represent the servlet in a GUI tool.
The following table describes the elements you can define within an icon element.
Table A-11 icon Elements
ElementRequired/OptionalDescription
<small-icon>
OptionalSpecifies the location within the Web application for a small (16x16 pixel) .gif or .jpg image used to represent the servlet in a GUI tool.
Currently, this element is not used by WebLogic Server.
<large-icon>
OptionalSpecifies the location within the Web application for a small (32x32 pixel) .gif or.jpg image used to represent the servlet in a GUI tool.
Currently, this element is not used by WebLogic Server.

init-param

This is an element within the servlet.
The optional init-param element contains a name/value pair as an initialization attribute of the servlet. Use a separate set of init-param tags for each attribute.
You can access these attributes with the javax.servlet.ServletConfig.getInitParameter() method.
The following table describes the elements you can define within a init-param element.
Table A-12 init-param Elements
ElementRequired/OptionalDescription
<param-name>
RequiredDefines the name of this attribute.
<param-value>
RequiredDefines a String value for this attribute.
<description>
OptionalText description of the initialization attribute.

security-role-ref

This is an element within the servlet.
The security-role-ref element links a security role name defined by <security-role> to an alternative role name that is hard-coded in the servlet logic. This extra layer of abstraction allows the servlet to be configured at deployment without changing servlet code.
The following table describes the elements you can define within a security-role-ref element.
Table A-13 security-role-ref Elements
ElementRequired/OptionalDescription
<description>
OptionalText description of the role.
<role-name>
RequiredDefines the name of the security role or principal that is used in the servlet code.
<role-link>
RequiredDefines the name of the security role that is defined in a <security-role> element later in the deployment descriptor.

servlet-mapping

The servlet-mapping element defines a mapping between a servlet and a URL pattern.
The following table describes the elements you can define within a servlet-mapping element.
Table A-14 servlet-mapping Elements
ElementRequired/OptionalDescription
<servlet-name>
RequiredThe name of the servlet to which you are mapping a URL pattern. This name corresponds to the name you assigned a servlet in a <servlet> declaration tag.
<url-pattern>
RequiredDescribes a pattern used to resolve URLs. The portion of the URL after the http://host:port +WebAppName is compared to the <url-pattern> by WebLogic Server. If the patterns match, the servlet mapped in this element will be called.
Example patterns:
/soda/grape/*
/foo/* 
/contents
*.foo
The URL must follow the rules specified in the Servlet 2.3 Specification.
For additional examples of servlet mapping, see Servlet Mapping.

session-config

The session-config element defines the session attributes for this Web application.
The following table describes the element you can define within a session-config element.
Table A-15 session-config Elements
ElementRequired/OptionalDescription
<session-timeout>
OptionalThe number of minutes after which sessions in this Web application expire. The value set in this element overrides the value set in the TimeoutSecs attribute of the <session-descriptor>element in the WebLogic-specific deployment descriptor weblogic.xml, unless one of the special values listed here is entered.
Default value: 60
Maximum value: Integer.MAX_VALUE ÷ 60
Special values:
-1 = Sessions do not timeout. The value set in <session-descriptor> element of weblogic.xml is ignored.
For more information, see session-descriptor.

mime-mapping

The mime-mapping element defines a mapping between an extension and a mime type.
The following table describes the elements you can define within a mime-mapping element.
Table A-16 mime-mapping Elements
ElementRequired/OptionalDescription
<extension>
RequiredA string describing an extension, for example: txt.
<mime-type>
RequiredA string describing the defined mime type, for example: text/plain.

welcome-file-list

The optional welcome-file-list element contains an ordered list of welcome-file elements.
When the URL request is a directory name, WebLogic Server serves the first file specified in this element. If that file is not found, the server then tries the next file in the list.
For more information, see Configuring Welcome Files.
The following table describes the element you can define within a welcome-file-list element.
Table A-17 welcome-file-list
ElementRequired/OptionalDescription
<welcome-file>
OptionalFile name to use as a default welcome file, such as index.html

error-page

The optional error-page element specifies a mapping between an error code or exception type to the path of a resource in the Web application.
When an error occurs—while WebLogic Server is responding to an HTTP request, or as a result of a Java exception—WebLogic Server returns an HTML page that displays either the HTTP error code or a page containing the Java error message. You can define your own HTML page to be displayed in place of these default error pages or in response to a Java exception.
For more information, see Customizing HTTP Error Responses.
The following table describes the elements you can define within an error-page element.
Note:
Define either an <error-code> or an <exception-type> but not both.
Table A-18 error-page Elements
ElementRequired/OptionalDescription
<error-code>
OptionalA valid HTTP error code, for example, 404.
<exception-type>
OptionalA fully-qualified class name of a Java exception type, for example, java.lang.string
<location>
RequiredThe location of the resource to display in response to the error. For example, /myErrorPg.html.

jsp-config

The jsp-config element is used to provide global configuration information for the JSP files in a Web application. It has two sub-elements, taglib and jsp-property-group.
The following table describes the elements you can define within a jsp-config element.
Table A-19 jsp-config Elements
ElementRequired/OptionalDescription
<taglib>
OptionalProvides information on a tag library that is used by a JSP page within the Web application.
<jsp-property-group>
OptionalUsed to group a number of files so they can be given global property information. All files so described are deemed to be JSP files.

taglib

This is an element within the jsp-config.
The required taglib element provides information on a tag library that is used by a JSP page within the Web application.
This element associates the location of a JSP Tag Library Descriptor (TLD) with a URI pattern. Although you can specify a TLD in your JSP that is relative to theWEB-INF directory, you can also use the <taglib> tag to configure the TLD when deploying your Web application. Use a separate element for each TLD.
The following table describes the elements you can define within a taglib element.
Table A-20 taglib Elements
ElementRequired/OptionalDescription
<taglib-location>
OptionalGives the file name of the tag library descriptor relative to the root of the Web application. It is a good idea to store the tag library descriptor file under the WEB-INF directory so it is not publicly available over an HTTP request.
<taglib-uri>
OptionalDescribes a URI, relative to the location of the web.xml document, identifying a Tag Library used in the Web application.
If the URI matches the URI string used in the taglib directive on the JSP page, this taglib is used.

jsp-property-group

This is an element within the jsp-config.
The required jsp-property-group element is used to group a number of files so they can be given global property information. All files so described are deemed to be JSP files.
The following table describes the elements you can define within a jsp-property-group element.
Table A-21 jsp-property-group Elements
ElementRequired/OptionalDescription
<el-ignored>
OptionalControls whether EL is ignored. By default, the EL evaluation is enabled for Web applications using a Servlet 2.4 or greater web.xml, and disabled otherwise.
<scripting-invalid>
OptionalControls whether scripting elements are invalid in a group of JSP pages. By default, scripting is enabled.
<page-encoding>
OptionalIndicates pageEncoding information. It is a translation-time error to name different encodings in the pageEncoding attribute of the page directive of a JSP page and in a JSP configuration element matching the page. It is also a translation-time error to name different encodings in the prolog or text declaration of a document in XML syntax and in a JSP configuration element matching the document. It is legal to name the same encoding through multiple mechanisms.
<is-xml>
OptionalIndicates that a resource is a JSP document (XML). If true, denotes that the group of resources that match the URL pattern are JSP documents, and thus must be interpreted as XML documents. If false, the resources are assumed to not be JSP documents, unless there is another property group that indicates otherwise.
<include-prelude>
OptionalA context-relative path that must correspond to an element in the Web application. When the element is present, the given path will be automatically included (as in an include directive) at the beginning of each JSP page in this jsp-property-group.
<include-coda>
OptionalA context-relative path that must correspond to an element in the Web application. When the element is present, the given path will be automatically included (as in an include directive) at the end of each JSP page in this jsp-property-group.
<deferred-syntax-allowed-as-literal>
OptionalControls whether the character sequence #{ is allowed when used as a String literal.
<trim-directive-whitespaces>
OptionalControls whether template text containing only white spaces must be removed from the response output.
<url-pattern>
RequiredDescribes a pattern used to resolve URLs. The portion of the URL after thehttp://host:port + ContextPath is compared to the <url-pattern> by WebLogic Server.
Example patterns:
/soda/grape/*
/foo/* 
/contents
*.foo
The URL must follow the rules specified in the Servlet 2.4 Specification.

resource-env-ref

The resource-env-ref element contains a declaration of a Web application's reference to an administered object associated with a resource in the Web application's environment. It consists of an optional description, the resource environment reference name, and an indication of the resource environment reference type expected by the Web application code.
For example:
<resource-env-ref>
    <resource-env-ref-name>jms/StockQueue</resource-env-ref-name>
    <resource-env-ref-type>javax.jms.Queue</resource-env-ref-type>
</resource-env-ref>
The following table describes the elements you can define within a resource-env-ref element.
Table A-22 resource-env-ref
ElementRequired/OptionalDescription
<description>
OptionalProvides a description of the resource environment reference.
<resource-env-ref-name>
RequiredSpecifies the name of a resource environment reference; its value is the environment entry name used in the Web application code. The name is a JNDI name relative to the java:comp/env context and must be unique within a Web application.
<resource-env-ref-type>
RequiredSpecifies the type of a resource environment reference. It is the fully qualified name of a Java language class or interface.

resource-ref

The optional resource-ref element defines a reference lookup name to an external resource. This allows the servlet code to look up a resource by a "virtual" name that is mapped to the actual location at deployment time.
Use a separate <resource-ref> element to define each external resource name. The external resource name is mapped to the actual location name of the resource at deployment time in the WebLogic-specific deployment descriptor weblogic.xml.
The following table describes the elements you can define within a resource-ref element.
Table A-23 resource-ref Elements
ElementRequired/OptionalDescription
<description>
OptionalA text description.
<res-ref-name>
RequiredThe name of the resource used in the JNDI tree. Servlets in the Web application use this name to look up a reference to the resource.
<res-type>
RequiredThe Java type of the resource that corresponds to the reference name. Use the full package name of the Java type.
<res-auth>
RequiredUsed to control the resource sign on for security.
If set to APPLICATION, indicates that the application component code performs resource sign on programmatically. If set to Container, WebLogic Server uses the security context established with the login-config element. See login-config.
<res-sharing-scope>
OptionalSpecifies whether connections obtained through the given resource manager connection factory reference can be shared.
Valid values:
Shareable
Unshareable

security-constraint

The security-constraint element defines the access privileges to a collection of resources defined by the <web-resource-collection> element.
For detailed instructions and an example on configuring security in Web applications, see Securing Resources Using Roles and Policies for Oracle WebLogic Server. Also, for more information on WebLogic Security, refer to Programming Security for Oracle WebLogic Server.
The following table describes the elements you can define within a security-constraint element.
Table A-24 security-constraint Elements
ElementRequired/OptionalDescription
<web-resource-
collection>
RequiredDefines the components of the Web application to which this security constraint is applied.
<auth-constraint>
OptionalDefines which groups or principals have access to the collection of Web resources defined in this security constraint. See also auth-constraint.
<user-data-
constraint>
OptionalDefines how the client should communicate with the server.
See also user-data-constraint

web-resource-collection

Each <security-constraint> element must have one or more <web-resource-collection> elements. These define the area of the Web application to which this security constraint is applied.
This is an element within the security-constraint.
The following table describes the elements you can define within a web-resource-collection element.
Table A-25 web-resource-collection Elements
ElementRequired/OptionalDescription
<web-resource-
name>
RequiredThe name of this Web resource collection.
<description>
OptionalA text description of this security constraint.
<url-pattern>
OptionalUse one or more of the <url-pattern> elements to declare to which URL patterns this security constraint applies. If you do not use at least one of these elements, this <web-resource-collection> is ignored by WebLogic Server.
<http-method>
OptionalUse one or more of the <http-method> elements to declare which HTTP methods (usually, GET orPOST) are subject to the authorization constraint. If you omit the <http-method> element, the default behavior is to apply the security constraint to all HTTP methods.

auth-constraint

This is an element within the security-constraint.
The optional auth-constraint element defines which groups or principals have access to the collection of Web resources defined in this security constraint.
The following table describes the elements you can define within an auth-constraint element.
Table A-26 auth-constraint Elements
ElementRequired/OptionalDescription
<description>
OptionalA text description of this security constraint.
<role-name>
OptionalDefines which security roles can access resources defined in this security-constraint. Security role names are mapped to principals using the security-role-ref.

user-data-constraint

This is an element within the security-constraint.
The user-data-constraint element defines how the client should communicate with the server.
The following table describes the elements you may define within a user-data-constraint element.
Table A-27 user-data-constraint Elements
ElementRequired/OptionalDescription
<description>
OptionalA text description.
<transport-
guarantee>
RequiredSpecifies that the communication between client and server.
WebLogic Server establishes a Secure Sockets Layer (SSL) connection when the user is authenticated using the INTEGRAL or CONFIDENTIAL transport guarantee.
Range of values:
NONE—The application does not require any transport guarantees.
INTEGRAL—The application requires that the data be sent between the client and server in such a way that it cannot be changed in transit.
CONFIDENTIAL—The application requires that data be transmitted so as to prevent other entities from observing the contents of the transmission.

login-config

Use the optional login-config element to configure how the user is authenticated; the realm name that should be used for this application; and the attributes that are needed by the form login mechanism.
If this element is present, the user must be authenticated in order to access any resource that is constrained by a <security-constraint> defined in the Web application. Once authenticated, the user can be authorized to access other resources with access privileges.
The following table describes the elements you can define within a login-config element.
Table A-28 config
ElementRequired/OptionalDescription
<auth-method>
OptionalSpecifies the method used to authenticate the user. Possible values:
BASIC—uses browser authentication. (This is the default value.)
FORM—uses a user-written HTML form.
CLIENT-CERT
You can define multiple authentication methods as a comma separated list to provide a fall-back mechanism. Authentication will be attempted in the order the values are defined in the auth-method list. See "Providing a Fallback Mechanism for Authentication Methods" in Programming Security for Oracle WebLogic Server.
<realm-name>
OptionalThe name of the realm that is referenced to authenticate the user credentials. If omitted, the realm defined with the Auth Realm Name field on the Web application > Configuration > Other tab of the Administration Console is used by default.
The <realm-name> element does not refer to system security realms within WebLogic Server. This element defines the realm name to use in HTTP Basic authorization. The system security realm is a collection of security information that is checked when certain operations are performed in the server. The servlet security realm is a different collection of security information that is checked when a page is accessed and basic authentication is used.
<form-login-
config>
OptionalUse this element if you configure the <auth-method> to FORM. See form-login-config.

form-login-config

This is an element within the login-config.
Use the <form-login-config> element if you configure the <auth-method> to FORM.
Table A-29 form-login-config Elements
ElementRequired/OptionalDescription
<form-login-page>
RequiredThe URI of a Web resource relative to the document root, used to authenticate the user. This can be an HTML page, JSP, or HTTP servlet, and must return an HTML page containing a FORM-based authentication that conforms to a specific naming convention.
<form-error-page>
RequiredThe URI of a Web resource relative to the document root, sent to the user in response to a failed authentication login.

security-role

The following table describes the elements you can define within a security-role element.
Table A-30 security-role Elements
ElementRequired/OptionalDescription
<description>
OptionalA text description of this security role.
<role-name>
RequiredThe role name. The name you use here must have a corresponding entry in the WebLogic-specific deployment descriptor, weblogic.xml, which maps roles to principals in the security realm. For more information, see security-role-assignment.

env-entry

The optional env-entry element declares an environment entry for an application. Use a separate element for each environment entry.
The following table describes the elements you can define within an env-entry element.
Table A-31 env-entry Elements
ElementRequired/OptionalDescription
<description>
OptionalA textual description.
<env-entry-name>
RequiredThe name of the environment entry.
<env-entry-value>
RequiredThe value of the environment entry.
<env-entry-type>
RequiredThe type of the environment entry.
Can be set to one of the following Java types:
java.lang.Boolean 
java.lang.String
java.lang.Integer 
java.lang.Double
java.lang.Float

ejb-ref

The optional ejb-ref element defines a reference to an EJB resource. This reference is mapped to the actual location of the EJB at deployment time by defining the mapping in the WebLogic-specific deployment descriptor file, weblogic.xml. Use a separate <ejb-ref> element to define each reference EJB name.
The following table describes the elements you can define within an ejb-ref element.
Table A-32 ejb-ref Elements
ElementRequired/OptionalDescription
<description>
OptionalA text description of the reference.
<ejb-ref-name>
RequiredThe name of the EJB used in the Web application. This name is mapped to the JNDI tree in the WebLogic-specific deployment descriptor weblogic.xml. For more information, see ejb-reference-description.
<ejb-ref-type>
RequiredThe expected Java class type of the referenced EJB.
<home>
RequiredThe fully qualified class name of the EJB home interface.
<remote>
RequiredThe fully qualified class name of the EJB remote interface.
<ejb-link>
OptionalThe <ejb-name> of an EJB in an encompassing J2EE application package.
<run-as>
OptionalA security role whose security context is applied to the referenced EJB. Must be a security role defined with the <security-role> element.

ejb-local-ref

The ejb-local-ref element is used for the declaration of a reference to an enterprise bean's local home. The declaration consists of:
  • An optional description
  • The EJB reference name used in the code of the Web application that references the enterprise bean. The expected type of the referenced enterprise bean
  • The expected local home and local interfaces of the referenced enterprise bean
  • Optional ejb-link information, used to specify the referenced enterprise bean
The following table describes the elements you can define within an ejb-local-ref element.
Table A-33 ejb-local-ref Elements
ElementRequired/OptionalDescription
<description>
OptionalA text description of the reference.
<ejb-ref-name>
RequiredContains the name of an EJB reference. The EJB reference is an entry in the Web application's environment and is relative to the java:comp/env context. The name must be unique within the Web application. It is recommended that name is prefixed with ejb/.
For example:
<ejb-ref-name>ejb/Payroll</ejb-ref-name>
<ejb-ref-type>
RequiredThe ejb-ref-type element contains the expected type of the referenced enterprise bean. The ejb-ref-type element must be one of the following:
<ejb-ref-type>Entity</ejb-ref-type>
<ejb-ref-type>Session</ejb-ref-type>
<local-home>
RequiredContains the fully-qualified name of the enterprise bean's local home interface.
<local>
RequiredContains the fully-qualified name of the enterprise bean's local interface.
<ejb-link>
OptionalThe ejb-link element is used in the ejb-ref or ejb-local-ref elements to specify that an EJB reference is linked to an EJB.
The name in the ejb-link element is composed of a path name. This path name specifies the ejb-jarcontaining the referenced EJB with the ejb-name of the target bean appended and separated from the path name by #.
The path name is relative to the WAR file containing the Web application that is referencing the EJB. This allows multiple EJBs with the same ejb-name to be uniquely identified.
Used in: ejb-local-ref and ejb-ref elements.
Examples:
<ejb-link>EmployeeRecord</ejb-link>
<ejb-link>../products/product.jar#ProductEJB</ejb-link>

web-app

The XML Schema for the Servlet 2.4 deployment descriptor. WebLogic Server fully supports HTTP servlets as defined athttp://java.sun.com/products/servlet/download.html#specs. However, the version attributed must be set to 2.4 in order to enforce 2.4 behavior.
The following table describes the elements you can define within an web-app element.
Table A-34 web-app Elements
ElementRequired/OptionalDescription
<version>
RequiredAll Servlet deployment descriptors must indicate the 2.4 version of the schema in order to enforce Servlet 2.4 behavior.