B weblogic.xml Deployment Descriptor Elements

This is a complete reference for the elements in the WebLogic Server-specific deployment descriptor weblogic.xml. If your Web application does not contain a weblogic.xml deployment descriptor, WebLogic Server automatically selects the default values of the deployment descriptor elements.

This appendix includes the following sections, which describe the complex deployment descriptor elements that can be defined in the weblogic.xml deployment descriptor under the root element weblogic-web-app:

weblogic.xml Namespace Declaration and Schema Location

The correct text for the namespace declaration and schema location for the WebLogic Server weblogic.xml file is as follows.

<weblogic-web-app xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app">

To view the schema for weblogic.xml, go to http://xmlns.oracle.com/weblogic/weblogic-web-app/1.9/weblogic-web-app.xsd.

async-descriptor

Use the async-descriptor element to configure the asynchronous processing behavior of Web applications. The following table describes the elements you can define within an async-descriptor element.

Table B-1 async-descriptor Elements

Element Required/Optional Description
timeout-secs

Optional

Sets the time, in seconds, that WebLogic Server waits before timing out an asynchronous job. The default value is 120 seconds.

Setting the timeout to -1 indicates that the asynchronous job never times out.

timeout-check-interval-secs

Optional

Sets the time, in seconds, that WebLogic Server waits between doing checks for timed-out jobs. The default value is 30 seconds.

async-work-manager

Use the async-work-manager element to specify a Work Manager for asynchronous jobs, including asynchronous dispatches initiated using the AsyncContext dispatch methods and runnable jobs started using the AsyncContext start method. If no Work Manager is specified, the asynchronous jobs will be executed in the current request Work Manager.

auth-filter

The auth-filter element specifies an authentication filter HttpServlet class.

Note:

This is a deprecated element for the current release. Instead, use servlet authentication filters.

charset-params

The charset-params element is used to define code set behavior for non-unicode operations. For example:

