This appendix provides 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 10.3.6 automatically selects the default values of the deployment descriptor elements.
This appendix includes the following sections that describe the complex deployment descriptor elements that can be defined in the weblogic.xml
deployment descriptor under the root element <weblogic-web-app>
:
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.3/weblogic-web-app.xsd
.
The description
element is a text description of the Web application.
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.
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-1 security-role-assignment Elements
Element | Required/Optional | Description |
---|---|---|
<role-name> |
Required |
Specifies the name of a security role. |
<principal-name> |
Required if |
Specifies the name of a principal that is defined in the security realm. You can use multiple |
<externally-defined> |
Required if |
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.
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.
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.
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.
The following table describes the elements you can define within a ejb-reference-description
element.
The following table describes the elements you can define within a service-reference-description
element.
Table B-6 service-reference-description Elements
Element | Required/Optional | Description |
---|---|---|
<service-ref-name> |
||
<wsdl-url> |
||
|
The <name> <value> |
|
|
The <port-name> <stub-property> <call-property> |
The session-descriptor
elements that define parameters for servlet sessions.
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 |
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. |
sharing-enabled |
false |
Enables Web applications to share HTTP sessions when the value is set to This element is ignored if turned on at the Web application level. |
|
false |
Enables the debugging feature for HTTP sessions. The default value is |
id-length |
52 |
Sets the size of the session ID. The minimum value is 8 bytes and the maximum value is 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. For more information, see URL Rewriting and Wireless Access Protocol (WAP) |
|
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 To configure bound in-memory servlet session use, you set the limitation in the The default is |
cookies-enabled |
true |
Use of session cookies is enabled by default and is recommended, but you can disable them by setting this property to |
cookie-name |
JSESSIONID |
Defines the session tracking cookie name. Defaults to |
cookie-path |
null |
Defines the session tracking cookie path. If not set, this attribute defaults to |
cookie-domain |
null |
Specifies the domain for which the cookie is valid. For example, setting The domain name must have at least two components. Setting a name to If not set, this attribute defaults to the server that issued the cookie. For more information, see |
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 |
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 Chapter 10, "Using Sessions and Session Persistence". |
persistent-store-type |
memory |
Sets the persistent store method to one of the following options:
|
persistent-store-cookie-name |
WLCOOKIE |
Sets the name of the cookie used for cookie-based persistence. The For more information, 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 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 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-store-table |
wl_servlet_sessions |
Specifies the database table name used to store JDBC-based persistent sessions. This applies only when The |
jdbc-column-name-max-inactive-interval |
Serves as an alternative name for the |
|
jdbc-connection-timeout-secs |
120 |
Note: This is a deprecated item for this release. Sets the time, in seconds, that WebLogic Server waits before timing out a JDBC connection, where x is the number of seconds between. |
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 "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 |
|
Used in Example: This element is useful for tagging session run-time information for different sessions. |
|
|
|
Specifies whether |
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-8 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.
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 modified 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 modified 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 |
verbose |
true |
When set to |
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 |
print-nulls |
null |
When set to false, this parameter ensures that expressions with "null" results are printed as " ". |
backward-compatible |
true |
When set to For more information, see Backwards Compatibility Flags. |
encoding |
ISO-8859-1 for JSP pages and UTF-8 for JSPX pages |
Specifies the default character set used in the JSP page. Use standard Java character set names (see 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:
|
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. |
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 |
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 |
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.The <container-descriptor>
element specifies a list of parameters that affect the behavior of the Web application.
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 does not recommend that you enable the check-auth-on-forward property.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.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.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
.
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
.
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 Administration Console will always take precedence over a manually specified value.
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 Administration Console are given precedence.
Note:
If the resource is a JSP, and ifpage-check-seconds
is specified in the jsp-descriptor
element, the page-check-seconds
value is used to determine reload time for the JSP file.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.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 Administration Console takes precedence over a value set manually.
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.
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 Administration Console will take precedence over a value set manually.
Note:
Neitherprefer-application-packages
nor prefer-application-resources
can be specified when prefer-web-inf-classes
is turned on in weblogic.xml
.The <prefer-application-packages
> element specifies a list of packages for classes that must always be loaded from the application. For more information, 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_0.xsd http://xmlns.oracle.com/weblogic/weblogic-web-app http://xmlns.oracle.com/weblogic/weblogic-web-app/1.2/weblogic-web-app.xsd"> <wls:weblogic-version>10.3.5</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.
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. For more information, 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.
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.
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.
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.
In the security-constraints elements defined in 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
.
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.
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
.
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
.
The temp-dir
element specifies the location of the temporary directory for the Web application, as returned by the "javax.servlet.context.tempDir"
attribute.
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
.
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
.
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>
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.
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
.
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>
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>
For more information, see Determining the Encoding of an HTTP Request.
The following table describes the elements you can define within a <input-charset>
element.
Table B-9 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> |
Required |
Specifies the Java characters set to use. |
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>
For more information, 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-10 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> |
Required |
Specifies the Java characters set to use. |
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-11 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.
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://foo.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>
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:
https://download.oracle.com/javase/1.3/docs/guide/security/PolicyFiles.html#FileSyntax
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.
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 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.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 at the individual servlet or jsp level by using the per-servlet-dispatch-policy
element.
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-12 servlet-descriptor Elements
Element | Required/Optional | Description |
---|---|---|
<servlet-name> |
Required |
Specifies the servlet name as defined in the servlet element of the |
<run-as-principal-name> |
Optional |
Contains the name of a principal against the |
<init-as-principal-name> |
Optional |
Equivalent to |
<destroy-as-principal-name> |
Optional |
Equivalent to |
<dispatch-policy> |
Optional |
This is a deprecated element. Used to assign a given servlet to a configured |
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-13 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:
|
min-threads-constraint, min-threads-constraint-name |
Optional |
You can choose between the following two elements:
|
max-threads-constraint, max-threads-constraint-name |
Optional |
You can choose between the following two elements:
|
capacity, capacity-name |
Optional |
You can choose between the following two elements:
|
The logging
element is a sub-element of the <weblogic-web-app>
element. You can define the following elements within the logging
element.
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 Failure to specify this value will result in WebLogic Server using its defined default value. Value Range: Default Value: |
rotation-type |
Optional |
Sets the file rotation type. Values are
Default Value: |
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 If you enable Value Range:
|
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 Default Value: |
file-size-limit |
Optional |
The size that triggers the server to move log messages to a separate file. (Requires that you specify a Default Value: |
rotate-log-on-startup |
Optional |
Specifies whether a server rotates its log file during its startup cycle. Value Range:
|
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 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 Default Value: |
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-15 library-ref Elements
Element | Required/Optional | Description |
---|---|---|
library-name |
Required |
Provides the library name for the library module reference. The default value is |
specification-version |
Optional |
Provides the specification version for the library module reference. The default value is |
implementation-version |
Optional |
Provides the implementation version for the library module reference. The default value is |
|
Optional |
The default value is |
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 WebLogic Server.
Element | Required/Optional | Description |
---|---|---|
<enabled> |
Optional |
Set to |
<refresh-interval> |
Optional |
FastSwap checks for changes in application classes when an incoming HTTP request is received. Subsequent HTTP requests arriving within the |
<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. |
For WebLogic Server, backward compatibility for WebLogic Server 9.2 or earlier is supported via the backward-compatible
element within the jsp-descriptor
element.
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.
If a Web application version is 2.5 (for example, its web.xml
has a version attribute of 2.5) and the backward-compatibility
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-compatibility
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-compatibility
flag is set.
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.
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
.