weblogic.xml是我们经常要配置的部署描述符，它的定义如下：
http://www.oracle.com/technology/weblogic/90/weblogic-web-app.xsd
<?xml version="1.0" encoding="UTF-8" ?>
- <xs:schema targetNamespace="http://www.bea.com/ns/weblogic/90" elementFormDefault="qualified" attributeFormDefault="unqualified" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:wls="http://www.bea.com/ns/weblogic/90" xmlns:j2ee="http://java.sun.com/xml/ns/j2ee">
<xs:include schemaLocation="weblogic-j2ee.xsd" />
<xs:include schemaLocation="weblogic-application.xsd" />
<xs:import namespace="http://java.sun.com/xml/ns/j2ee" schemaLocation="http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" />
<xs:element name="weblogic-web-app" type="wls:weblogic-web-appType" />
<xs:element name="description" type="wls:descriptionType" minOccurs="0" />
<xs:element name="weblogic-version" type="wls:weblogic-versionType" minOccurs="0" />
- <!--
The security-role-assigment declares a mapping between an WebApp security role and one or more principals in the WebLogic server. You can also use it to mark a given role as an externally-defined role. 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> Example to mark a given role as a externally defined role <security-role-assignment> <role-name>roleadmin</role-name> <externally-defined/> </security-role-assignment>-->
<xs:element name="security-role-assignment" type="wls:security-role-assignmentType" minOccurs="0" maxOccurs="unbounded" />
- <!--
run-as-role-assignment is used to map a given run-as role-name defined in web.xml to a valid username in the system. The value can be overridden for a given servlet by the run-as-principal-name element in the servlet-descriptor. Note that if the run-as-role-assignment is absent for a given rolename then the webapp container will choose the first principal-name defined in the security-role-assignment, if present, else will use the rolename as the run-as-role-assignment. Example to specify a given principal ("joe") to be used for run-as <run-as-role-assignment> <role-name>RunAsRoleName</role-name> <run-as-principal-name>joe</run-as-principal-name> </run-as-role-assignment>
-->
<xs:element name="run-as-role-assignment" type="wls:run-as-role-assignmentType" minOccurs="0" maxOccurs="unbounded" />
<xs:group ref="wls:reference-descriptorGroup" />
<xs:element name="message-destination-descriptor" type="wls:message-destination-descriptorType" minOccurs="0" maxOccurs="unbounded" />
<xs:element name="session-descriptor" type="wls:session-descriptorType" minOccurs="0" />
<xs:element name="jsp-descriptor" type="wls:jsp-descriptorType" minOccurs="0" />
<xs:element name="auth-filter" type="wls:auth-filterType" minOccurs="0" />
<xs:element name="container-descriptor" type="wls:container-descriptorType" minOccurs="0" />
<xs:element name="charset-params" type="wls:charset-paramsType" minOccurs="0" />
<xs:element name="virtual-directory-mapping" type="wls:virtual-directory-mappingType" minOccurs="0" maxOccurs="unbounded" />
<xs:element name="url-match-map" type="wls:url-match-mapType" minOccurs="0" />
- <!--
security-permission specifies a security permission that is associated with a J2EE Sandbox.-->
<xs:element name="security-permission" type="wls:security-permissionType" minOccurs="0" />
- <!--
The context root of this web application. This is useful for standalone web applications. Normally, you would specify the context-root in the META-INF/application.xml file of a J2EE EAR, however, if this is a standalone web application, you can specify the value here. The application.xml setting takes precedence over this setting.-->
<xs:element name="context-root" type="wls:context-rootType" minOccurs="0" />
- <!--
The wl-dispatch-policy can be used to assign the webapp to a configured execute queue by identifying the execute queue name. This webapp level param can be overridden at the individual servlet/jsp level by per-servlet-dispatch-policy.-->
<xs:element name="wl-dispatch-policy" type="wls:wl-dispatch-policyType" minOccurs="0" />
<xs:element name="servlet-descriptor" type="wls:servlet-descriptorType" minOccurs="0" maxOccurs="unbounded" />
<xs:element name="work-manager" type="wls:work-managerType" minOccurs="0" maxOccurs="unbounded" />
<xs:element name="logging" type="wls:loggingType" minOccurs="0" />
- <!--
library-ref element references a library module, which is intended to be used as a webapp library in the current webapp. Example: <library-ref> <library-name>BaseWebApp</library-name> <specification-version>2.0</specification-version> <implementation-version>8.1beta</implementation-version> <exact-match>false</exact-match> </library-ref> Only the sub-elements: library-name, specification-version (float), implementation-version (String) and exact-match (default false) are relevant to the webapps. Rest of the sub-elements if present will be ignored.-->
<xs:element name="library-ref" type="wls:library-refType" minOccurs="0" maxOccurs="unbounded" />
</xs:choice>
<xs:attribute name="id" type="xs:ID" />
</xs:complexType>
- <!--
The weblogic-version specifies the version of WebLogic to which the weblogic-web-app applies. Used in: weblogic-web-app-->
<!--
Keep generated .java source files-->
<xs:element name="keepgenerated" type="wls:true-falseType" minOccurs="0" />
<!--
package prefix for the generated jsp file-->
<xs:element name="package-prefix" type="xs:string" minOccurs="0" />
<!--
super-class to be used for the generated jsp class-->
<xs:element name="super-class" type="xs:string" minOccurs="0" />
- <!--
Interval at which the jsp servlet class is checked for staleness against the jsp resource default: 1-->
<xs:element name="page-check-seconds" type="j2ee:xsdIntegerType" minOccurs="0" />
- <!--
compiles all modified jsps at webapp application deployment time or server startup time. default: false-->
<xs:element name="precompile" type="wls:true-falseType" minOccurs="0" />
- <!--
This param indicates whether to continue precompilation even when some jsp pages have errors in them. default: false-->
<xs:element name="precompile-continue" type="wls:true-falseType" minOccurs="0" />
- <!--
When set to true, debugging information is printed out to the browser, the command prompt, and WebLogic Server log file. default:true-->
<xs:element name="verbose" type="wls:true-falseType" minOccurs="0" />
- <!--
The name of a directory where WebLogic Server saves the generated Java and compiled class files for a JSP.-->
<xs:element name="working-dir" type="xs:string" minOccurs="0" />
- <!--
When set to false, this parameter ensures that expressions with "null" results are printed as " ". default:true-->
<xs:element name="print-nulls" type="wls:true-falseType" minOccurs="0" />
<xs:element name="backward-compatible" type="wls:true-falseType" minOccurs="0" />
<xs:element name="encoding" type="xs:string" minOccurs="0" />
<xs:element name="exact-mapping" type="wls:true-falseType" minOccurs="0" />
<xs:element name="default-file-name" type="xs:string" minOccurs="0" />
<xs:element name="rtexprvalue-jsp-param-name" type="wls:true-falseType" minOccurs="0" />
<xs:element name="debug" type="wls:true-falseType" minOccurs="0" />
</xs:sequence>
</xs:complexType>
- <!--
This specifies an authentication filter HttpServlet class. This feature has been deprecated. Please use "Servlet Authentication Filters" instead.-->
- <!--
The container-descriptor specifies a list of parameters that affect the behavior of the web application Used in: weblogic-web-app-->
- <!--
The check-auth-on-forward element, by its presence in a weblogic deployment descriptor, indicates that the request dispatcher will check authorization when a request is forwarded. By default authorization check is not performed on forward.-->
<xs:element name="check-auth-on-forward" type="j2ee:emptyType" minOccurs="0" />
- <!--
Whether or not apply filters to dispatched requests. It defaults to "false". This is a backward compatibility flag. Till 8.1 WebLogic applied ServletFilters (if configured for the webapp) on request dispatches (includes/forwards) too. Servlet 2.4 has introduced "Dispatcher" element to make this behavior explicit. The default value being Dispatcher=REQUEST. In order to be spec complaint the default value for FilterDispatchedRequestsEnabled is "false" from 9.0 release onwards. Note that if you are using old descriptors (meaning web.xml does not have version=2.4), then WebLogic automatically uses FilterDispatchedRequestsEnabled = true for the webapps, unless filter-dispatched-requests-enabled is explicitly set to false in weblogic.xml. So the old applications will work fine without any change. Also the migration plugin sets this flag to true, during the migration of old domains to the 9.0 domain. This value can also be set at the domain level for all webapps (WebAppContainerMBean).-->
<xs:element name="filter-dispatched-requests-enabled" type="wls:true-falseType" minOccurs="0" />
- <!--
DEPRECATED: The redirect-content-type element is deprecated since 8.1 and will be removed in a future version of WebLogic. If the redirect-content-type element is set, then the servlet container will set that type on the response for internal redirects (e.g., for welcome files).-->
<xs:element name="redirect-content-type" type="wls:redirect-content-typeType" minOccurs="0" />
- <!--
DEPRECATED: The redirect-content element is deprecated since 8.1 and will be removed in a future version of WebLogic. If the redirect-content element is set, then the servlet container will use that as the value for the user readable data used in a redirect.-->
<xs:element name="redirect-content" type="wls:redirect-contentType" minOccurs="0" />
- <!--
If the redirect-with-absolute-url element is set to false, then the servlet container will not convert the relative url to the absolute url in the location header in a redirect.-->
<xs:element name="redirect-with-absolute-url" type="wls:true-falseType" minOccurs="0" />
- <!--
Whether or not to automatically generate an HTML directory listing if no suitable index file is found. Defaults to "false". Value specified via console will be given precedence over this setting.-->
<xs:element name="index-directory-enabled" type="wls:true-falseType" minOccurs="0" />
- <!--
This element defines the order of sorting for the directory listing generated by weblogic.servlet.FileServlet. Valid values are "NAME" (default), "LAST_MODIFIED" and "SIZE".-->
<xs:element name="index-directory-sort-by" type="wls:index-directory-sort-byType" minOccurs="0" />
- <!--
How often WebLogic checks whether a servlet has been modified, and if so reloads it. -1 is never reload, 0 is always reload. Default to 1 second. Value specified via console will be given precedence over this setting.-->
<xs:element name="servlet-reload-check-secs" type="j2ee:xsdIntegerType" minOccurs="0" />
- <!--
This parameter is used to do metadata caching for resources cached found in the resource path in the webapp scope. This param is to tell how often WebLogic checks whether a resource has been modified, and if so reloads it. -1 is never reload, 0 is always reload. Default to 1 second. Value specified via console will be given precedence over this setting.-->
<xs:element name="resource-reload-check-secs" type="j2ee:xsdIntegerType" minOccurs="0" />
- <!--
Defines the size of the pool used for SingleThreadModel instance pools. Defaults to 5. Value specified via console will be given precedence over this setting. DEPRECATED: since WebLogic 9.0 release, since SingleThreadModel has been deprecated since Servlet 2.4-->
<xs:element name="single-threaded-servlet-pool-size" type="j2ee:xsdNonNegativeIntegerType" minOccurs="0" />
- <!--
If set to true, then runtime mbeans will be created for sessions, otherwise, they will not be created. Defaults to false. Value specified via console will be given precedence over this setting. DEPRECATED: since WebLogic 9.0 release This flag is used only for monitoring by the deprecated way using weblogic.management.runtime.ServletSessionRuntimeMBean, which was expensive and cause memory leaks when the proxies cannot maintain stickiness with the primary server for file and jdbc based persistence. Therefore the usage of this method of monitoring sessions is not recommended. Instead use the new equivalent methods in weblogic.management.runtime.WebAppComponentRuntimeMBean: getServletSessionsMonitoringIds, invalidateServletSession, getSessionLastAccessedTime and getSessionMaxInactiveInterval.-->
<xs:element name="session-monitoring-enabled" type="wls:true-falseType" minOccurs="0" />
- <!--
This setting controls whether session data is cleaned up during redeploy or not. It affects memory and replicated sessions only. Setting the value to true means session data is saved. Setting to false means session data will be destroyed when the web app is redeployed. Sessions will be cleaned up if the webapp is undeployed. The default is false. If you are using side-by-side deployments (new in diablo) then this setting is not required, since the sessions are not affected when a new version of app is deployed.-->
<xs:element name="save-sessions-enabled" type="wls:true-falseType" minOccurs="0" />
- <!--
If true, classes located in the WEB-INF directory of a web-app will be loaded in preference to classes loaded in the application or system classloader. Defaults to false. Value specified via console will be given precedence over this setting.-->
<xs:element name="prefer-web-inf-classes" type="wls:true-falseType" minOccurs="0" />
- <!--
The default mime type to be used for all extensions without an explicit Mime map in web.xml-->
<xs:element name="default-mime-type" type="wls:default-mime-typeType" minOccurs="0" />
- <!--
A true value for client-cert-proxy-enabled overrides the value for ClientCertProxyEnabled in webserver/cluster level for each webapp. A value of true causes weblogic server to pass identity certificates from clients to the backend servers. It also tells the weblogic server wether to honor or discard the incoming WL-Proxy-Client-Cert header. A proxy-server plugin encodes each identify certification in the WL-Proxy-Client-Cert header and passes the header to the backend WebLogic Server instances. Each WebLogic Server instance takes the certificate information from the header, trusting that it came from a secure source, and uses that information to authenticate the user. For the backend weblogic servers too this parameter has to be turned on (either in cluster/server level or webapp level). If you specify a true value, 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. Specifying true without using a connection filter creates a potential security vulnerability because the WL-Proxy-Client-Cert header can be spoofed.-->
<xs:element name="client-cert-proxy-enabled" type="wls:true-falseType" minOccurs="0" />
- <!--
relogin-enabled is a backward compatibility parameter. If a user has logged in already and tries to access a resource for which he/she doesn't have previledges, then spec requires a FORBIDDEN (403) response. In the earlier releases (till 8.1) weblogic server used to present the login form again so that the end user can relogin as a more previledged user. This value can also be set at the domain level for all webapps (WebAppContainerMBean).-->
<xs:element name="relogin-enabled" type="wls:true-falseType" minOccurs="0" />
- <!--
In the security-constraints elements defined in web.xml descriptor of web-applications, 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 the past releases role-name = "*" was treated as all users/roles defined in the realm. This param is a backward compatibility switch to restore old behavior. Default behavior is one required by the spec, meaning all roles defained in the web application. The value specified in weblogic.xml takes precendence over value defined in the WebAppContainerMBean.-->
<xs:element name="allow-all-roles" type="wls:true-falseType" minOccurs="0" />
- <!--
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 (default false). This parameter applies only on Windows.-->
<xs:element name="native-io-enabled" type="wls:true-falseType" minOccurs="0" />
- <!--
The parameter minimum-native-file-size applies only when native-io-enabled is true. It sets the minimum file size for using native I/O. If the file being served is larger than this value, native I/O is used. If you do not specify this parameter, a value of 4096 (4K) is used as default.-->
<xs:element name="minimum-native-file-size" type="xs:long" minOccurs="0" />
- <!--
When disable-implicit-servlet-mappings flag is turned on, the webapp container doesn't create implicit mappings for internal servlets (*.jsp, *.class etc), except the default servlet mapping. default = "false". Typical usecase when you would want to turn off implicit mappings is when configuring HttpClusterServlet or HttpProxyServlet.-->
<xs:element name="disable-implicit-servlet-mappings" type="wls:true-falseType" minOccurs="0" />
- <!--
Location of temporary directory for the webapp, as returned by "javax.servlet.context.tempDir" context attribute-->
<xs:element name="temp-dir" type="xs:string" minOccurs="0" />
- <!--
When optimistic-serialization is turned on, WebLogic server does not serialize-deserialize context and request attributes upon getAttribute(name), when request gets dispatched across servlet contexts. This means you will need to make sure that the attributes common to webapps are scoped to a common parent classloader; e.g. Application scoped or place in system classpath if the two webapps do not belong to the same application. When OptimisticSerialization is turned off (default value) WebLogic server serialize-deserialize context and request attributes upon getAttribute(name) to avoid possibility of ClassCastExceptions. optimistic-serialization value can also be specified at domain level in WebAppContainerMBean, which applies for all webapps. The value in weblogic.xml, if specified, overrides the domain level value. defaults to "false".-->
<xs:element name="optimistic-serialization" type="wls:true-falseType" minOccurs="0" />
- <!--
<p> retain-original-url is used in FORM based authentication scenarios. When this property is set to true, after a successful authentication, Weblogic Server will redirect back to the web resource (page/servlet) retaining the protocol (http/https) used to access the protected resource in the original request. If set to false (which is the default value), Weblogic Server will redirect back to the protected resource using the current protocol. retain-original-url value can also be specified at domain level in WebAppContainerMBean, in which case it will be applied to all the webapps in the domain. defaults to "false". </p>-->
<xs:element name="retain-original-url" type="wls:true-falseType" minOccurs="0" />
- <!--
If the show-archived-real-path-enabled element is set to false, then the servlet container will return real path of files in archived web apps as null.-->
<xs:element name="show-archived-real-path-enabled" type="wls:true-falseType" minOccurs="0" />
</xs:sequence>
<xs:attribute name="id" type="xs:ID" />
</xs:complexType>
- <!--
DEPRECATED: The redirect-content-type element is deprecated since 8.1 and will be removed in a future version of WebLogic. If the redirect-content-type element is set, then the servlet container will set that type on the response for internal redirects (e.g., for welcome files).-->
- <!--
DEPRECATED: The redirect-content element is deprecated since 8.1 and will be removed in a future version of WebLogic. If the redirect-content element is set, then the servlet container will use that as the value for the user readable data used in a redirect.-->
- <!--
This element defines the order of sorting for the directory listing generated by weblogic.servlet.FileServlet. Valid values are "NAME" (default), "LAST_MODIFIED" and "SIZE".-->
- <!--
The default mime type to be used for all extensions without an explicit Mime map in web.xml-->
- <!--
The charset-params element parameters defines the codeset that will be used for non-unicode operations. Used in: weblogic-web-app-->
<xs:element name="input-charset" type="wls:input-charsetType" minOccurs="0" maxOccurs="unbounded" />
<xs:element name="charset-mapping" type="wls:charset-mappingType" minOccurs="0" maxOccurs="unbounded" />
</xs:sequence>
<xs:attribute name="id" type="xs:ID" />
</xs:complexType>
- <!--
The input-charset element defines what charset will be used to process POST data for a particular resource-->
<xs:element name="resource-path" type="wls:resource-pathType" />
<xs:element name="java-charset-name" type="wls:java-charset-nameType" />
</xs:sequence>
<xs:attribute name="id" type="xs:ID" />
</xs:complexType>
- <!--
The charset-mapping element defines a mapping between IANA names and Java names for charsets-->
<xs:element name="iana-charset-name" type="wls:iana-charset-nameType" />
<xs:element name="java-charset-name" type="wls:java-charset-nameType" />
</xs:sequence>
<xs:attribute name="id" type="xs:ID" />
</xs:complexType>
- <!--
By specifying virtual directory mappings you can change the default docroot for certain requests. virtual-directory-mapping defines a mapping between url pattern and a new doc root-->
<xs:element name="local-path" type="wls:local-pathType" />
<xs:element name="url-pattern" type="j2ee:url-patternType" maxOccurs="unbounded" />
</xs:sequence>
<xs:attribute name="id" type="xs:ID" />
</xs:complexType>
<!--
The local-path element specifies a physical location on the disk.-->
- <!--
Using url-match-map you can specify your own class for url pattern matching. By default weblogic uses weblogic.servlet.utils.ServletMapping which is based on J2EE standards. So using url-match-map you could overide default behaviour or write your own url pattern matcher. The new class has to implement weblogic.servlet.utils.URLMapping interface.-->
- <!--
The context root of this web application. This is useful for standalone web applications. Normally, you would specify the context-root in the META-INF/application.xml file of a J2EE EAR, however, if this is a standalone web application, you can specify the value here. The application.xml setting takes precedence over this setting.-->
- <!--
The wl-dispatch-policy can be used to assign the webapp to a configured execute queue by identifying the execute queue name. This webapp level param can be overridden at the individual servlet/jsp level by per-servlet-dispatch-policy.-->
<xs:element name="servlet-name" type="j2ee:servlet-nameType" />
- <!--
The run-as-principal-name element contains the name of a principal against the run-as role-name defined in web.xml.-->
<xs:element name="run-as-principal-name" type="wls:run-as-principal-nameType" minOccurs="0" />
- <!--
init-as-principal-name is equivalent to run-as-principal-name for the init method for servlets. The identity specified here should be a valid username in the system. If init-as-principal-name is not specified the container will use the run-as-principal-name.-->
<xs:element name="init-as-principal-name" type="wls:init-as-principal-nameType" minOccurs="0" />
- <!--
destroy-as-principal-name is equivalent to run-as-principal-name for the destroy method for servlets. The identity specified here should be a valid username in the system. If destroy-as-principal-name is not specified the container will use the run-as-principal-name.-->
<xs:element name="destroy-as-principal-name" type="wls:destroy-as-principal-nameType" minOccurs="0" />
- <!--
The dispatch-policy element can be used to assign a given servlet to a configured execute-queue by identifying the execute queue name. This setting overrides the webapp level dispatch policy defined by wl-dispatch-policy.-->
<xs:element name="dispatch-policy" type="wls:dispatch-policyType" minOccurs="0" />
</xs:sequence>
<xs:attribute name="id" type="xs:ID" />
</xs:complexType>
- <!--
init-as-principal-name is equivalent to run-as-principal-name for the init method for servlets. The identity specified here should be a valid username in the system. If init-as-principal-name is not specified the container will use the run-as-principal-name.-->
- <!--
destroy-as-principal-name is equivalent to run-as-principal-name for the destroy method for servlets. The identity specified here should be a valid username in the system. If destroy-as-principal-name is not specified the container will use the run-as-principal-name.-->
</xs:schema>