<charset-params> 
    <input-charset> 
        <resource-path>/*</resource-path> 
        <java-charset-name>UTF-8</java-charset-name> 
    </input-charset> 
</charset-params>

charset-mapping

Use the charset-mapping element to map an IANA character set name to a Java character set name. For example:

<charset-mapping>
    <iana-charset-name>Shift-JIS</iana-charset-name>
    <java-charset-name>SJIS</java-charset-name>
</charset-mapping>

See Mapping IANA Character Sets to Java Character Sets.

The following table describes the elements you can define within a charset-mapping element.

Table B-2 charset-mapping Elements

Element Required/Optional Description
iana-charset-name

Required

Specifies the IANA character set name that is to be mapped to the Java character set specified by the java-charset-name element.

java-charset-name

Required

Specifies the Java characters set to use.

input-charset

Use the input-charset element to define which character set is used to read GET and POST data. For example:

<input-charset>
    <resource-path>/foo</resource-path>
    <java-charset-name>SJIS</java-charset-name>
</input-charset>

See Determining the Encoding of an HTTP Request.

The following table describes the elements you can define within a input-charset element.

Table B-3 input-charset Elements

Element Required/Optional Description
resource-path

Required

A path which, if included in the URL of a request, signals WebLogic Server to use the Java character set specified by java-charset-name.

java-charset-name

Required

Specifies the Java characters set to use.

container-descriptor

The container-descriptor element specifies a list of parameters that affect the behavior of the Web application.

access-logging-disabled

The access-logging-disabled element defines whether to eliminate access logging of the underlying Web application. Setting this property to true improves server throughput by reducing the logging overhead. If the property is not specified or a false value is set, application accesses are logged.

allow-all-roles

In the security-constraints elements defined in the web.xml descriptor of a Web application, the auth-constraint element indicates the user roles that should be permitted access to this resource collection. Here role-name = "*" is a compact syntax for indicating all roles in the Web application. In past releases, role-name = "*" was treated as all users/roles defined within the realm.

This allow-all-roles element is a backward compatibility switch to restore old behavior. The default behavior is to allow all roles defined in the Web application. The value specified in weblogic.xml takes precedence over the value defined in the WebAppContainerMBean.

check-auth-on-forward

Add the check-auth-on-forward element when you want to require authentication of forwarded requests from a servlet or JSP. Omit the tag if you do not want to require re-authentication. For example:

<container-descriptor>
    <check-auth-on-forward/>
</container-descriptor>

Note:

As a best practice, Oracle recommends that you do not enable the check-auth-on-forward property.

client-cert-proxy-enabled

The client-cert-proxy-enabled element default value is true. When set to true, WebLogic Server passes identity certificates from the clients to the backend servers. Also, WebLogic Server is notified whether to honor or discard the incoming WL-Proxy-Client-Cert header.

A proxy-server plugin encodes each identity certification in the WL-Proxy-Client-Cert header and passes it to the backend WebLogic Server instances. Each WebLogic Server instance takes the certificate information from the header, ensures it came from a secure source, and uses that information to authenticate the user. For the background WebLogic Server instances, this parameter must be set to true (either at the cluster/server level or at the Web application level).

If you set this element to true, use a weblogic.security.net.ConnectionFilter to ensure that each WebLogic Server instance accepts connections only from the machine on which the proxy-server plugin is running. If you specify true without using a connection filter, a potential security vulnerability is created because the WL-Proxy-Client-Cert header can be spoofed.

container-initializer-enabled

The container-initializer-enabled element controls whether or not to enable the servlet container initializer.

In Servlet 3.x applications, ServletContainerInitializer is enabled by default. For performance considerations, you can explicitly disable the servlet container initializer by configuring the container-initializer-enabled element in the weblogic.xml deployment descriptor in the targeted Web application. For example:

<?xml version="1.0" encoding="UTF-8"?> 
<weblogic-web-app xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
                  xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
http://xmlns.jcp.org/xml/ns/javaee/web-app_3.1.xsd 
http://xmlns.oracle.com/weblogic/weblogic-web-app 
http://xmlns.oracle.com/weblogic/weblogic-web-app/1.9/weblogic-web-app.xsd">    
    ... 
    <container-descriptor> 
        <container-initializer-enabled>false</container-initializer-enabled> 
    </container-descriptor> 
     ... 
</weblogic-web-app> 

In pre-servlet 3.x applications, you can explicitly enable the servlet container initializer by setting the container-initializer-enabled element in the weblogic.xml deployment descriptor to true. For example:

<container-descriptor>
    <container-initializer-enabled>true</container-initializer-enabled>
</container-descriptor>

default-mime-type

The default-mime-type element default value is null. This element allows the user to specify the default mime type for a content-type for which the extension is not mapped.

disable-implicit-servlet-mappings

When the disable-implicit-servlet-mappings flag is set to true, the Web application container does not create implicit mappings for internal servlets (*.jsp, *.class, and so on); only for the default servlet mapping. A typical use case for turning off implicit servlet mappings would be when configuring HttpClusterServlet or HttpProxyServlet.

The default value is false.

filter-dispatched-requests-enabled

The filter-dispatched-requests-enabled element controls whether or not filters are applied to dispatched requests. The default value is false.

Note:

Because 2.4 servlets are backward compatible with 2.3 servlets (per the 2.4 specification), when 2.3 descriptor elements are detected by WebLogic Server, the filter-dispatched-requests-enabled element defaults to true.

gzip-compression

Section Title

The gzip-compression element controls GZIP compression support for a specified Web application.

Table B-4 gzip-compression sub-elements

Element Description Default Value
enabled

Enables GZIP compression for the specified Web application. If set to true, only the current application is affected.

If specified, the weblogic.xml value overrides the domain-level value.

false
min-content-length

Specifies the minimum file size to trigger compression for the specified Web application. This element allows you to bypass small-sized resources where compression would not yield a great return but use unnecessary CPUs.

If specified, the weblogic.xml value overrides the domain-level value.

2048
content-type

Specifies the type of content to be included in compression. You can specify more than one content type by using separate content-type sub-elements for each type.

If specified, the weblogic.xml value overrides the domain-level value.

text/html, text/xml, text/plain

If the gzip-compression element and all of its sub-elements are present, these values override any default values at the domain level. If one of the sub-elements is absent, then the default domain value for that attribute is used.

The following example demonstrates setting the gzip-compression element and its sub-elements:

<weblogic-web-app>
   <container-descriptor>
      <gzip-compression>
         <enabled>true</enabled>
         <min-content-length>4096</min-content-length>
         <content-type>text/html</content-type>
         <content-type>text/xml</content-type>
      </gzip-compression>
   </container-descriptor>
</weblogic-web-app>

(Optional) Enter reference information in this section.

Syntax

(Optional) Enter syntax information here.

Example B-1 Example Title

(Optional) Enter an example to illustrate your reference here.

index-directory-enabled

The index-directory-enabled element controls whether or not to automatically generate an HTML directory listing if no suitable index file is found.

The default value is false (does not generate a directory). Values are true or false.

index-directory-sort-by

The index-directory-sort-by element defines the order in which the directory listing generated by weblogic.servlet.FileServlet is sorted. Valid sort-by values are NAME, LAST_MODIFIED, and SIZE. The default sort-by value is NAME.

langtag-revision

The langtag-revision element determines the language tag specification version that the HttpServletRequest getLocale and getLocales methods should obey.

Currently, WebLogic Server supports RFC5646 and RFC3066. If you do not set a value, the HttpServletRequest getLocale and getLocales methods return a language tag for locale according to RFC5646. The value 3066 means that the HttpServletRequest getLocale and getLocales methods return a language tag for locale according to RFC3066. For example, if using RFC3066:

<container-descriptor>
  <langtag-revision>3066</langtag-revision>
</container-descriptor>

The system property -Dweblogic.servlet.langtagRevision can also determine the locale parsing mechanism. However, explicit configuration for the langtag-revision element in weblogic.xml takes precedence over configuration in -Dweblogic.servlet.langtagRevision. If you do not set a value in weblogic.xml, then the system property configuration takes effect.

The following table describes the relationship between the langtag-revision element in weblogic.xml, the system property -Dweblogic.servlet.langtagRevision, and RFC3066 behavior.

System Property weblogic.xml Uses RFC3066 behavior

not set/5646

not set/5646

off

not set/5646

3066

on

3066

not set

on

3066

5646

off

3066

3066

on

minimum-native-file-size

The minimum-native-file-size element applies only when native-io-enabled is set to true. It sets the minimum file size in Bytes for using native I/O. If the file being served is larger than this value, native I/O is used. If you do not set this value, the default value used is 4000.

native-io-enabled

To use native I/O while serving static files with weblogic.servlet.FileServlet, which is implicitly registered as the default servlet, set native-io-enabled to true. (The default value is false.) native-io-enabled element applies only on Windows.

optimistic-serialization

When optimistic-serialization is turned on, WebLogic Server does not serialize-deserialize context and request attributes upon getAttribute(name) when the request is dispatched across servlet contexts.

This means that you must make sure that the attributes common to Web applications are scoped to a common parent classloader (application scoped) or you must place them in the system classpath if the two Web applications do not belong to the same application.

When optimistic-serialization is turned off (default value), WebLogic Server serialize-deserializes context and request attributes upon getAttribute(name) to avoid the possibility of ClassCastExceptions.

The optimistic-serialization value can also be specified at domain level in the WebAppContainerMBean, which applies for all Web applications. The value in weblogic.xml, if specified, overrides the domain-level value.

The default value is false.

prefer-application-packages

The prefer-application-packages element specifies a list of packages for classes that must always be loaded from the application. See prefer-application-packages in Developing Applications for Oracle WebLogic Server.

<?xml version="1.0" encoding="UTF-8"?>

<wls:weblogic-web-app
xmlns:wls="http://xmlns.oracle.com/weblogic/weblogic-web-app"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/ejb-jar_3_2.xsd
http://xmlns.oracle.com/weblogic/weblogic-web-app
http://xmlns.oracle.com/weblogic/weblogic-web-app/1.9/weblogic-web-app.xsd">

     <wls:weblogic-version>12.2.1</wls:weblogic-version>
     <wls:context-root>FilterWeb</wls:context-root>
     <wls:container-descriptor>
         <wls:prefer-application-packages>
             <wls:package-name>com.oracle.foo</wls:package-name>
         </wls:prefer-application-packages>
     </wls:container-descriptor>
</wls:weblogic-web-app>

Note that in order to use prefer-application-packages or prefer-application-resources, prefer-web-inf-classes must be set to false.

prefer-application-resources

The prefer-application-resources element specifies a list of resources that must always be loaded from the application, even if the resources are found in the system classloader. See prefer-application-resources in Developing Applications for Oracle WebLogic Server.

<?xml version="1.0" encoding="UTF-8"?>
<weblogic-web-app xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app">
  <container-descriptor>
    <prefer-web-inf-classes>false</prefer-web-inf-classes>
    <prefer-application-packages>
      <package-name>javax.faces.*</package-name>
      <package-name>com.sun.faces.*</package-name>
      <package-name>com.bea.faces.*</package-name>
    </prefer-application-packages>
 
    <prefer-application-resources>
      <resource-name>javax.faces.*</resource-name>
      <resource-name>com.sun.faces.*</resource-name>
      <resource-name>com.bea.faces.*</resource-name>
      <resource-name>META-INF/services/javax.servlet.ServletContainerInitializer</resource-name>
      </prefer-application-resources>
  </container-descriptor>
</weblogic-web-app>

Note that in order to use prefer-application-packages or prefer-application-resources, prefer-web-inf-classes must be set to false.

prefer-forward-query-string

When HttpServletRequest.getQueryString() is invoked in a forwarding request, WebLogic Server returns the queryString sent by the forwarding servlet via RequestDispatcher and the original ones sent by the client.

When the prefer-forward-query-string flag is set to true, WebLogic Server returns only the forwarded query string, if it is specified. The default value is false.

prefer-web-inf-classes

The prefer-web-inf-classes element, if set to true, will cause classes located in the WEB-INF directory of a Web application to be loaded in preference to classes loaded in the application or system classloader. The default value is false. A value specified in the WebLogic Server Administration Console will take precedence over a value set manually.

Note:

Neither prefer-application-packages nor prefer-application-resources can be specified when prefer-web-inf-classes is turned on in weblogic.xml.

redirect-with-absolute-url

The redirect-with-absolute-url element controls whether the javax.servlet.http.HttpServletResponse.SendRedirect() method redirects using a relative or absolute URL. Set this element to false if you are using a proxy HTTP server and do not want the URL converted to a non-relative link.

The default behavior is to convert the URL to a non-relative link.

Note:

User readable data used in a redirect.

referer-validation

To help mitigate Cross-Site Request Forgery (CSRF) attacks, you can configure validation of the Referer header in incoming HTTP requests.

Checking the Referer is a commonly used method of preventing CSRF on embedded network devices because it does not require any per-user state. This makes Referer a useful method of CSRF prevention when memory is scarce or server-side state doesn't exist. This method of CSRF mitigation is also commonly used with unauthenticated requests, such as requests made prior to establishing a session state which is required to keep track of a synchronization token.

<container-descriptor>
<referer-validation>NONE</referer-validation>
</container-descriptor>

Valid values:

  • NONE: Disable Referer header validation.

  • LENIENT (default): The web container blocks requests whose Referer header has an incorrect value. If a requests lacks the header, the web container accepts the request.

  • STRICT: The web container blocks requests that lack a Referer header.

For example, an authentication request is sent to http://myhost:myport/myapp/Jj_security_check:
  • If <referer-validation>NONE</referer-validation>, then the container will not validate the Referer header.

  • If <referer-validation>LENIENT</referer-validation> and there is a Referer header in this request, then the container will check the host and port of Referer URL.

    • If they are "myhost" and "myport", then this Referer header is valid.

    • If either the host or port of the Referer URL is different from the actual URL, for example, ”myhost1”, then this Referer header is invalid.

    • If there is no Referer header in this request, then the container will not validate it.

  • If <referer-validation>STRICT</referer-validation> and there is a Referer header in this request, the container will check the host and port of the Referer URL.

    • If they are "myhost" and "myport", then this Referer header is valid.

    • If either the host or port of the Referer URL is different from the actual URL, for example, ”myhost1”, then this Referer header is invalid.

    • If there is no Referer header in this request, then the validation will fail.

Note:

The web container also will consider the IP address. For example, if 192.168.226.129 is mapped to "myhost", then it is valid if the host of the Referer URL is "192.168.226.129".

relogin-enabled

The relogin-enabled element is a backward compatibility parameter. If a user has logged in already and tries to access a resource for which s/he does not have privileges, a FORBIDDEN (403) response occurs.

require-admin-traffic

The require-admin-trafffic element defines whether traffic should go through the administration channel. When set to true traffic is allowed to go through the administration channel. Otherwise, traffic can only go through administration channel when the Web application is in administrative mode. For example:

<container-descriptor>
    <require-admin-traffic>true</require-admin-traffic>
</container-descriptor>

resource-reload-check-secs

The resource-reload-check-secs element is used to perform metadata caching for cached resources that are found in the resource path in the Web application scope. This parameter identifies how often WebLogic Server checks whether a resource has been modified and if so, it reloads it.

  • The value -1 means never reload. This is the default value in a production environment.

  • The value 0 means always reload.

  • The value 1 means reload every second. This is the default value in a development environment.

Values specified for this parameter using the WebLogic Server Administration Console are given precedence.

Note:

If the resource is a JSP, and if page-check-secondsis specified in the jsp-descriptor element, the page-check-seconds value is used to determine reload time for the JSP file.

save-sessions-enabled

The save-sessions-enabled element controls whether session data is cleaned up during redeploy or undeploy. It affects memory and replicated sessions. Setting the value to true means session data is saved. Setting to false means session data will be destroyed when the Web application is redeployed or undeployed. The default is false.

servlet-reload-check-secs

The servlet-reload-check-secs element defines whether a WebLogic Server will check to see if a servlet has been modified, and if it has been modified, reloads it.

  • The value -1 means never check the servlets. This is the default value in a production environment.

  • The value 0 means always check the servlets.

  • The value 1 means check the servlets every second. This is the default value in a development environment.

A value specified in the WebLogic Server WebLogic Server Administration Console will always take precedence over a manually specified value.

session-monitoring-enabled

The session-monitoring-enabled element, if set to true, allows run-time MBeans to be created for sessions. When set to false, the default value, run-time MBeans are not created. A value specified in the WebLogic Server Administration Console takes precedence over a value set manually.

show-archived-real-path-enabled

The show-archived-real-path-enabled element specifies the behavior of getRealPath() for archived Web applications.

When set to true, getRealPath() returns the canonical path of the resource files.

If the show-archived-real-path-enabled element is set to false, the servlet container will return the real path of files in archived Web applications as null.

The default value is false.

single-threaded-servlet-pool-size

The single-threaded-servlet-pool-size element defines the size of the pool used for SingleThreadMode instance pools. The default value is 5.

Note:

SingleThreadMode instance pools are deprecated in this release.

temp-dir

The temp-dir element specifies the location of the temporary directory for the Web application, as returned by the "javax.servlet.context.tempDir" attribute.

context-root

The context-root element defines the context root of this standalone Web application. If the Web application is part of an EAR, not standalone, specify the context root in the EAR's META-INF/application.xml file. A context-root setting in application.xml takes precedence over context-root setting in weblogic.xml.

Note that this weblogic.xml element only acts on deployments using the two-phase deployment model.

The order of precedence for context root determination for a Web application is as follows:

  • Check context-root and web-uri in application.xml for context root; if found, use as Web application's context root.

  • If context root is not set in application.xml, and the Web application is being deployed as part of an EAR, check whether context root is defined in weblogic.xml. If found, use as Web application's context root. If the Web application is deployed standalone, application.xml does not come into play and the determination for context-root starts at weblogic.xml and defaults to URI if it is not defined there.

  • If context root is not defined in weblogic.xml or application.xml, then infer the context path from the URI, giving it the name of the value defined in the URI minus the WAR suffix. For instance, a URI MyWebApp.war would be named MyWebApp.

    Note:

    The context-root element cannot be set for individual Web applications in EAR libraries. It can only bet set for Web application libraries.

description

The description element is a text description of the Web application.

ejb-reference-description

The following table describes the elements you can define within a ejb-reference-description element.

Table B-5 ejb-reference-description Elements

Element Required/Optional Description
ejb-ref-name

Required

Specifies the name of an EJB reference used in your Web application.

jndi-name

Required

Specifies a JNDI name for the reference.

fast-swap

The following table describes the elements you can define within a fast-swap element.

For more information about FastSwap Deployment, see Using FastSwap Deployment to Minimize Redeployment in Deploying Applications to Oracle WebLogic Server.

Table B-6 fast-swap Elements

Element Required/Optional Description
enabled

Optional

Set to true to enable FastSwap deployment in your application.

refresh-interval

Optional

FastSwap checks for changes in application classes when an incoming HTTP request is received. Subsequent HTTP requests arriving within the refresh-interval seconds will not trigger a check for changes. The first HTTP request arriving after the refresh-interval seconds have passed, will cause FastSwap to perform a class-change check again.

redefinition-task-limit

Optional

FastSwap class redefinitions are performed asynchronously by redefinition tasks. They can be controlled and inspected using JMX interfaces.

Specifies the number of redefinition tasks that will be retained by the FastSwap system. If the number of tasks exceeds this limit, older tasks are automatically removed.

jsp-descriptor

The jsp-descriptor element specifies a list of configuration parameters for the JSP compiler. The following table describes the elements you can define within a jsp-descriptor element.

Table B-7 jsp-descriptor Elements

Element Default Value Description
page-check-seconds 1

Sets the interval, in seconds, at which WebLogic Server checks to see if JSP files have changed and need recompiling. Dependencies are also checked and recursively reloaded if changed.

  • The value -1 means never check the pages. This is the default value in a production environment.

  • The value 0 means always check the pages.

  • The value 1 means check the pages every second. This is the default value in a development environment.

In a production environment where changes to a JSP are rare, consider changing the value of pageCheckSeconds to 60 or greater, according to your tuning requirements.

strict-stale-check true

Applies to exploded WARs only.

Checks for updated JSP files, in other words, whether the timestamp on the file is later (more recent) than the one in the build. Only newer files can replace older ones.

When set to false, just checks whether the timestamp has changed. If so, the file is replaced.

<?xml version="1.0" encoding="UTF-8"?>
<weblogic-web-app xmlns="http://
xmlns.oracle.com/weblogic/weblogic-web-app">
  <jsp-descriptor>
    <strict-stale-check>false
    </strict-stale-check>
  </jsp-descriptor>
</weblogic-web-app>
precompile false

When set to true, WebLogic Server automatically precompiles all JSPs when the Web application is deployed or re-deployed or when starting WebLogic Server.

precompile-continue false

When set to true, WebLogic Server continues precompiling all JSPs even if some of those JSPs fail during compilation. Only takes effect when precompile is set to true.

keepgenerated false

Saves the Java files that are generated as an intermediary step in the JSP compilation process. Unless this parameter is set to true, the intermediate Java files are deleted after they are compiled.

debug false

When set to true, WebLogic Server enables the debugging feature of the JSP compiler.

The default value is false.

verbose true

When set to true, debugging information is printed out to the browser, the command prompt, and WebLogic Server log file.

working-dir internally generated directory

The name of a directory where WebLogic Server saves the generated Java and compiled class files for a JSP.

Note: If weblogic.xml defines a working-dir, WebLogic Server does not delete this directory when the Web application is undeployed.

print-nulls null

When set to false, this parameter ensures that expressions with "null" results are printed as " ".

backward-compatible true

When set to true, backward compatibility is enabled.

See Backwards Compatibility Flags.

encoding UTF-8 for JSP and JSPX pages

Specifies the default character set used in the JSP page. Use standard Java character set names (see http://docs.oracle.com/javase/8/docs/technotes/guides/intl/).

If not set, this attribute defaults to the encoding for your platform.

A JSP page directive (included in the JSP code) overrides this setting. For example:

<%@ page contentType="text/html; charset=custom-encoding"%>

package-prefix jsp_servlet

Specifies the package prefix into which all JSP pages are compiled.

exact-mapping true

When true, upon the first request for a JSP the newly created JspStub is mapped to the exact request. If exactMapping is set to false, the Web application container generates non-exact url mapping for JSPs. exactMapping allows path info for JSP pages.

default-file-name true

The default file name in which WebLogic Server saves the generated Java and compiled class files for a JSP.

rtexprvalue-jsp-param-name false

Allows run-time expression values in the name attribute of the jsp:param tag. It is set to false by default.

optimize-java-expression false

When set to true, the JSP compiler optimizes Java expressions to improve run-time performance.

compress-html-template false

When set to true, compresses the HTML in the JSP template blocks to improve run-time performance.

If the JSP's HTML template block contains the <pre> HTML tag, do not enable this feature.

library-ref

The library-ref element references a library module, which is intended to be used as a Web application library in the current Web application.

Example:

<library-ref>
    <library-name>WebAppLibraryFoo</library-name>
    <specification-version>2.0</specification-version>
    <implementation-version>8.1beta</implementation-version>
    <exact-match>false</exact-match>
</library-ref>

Only the following sub-elements are relevant to Web applications: library-name, specification-version, implementation-version, and exact-match.

You can define the following elements within the library-ref element.

Table B-8 library-ref Elements

Element Required/Optional Description
library-name

Required

Provides the library name for the library module reference. The default value is null.

specification-version

Optional

Provides the specification version for the library module reference. The default value is 0. (This is a float.)

implementation-version

Optional

Provides the implementation version for the library module reference. The default value is null.

exact-match

Optional

The default value is false.

logging

The logging element is a sub-element of the weblogic-web-app element. You can define the following elements within the logging element.

Table B-9 logging Elements

Element Required/Optional Description
log-filename

Required

Specifies the name of the log file. The full address of the filename is required.

logging-enabled

Optional

Indicates whether or not the log writer is set for either the ManagedConnectionFactory or ManagedConnection. If this element is set to true, output generated from either the ManagedConnectionFactory or ManagedConnection will be sent to the file specified by the log-filename element.

Failure to specify this value will result in WebLogic Server using its defined default value.

Value Range: true | false

Default Value: false

rotation-type

Optional

Sets the file rotation type.

Values are bySize, byTIme, none

  • bySize—When the log file reaches the size that you specify in file-size-limit, the server renames the file as FileName.n.

  • byTIme—At each time interval that you specify in file-time-span, the server renames the file as FileName.n. After the server renames a file, subsequent messages accumulate in a new file with the name that you specified in log-filename.

  • none—Messages accumulate in a single file. You must erase the contents of the file when the size is unwieldy.

Default Value: bySize

number-of-files-limited

Optional

Specifies whether the number of files that this server instance creates to store old messages should be limited. (Requires that you specify a rotation-type of bySize). After the server reaches this limit, it overwrites the oldest file. If you do not enable this option, the server creates new files indefinitely and you must clean up these files as you require.

If you enable number-of-files-limited by setting it to true, the server refers to your rotationType variable to determine how to rotate the log file. Rotate means that you override your existing file instead of creating a new file. If you specify false for number-of-files-limited, the server creates numerous log files rather than overriding the same one.

Value Range: true | false

Default Value: false

file-count

Optional

The maximum number of log files that the server creates when it rotates the log. This number does not include the file that the server uses to store current messages. (Requires that you enable number-of-files-limited.)

Default Value: 7

file-size-limit

Optional

The size that triggers the server to move log messages to a separate file. (Requires that you specify a rotation-type of bySize.) After the log file reaches the specified minimum size, the next time the server checks the file size, it will rename the current log file as FileName.n and create a new one to store subsequent messages.

Default Value: 500

rotate-log-on-startup

Optional

Specifies whether a server rotates its log file during its startup cycle.

Value Range: true | false

Default Value: true

log-file-rotation-dir

Optional

Specifies the directory path where the rotated log files will be stored.

rotation-time

Optional

The start time for a time-based rotation sequence of the log file, in the format k:mm, where k is 1-24. (Requires that you specify a rotation-type of byTime.) At the specified time, the server renames the current log file. Thereafter, the server renames the log file at an interval that you specify in file-time-span.

If the specified time has already past, then the server starts its file rotation immediately.

By default, the rotation cycle begins immediately.

file-time-span

Optional

The interval (in hours) at which the server saves old log messages to another file. (Requires that you specify a rotation-type of byTime.)

Default Value: 24

ready-registration

To use the ReadyApp framework, register a WAR-based application with the framework by adding the following code to the application's WebLogic deployment descriptor (META-INF\weblogic-application.xml):

<wls:ready-registration>true</wls:ready-registration>

When the application starts, the state of the application is set to NOT READY.

Note:

The prefix wls: may or may not be required depending on the contents of the weblogic-application.xml file. If the rest of the tags do not have the prefix, you can ignore the prefix.

See Configuring the ReadyApp Framework with EAR or WAR-based Applications in Deploying Applications to Oracle WebLogic Server.

resource-description

The resource-description element is used to map the JNDI name of a server resource to an EJB resource reference in WebLogic Server.

The following table describes the elements you can define within a resource-description element.

Table B-10 resource-description Elements

Element Required/Optional Description
res-ref-name

Required

Specifies the name of a resource reference.

jndi-name

Required

Specifies a JNDI name for the resource.

resource-env-description

The resource-env-description element maps a resource-env-ref, declared in the ejb-jar.xml deployment descriptor, to the JNDI name of the server resource it represents.

The following table describes the elements you can define within a resource-env-description element.

Table B-11 resource-env-description Elements

Element Required/Optional Description
res-env-ref-name

Required

Specifies the name of a resource environment reference.

jndi-name

Required

Specifies a JNDI name for the resource environment reference.

run-as-role-assignment

The run-as-role-assignment element maps a run-as role name (a sub-element of the servlet element) in web.xml to a valid user name in the system. The value can be overridden for a given servlet by the run-as-principal-name element in the servlet-descriptor. If the run-as-role-assignment is absent for a given role name, the Web application container uses the first principal-name defined in the security-role-assignment. The following example illustrates how to use the run-as-role-assignment element.

<run-as-role-assignment>
    <role-name>RunAsRoleName</role-name>
    <run-as-principal-name>joe</run-as-principal-name>
</run-as-role-assignment>

The following table describes the elements you can define within a run-as-role-assignment element.

Table B-12 run-as-role-assignment Elements

Element Required/Optional Description
role-name

Required

Specifies the name of a security role.

run-as-principal-name

Required

Specifies the name of a principal.

security-permission

The security-permission element specifies a single security permission based on the security policy file syntax. Refer to the following URL for the implementation of the security permission specification: http://docs.oracle.com/javase/8/docs/technotes/guides/security/PolicyFiles.html.

Disregard the optional codebase and signedBy clauses.

For example:

<security-permission-spec>
     grant { permission java.net.SocketPermission "*", "resolve" };
</security-permission-spec>

where:

  • permission java.net.SocketPermission is the permission class name.

  • "*" represents the target name.

  • resolve indicates the action.

security-role-assignment

The security-role-assignment element declares a mapping between a Web application security role and one or more principals in WebLogic Server, as shown in the following example.

<security-role-assignment>
    <role-name>PayrollAdmin</role-name>
    <principal-name>Tanya</principal-name>
    <principal-name>Fred</principal-name>
    <principal-name>system</principal-name>
</security-role-assignment>

You can also use it to mark a given role as an externally defined role, as shown in the following example:

<security-role-assignment>
    <role-name>roleadmin</role-name>
    <externally-defined/>
</security-role-assignment>

Note:

In the security-role-assignment element, either principal-name or externally-defined must be defined. Both cannot be omitted.

The following table describes the elements you can define within a security-role-assignment element.

Table B-13 security-role-assignment Elements

Element Required/Optional Description
role-name

Required

Specifies the name of a security role.

principal-name

Required if externally-defined is not defined.

Specifies the name of a principal that is defined in the security realm. You can use multiple principal-name elements to map principals to a role. For more information on security realms, see Administering Security for Oracle WebLogic Server.

externally-defined

Required if principal-name is not defined.

Specifies that a particular security role is defined globally in a security realm; WebLogic Server uses this security role as the principal name, rather than looking it up in a global realm. When the security role and its principal-name mapping are defined elsewhere, this is used as an indicative placeholder.

If you do not define a security-role-assignment element and its sub-elements, the Web application container implicitly maps the role name as a principal name and logs a warning. The EJB container does not deploy the module if mappings are not defined.

Consider the following usage scenarios for the role name is "role_xyz"

  • If you map "role_xyz" to user "joe" in weblogic.xml, role_xyz becomes a local role.

  • If you specify role_xyz as an externally defined role, it becomes global (it refers to the role defined at the realm level).

  • If you do not define a security-role-assignment element, role_xyz becomes a local role, and the Web application container creates an implicit mapping to it and logs a warning.

service-reference-description

The following table describes the elements you can define within a service-reference-description element.

Table B-14 service-reference-description Elements

Element Required/Optional Description
service-ref-name

wsdl-url

call-property

The call-property element has the following sub-elements:

name

value

port-info

The port-info element has the following sub-elements:

port-name

stub-property

call-property

servlet-descriptor

Use the servlet-descriptor element to aggregate the servlet-specific elements.

The following table describes the elements you can define within the servlet-descriptor element.

Table B-15 servlet-descriptor Elements

Element Required/Optional Description
servlet-name

Required

Specifies the servlet name as defined in the servlet element of the web.xml deployment descriptor file.

run-as-principal-name

Optional

Contains the name of a principal against the run-as-role-name defined in the web.xml deployment descriptor.

init-as-principal-name

Optional

Equivalent to run-as-principal-name for the init method for servlets. The identity specified here should be a valid user name in the system. If init-as-principal-name is not specified, the container uses the run-as-principal-name element.

destroy-as-principal-name

Optional

Equivalent to run-as-principal-name for the destroy method for servlets. The identity specified here should be a valid user name in the system. If destroy-as-principal-name is not specified, the container uses the run-as-principal-name element.

dispatch-policy

Optional

This is a deprecated element. Used to assign a given servlet to a configured Work Manager by identifying the Work Manager name. This setting overrides the Web application-level dispatch policy defined by wl-dispatch-policy.

session-descriptor

The following table describes the elements you can define within a session-descriptor element to define parameters for servlet sessions.

Table B-16 session-descriptor

Element Name Default Value Value
timeout-secs

3600

Sets the time, in seconds, that WebLogic Server waits before timing out a session. The default value is 3600 seconds.

On busy sites, you can tune your application by adjusting the timeout of sessions. While you want to give a browser client every opportunity to finish a session, you do not want to tie up the server needlessly if the user has left the site or otherwise abandoned the session.

This element can be overridden by the session-timeout element (defined in minutes) in web.xml.

invalidation-interval-secs 60

Sets the time, in seconds, that WebLogic Server waits between doing house-cleaning checks for timed-out and invalid sessions, and deleting the old sessions and freeing up memory. Use this element to tune WebLogic Server for best performance on high traffic sites.

The default value is 60 seconds.

invalidate-on-relogin false

Sets whether the container must invalidate the current session if the currently logged-in user switches to a different user name (which is valid in the security realm) and attempts to log in again.

If the value of this parameter is set to true, the current session is invalidated if the user attempts to log in again using a different user name.

sharing-enabled

false

Enables Web applications to share HTTP sessions when the value is set to true at the application level.

This element is ignored if turned on at the Web application level.

debug-enabled

false

Enables the debugging feature for HTTP sessions.

The default value is false.

id-length

52

Sets the size of the session ID.

The minimum value is 32 bytes and the maximum value is Integer.MAX_VALUE.

Note: If a value lower than 32 bytes is set, WebLogic Server automatically raises the value to 32 and displays the following message:

The IDLength is too short. It is not secure. WLS will raise the length to 32.

If you are writing a WAP application, you must use URL rewriting because the WAP protocol does not support cookies. Also, some WAP devices have a 128-character limit on URL length (including attributes), which limits the amount of data that can be transmitted using URL rewriting. To allow more space for attributes, use this attribute to limit the size of the session ID that is randomly generated by WebLogic Server.

You can also limit the length to a fixed 52 characters, and disallow special characters, by setting the WAPEnabled attribute. See URL Rewriting and Wireless Access Protocol (WAP).

tracking-enabled

true

Enables session tracking between HTTP requests.

cache-size

1028

Sets the cache size for JDBC and file-persistent sessions.

max-in-memory-sessions

-1

Sets the maximum limit for memory/replicated sessions.

Without the ability to configure bound in-memory servlet session use, as new sessions are continually created, the server eventually grows out of memory. To protect against this, WebLogic Server provides a configurable bound on the number of sessions created. When this number is exceeded, the weblogic.servlet.SessionCreationException occurs for each attempt to create a new session. This feature applies to both replicated and non-replicated in-memory sessions.

To configure bound in-memory servlet session use, you set the limitation in the max-in-memory-sessions element.

The default is -1 (unlimited); any negative value works as the same as -1.

max-save-post-size

4096

Sets the maximum size, in bytes, of the POST data that the container saves/buffers during FORM authentication.

The default value is 4096 bytes.

save-post-timeout-secs

40

Defines the timeout, in seconds, for the session that saved/buffered POST data. For FORM authentication, POST data is saved in a session while the user is redirected to the login form.

The default value is 40 seconds.

If the value of the save-post-timeout-secs element is less than the value of the timeout-secs element, then session invalidation may occur during user operations. In this scenario, increase the value of save-post-timeout-secs to match the timeout-secs value or to an acceptable value, according to your needs.

save-post-timeout-interval-secs

20

Sets the invalidation trigger interval, in seconds, for saving POST data in a session.

The default value is 20 seconds.

cookies-enabled true

Use of session cookies is enabled by default and is recommended, but you can disable them by setting this property to false. You might turn this option off to test.

cookie-name JSESSIONID

Defines the session tracking cookie name. Defaults to JSESSIONID if not set. You may set this to a more specific name for your application.

cookie-path

null

Defines the session tracking cookie path.

If not set, this attribute defaults to / (slash), where the browser sends cookies to all URLs served by WebLogic Server. You may set the path to a narrower mapping, to limit the request URLs to which the browser sends cookies.

cookie-domain

null

Specifies the domain for which the cookie is valid. For example, setting cookie-domain to.example.com returns cookies to any server in the *.example.com domain.

The domain name must have at least two components. Setting a name to *.com or *.net is not valid.

If not set, this attribute defaults to the server that issued the cookie.

See Cookie.setDomain() in the Servlet specification.

cookie-comment

null

Specifies the comment that identifies the session tracking cookie in the cookie file.

cookie-secure false

Tells the browser to only send the cookie back over an HTTPS connection. This ensures that the cookie ID is secure and should only be used on Web sites that use HTTPS. Session Cookies over HTTP no longer work if this feature is enabled.

You should disable the url-rewriting-enabled element if you intend to use this feature.

cookie-max-age-secs -1

Sets the life span of the session cookie, in seconds, after which it expires on the client.

This value can be set as any integer; the default value is -1 (unlimited).

For more information about cookies, see Using Sessions and Session Persistence.

persistent-store-type memory

Sets the persistent store method to one of the following options:

  • memory—Disables persistent session storage.

  • replicated—Same as memory, but session data is replicated across the clustered servers.

  • replicated_if_clustered—If the Web application is deployed on a clustered server, the in-effect persistent-store-type will be replicated. Otherwise, memory is the default.

  • async-replicated—Enables asynchronous session replication in an application or Web application. See Asynchronous HTTP Session Replication in Tuning Performance of Oracle WebLogic Server.

  • async-replicated-if-clustered—Enables asynchronous session replication in an application or Web application when deployed to a cluster environment. If deployed to a single server environment, then the session persistence/replication defaults to in-memory. This allows testing on a single server without deployment errors.

  • file—Uses file-based persistence (See also session-descriptor).

  • async-jdbc—Enables asynchronous JDBC persistence for HTTP sessions in an application or Web application. See Configuring Session Persistence.

  • jdbc—Uses a database to store persistent sessions. (see also session-descriptor).

  • cookie—All session data is stored in a cookie in the user's browser.

persistent-store-cookie-name WLCOOKIE

Sets the name of the cookie used for cookie-based persistence. The WLCOOKIE cookie carries the session state, which should not be shared between Web applications.

See Using Cookie-Based Session Persistence.

persistent-store-dir session_db

Specifies the storage directory used for file-based persistence

Ensure that you have enough disk space to store the number of valid sessions multiplied by the size of each session. You can find the size of a session by looking at the files created in the persistent-store-dir. Note that the size of each session can vary as the size of serialized session data changes.

Each server instance has a default persistent file store that requires no configuration. Therefore, if no directory is specified, a default store is automatically created in the <server-name>\data\store\default directory. However, the default store is not shareable among clustered servers.

You can make file-persistent sessions clusterable by creating a custom persistent store in a directory that is shared among different servers. However, this requires you to create this directory manually.

persistent-store-pool None

Specifies the name of a JDBC connection pool to be used for persistence storage.

persistent-data-source-jndi-name None

Specifies the data source JNDI name of a JDBC connection to be used for jdbc- and async-jdbc-based persistence (see persistent-store-type above).

For async-jdbc-based persistence, you must specify the persistent-data-source-jndi-name parameter to configure persistence storage.

persistent-store-table wl_servlet_sessions

Specifies the database table name used to store JDBC-based persistent sessions. This applies only when persistent-store-type is set to jdbc.

The persistent-store-table element is used when you choose a database table name other than the default.

jdbc-column-name-max-inactive-interval

Serves as an alternative name for the wl_max_inactive_interval column name. This jdbc-column-name-max-inactive-interval element applies only to JDBC-based persistence. It is required for certain databases that do not support long column names.

url-rewriting-enabled

true

Enables URL rewriting, which encodes the session ID into the URL and provides session tracking if cookies are disabled in the browser.

http-proxy-caching-of-cookies

true

When set to false, WebLogic Server adds the following header with the following response:

"Cache-control: no-cache=set-cookie"

This indicates that the proxy caches do not cache the cookies.

encode-session-id-in-query-params false

The latest servlet specification requires containers to encode the session ID in path parameters. Certain Web servers do not work well with path parameters. In such cases, the encode-session-id-in-query-params element should be set to true. (The default is false.)

runtime-main-attribute

Used in ServletSessionRuntimeMBean. The getMainAttribute() of the ServletSessionRuntimeMBean returns the session attribute value using this string as a key.

Example: user-name

This element is useful for tagging session runtime information for different sessions.

monitoring-attribute-name

Configures the monitoring ID for a given HTTP session.

HTTP sessions are identified with a monitoring ID. By default, the monitoring ID for a given HTTP session is a random string (not the same as a session ID for security reasons). This monitoring ID can be configured by setting the monitoring-attribute-name element in session-descriptor of the weblogic.xml deployment descriptor and then setting a session attribute the defined monitoring-attribute-name. The toString() of the session attribute value will then be used as a monitoring ID.

This element is useful for tagging session runtime information for different sessions. For example, you can set it to "username", if you have a "username" attribute that is unique.

cookie-http-only

true

Specifies whether HttpOnly cookies are enabled. When this element is set to true, all session cookies would be unavailable to the browser scripts. The default value is true. Therefore, HttpOnly cookies are enabled by default.

auth-cookie-id-length

20

Defines the length of the secure cookie, _WL_AUTHCOOKIE_JSESSIONID. The default cookie length is 20, and the minimum cookie length is 8.

url-match-map

Use this element to specify a class for URL pattern matching. The WebLogic Server default URL match mapping class is weblogic.servlet.utils.URLMatchMap, which is based on Java EE standards. Another implementation included in WebLogic Server is SimpleApacheURLMatchMap, which you can plug in using the url-match-map element.

Rule for SimpleApacheURLMatchMap:

If you map *.jws to JWSServlet then

http://example.com/bar.jws/baz will be resolved to JWSServlet with pathInfo = baz.

Configure the URLMatchMap to be used in weblogic.xml as in the following example:

<url-match-map>
    weblogic.servlet.utils.SimpleApacheURLMatchMap
</url-match-map>

virtual-directory-mapping

Use the virtual-directory-mapping element to specify document roots other than the default document root of the Web application for certain kinds of requests, such as image requests. All images for a set of Web applications can be stored in a single location, and need not be copied to the document root of each Web application that uses them. For an incoming request, if a virtual directory has been specified, the servlet container will search for the requested resource first in the virtual directory and then in the Web application's original document root. This defines the precedence if the same document exists in both places.

Example:

<virtual-directory-mapping>
     <local-path>c:/usr/gifs</local-path>
     <url-pattern>/images/*</url-pattern>
     <url-pattern>*.jpg</url-pattern>
</virtual-directory-mapping>
<virtual-directory-mapping>
     <local-path>c:/usr/common_jsps.jar</local-path>
     <url-pattern>*.jsp</url-pattern>
</virtual-directory-mapping>

The following table describes the elements you can define within the virtual-directory-mapping element.

Table B-17 virtual-directory-mapping Elements

Element Required/Optional Description
local-path

Required

Specifies a physical location on the disk.

url-pattern

Required

Contains the URL pattern of the mapping. Must follow the rules specified in Section 11.2 of the Servlet API Specification.

The WebLogic Server implementation of virtual directory mapping requires that you have a directory that matches the url-pattern of the mapping. The image example requires that you create a directory named images at c:/usr/gifs/images. This allows the servlet container to find images for multiple Web applications in the images directory.

weblogic-version

The weblogic-version element indicates the version of WebLogic Server on which this Web application (as defined in the root element weblogic-web-app) is intended to be deployed. This element is informational only and is not used by WebLogic Server.

wl-dispatch-policy

Use the wl-dispatch-policy element to assign the Web application to a configured Work Manager by identifying the Work Manager name. This Web application-level parameter can be overridden by the dispatch policy setting at the individual servlet or JSP level. You can set the dispatch policy by using:

  • The servlet's wl-dispatch-policy, using <init-param> of the <servlet> element in web.xml

  • The <dispatch-policy> element in the <servlet-descriptor> element of weblogic.xml

Note:

The <dispatch-policy> setting in weblogic.xml overrides the wl-dispatch-policy <init-param> configuration in web.xml.

work-manager

The work-manager element is a sub-element of the weblogic-web-app element. You can define the following elements within the work-manager element.

Table B-18 work-manager Elements

Element Required/Optional Description
name

Required

Specifies the name of the Work Manager.

response-time-request-class, fair-share-request-class, context-request-class, request-class-name

Optional

You can choose between the following four elements:

  • response-time-request-class—Defines the response time request class for the application. Response time is defined with attribute goal-ms in milliseconds. The increment is ((goal - T) Cr)/R, where T is the average thread use time, R the arrival rate, and Cr a coefficient to prioritize response time goals over fair shares.

  • fair-share-request-class—Defines the fair share request class. Fair share is defined with attribute percentage of default share. Therefore, the default is 100. The increment is Cf/(P R T), where P is the percentage, R the arrival rate, T the average thread use time, and Cf a coefficient for fair shares to prioritize them lower than response time goals.

  • context-request-class—Defines the context class. Context is defined with multiple cases mapping contextual information, like current user or its role, cookie, or work area fields to named service classes.

  • request-class-name—Defines the request class name.

min-threads-constraint, min-threads-constraint-name

Optional

You can choose between the following two elements:

  • min-threads-constraint—Used to guarantee a number of threads the server allocates to requests of the constrained work set to avoid deadlocks. The default is zero. A min-threads value of one is useful, for example, for a replication update request, which is called synchronously from a peer.

  • min-threads-constraint-name—Defines a name for the min-threads-constraint element.

max-threads-constraint, max-threads-constraint-name

Optional

You can choose between the following two elements:

  • max-threads-constraint—Limits the number of concurrent threads executing requests from the constrained work set. The default is unlimited. For example, consider a constraint defined with maximum threads of 10 and shared by 3 entry points. The scheduling logic ensures that not more than 10 threads are executing requests from the three entry points combined.

  • max-threads-constraint-name—Defines a name for the max-threads-constraint element.

capacity, capacity-name

Optional

You can choose between the following two elements:

  • capacity—Constraints can be defined and applied to sets of entry points, called constrained work sets. The server starts rejecting requests only when the capacity is reached. The default is zero. Note that the capacity includes all requests, queued or executing, from the constrained work set. This constraint is primarily intended for subsystems like JMS, which do their own flow control. This constraint is independent of the global queue threshold.

  • capacity-name—Defines a name for the capacity element.

Backward Compatibility Flags

For WebLogic Server, backward compatibility for WebLogic Server 9.2 or earlier is supported via the backward-compatible element within the jsp-descriptor element.

Compatibility with JSP 2.0 Web Applications

JSP 2.1 is supported as of WebLogic Server 10.0. Depending on the version of the Web application (version 2.4 or 2.5) and the setting of the backward-compatible element in the weblogic.xml descriptor file, WebLogic Server will also support JSP 2.0.

JSP Behavior and Buffer Suffix
  • If a Web application version is 2.5 (for example, its web.xml has a version attribute of 2.5) and the backward-compatible flag is set to false, then:

    • All version 2.1 JSP/TAG files will follow the new JSP behavior.

    • All version 2.0 or earlier JSP/TAG files will follow the previous JSP 2.0 or earlier behavior.

  • If a Web application version is 2.5 and the backward-compatible flag is set to true, then all JSP/TAG files will follow the previous JSP 2.0 or earlier behavior.

  • If the Web application version is 2.4 or earlier, then all JSP/TAG files will follow the previous JSP 2.0 or earlier behavior no matter how the backward-compatible flag is set.

Implicit Servlet 2.5 Package Imports

The Servlet 2.5 specification mandates that only the java.lang.*, javax.servlet.*, javax.servlet.jsp.*, and javax.servlet.http.* packages be implicitly imported. In compliance with the Servlet 2.5 specification, WebLogic Server will only import these mandated packages. Whereas, previous releases of WebLogic Server also imported the java.io.*, java.util.*, and javax.servlet.jsp.tagext.* packages.

WebLogic Server will follow the previous 2.4 or earlier behavior and import the non-mandated packages, if any of the following occur:

  • The backward-compatible flag is set to true in the weblogic.xml descriptor file.

  • The Web application version is 2.4 or earlier.

  • The individual JSP/TAG files in a version 2.5 Web application are version 2.0 or earlier.

Web Container Global Configuration

To configure your Web container at a global level, use the WebAppContainerMBean. For information on the WebAppContainerMBean attributes and how to use them to specify domain-wide defaults for all of your Web applications, see the WebAppContainerMBean.