|
|
|
|
| |
Deploying and Configuring Web Applications
The following sections describes how to configure and deploy Web Applications:
A Web Application contains an application's resources such as servlets, JavaServer Pages (JSP), JSP tag libraries, and static resources such as HTML pages and image files. A Web Application can also define links to resources outside of the application such as Enterprise JavaBeans (EJB). Web Applications use a standard J2EE deployment descriptor in conjunction with a WebLogic-specific deployment descriptor to define the resources and their operating parameters.
JSP pages and HTTP servlets can access all services and APIs available in WebLogic Server. These services include EJBs, database connections via Java Database Connectivity (JDBC), JavaMessaging Service (JMS), XML, and more.
Web Applications use a standard directory structure defined in the J2EE specification and can be deployed as a collection of files that use this directory structure (this type of deployment is called exploded directory format) or as an archived file called a .war file. Deploying a Web Application in exploded directory format is recommended primarily for use while developing your application. Deploying a Web Application as a .war file is recommended primarily for production environments.
Steps to Deploy a Web Application
For detailed instructions, see Writing the Web Application Deployment Descriptor.
For detailed instructions on creating the WebLogic-specific deployment descriptor, see "Writing the WebLogic-Specific Deployment Descriptor".
jar cv0f myWebApp.war .
This command creates a Web Application archive file called myWebApp.war.
To deploy a Web Application in archived war format using the Administration Console (you cannot deploy a Web Application in exploded directory format using this procedure):
This procedure creates a new entry in the config.xml file containing the configuration for your Web Application and copies your Web Application to an internal location. To deploy a Web Application (in either archived or exploded format) by copying:
Note: If you deploy your Web Application in expanded form, read
Modifying Components of a Web Application. Note: If you modify any component of a .war file in its original location in your file system, you must redeploy your.war file by uploading it again from the Administration Console.
You develop your Web Application within a specified directory structure so that it can be archived and deployed on WebLogic Server, or another Servlet 2.2 compliant server. All servlets, classes, static files, and other resources belonging to a Web Application are organized under a directory hierarchy. The root of this hierarchy defines the document root of your Web Application. All files under this root directory can be served to the client, except for files under the special directories WEB-INF and META-INF located in the root directory. Name the root directory with the name of your Web Application.This name will be used to resolve requests for components of the Web Application.
Private files should be located in the WEB-INF directory, under the root directory. All files under WEB-INF are private, and are not served to a client.
Deploying and Redeploying Web Applications
The procedure you use to deploy or redeploy a Web Application depend on whether the Web Application is deployed in exploded or archived format. When you modify a component of a Web Application you must also redeploy the Web Application on WebLogic Server in order to serve the modified component. These procedures are discussed in this section.
Modifying Components of a Web Application
When you modify any component of a Web Application (such as a servlet class, HTML file, JSP file, or one of the deployment descriptors), the new version of the component cannot be served by Weblogic Server until you redeploy the Web Application. The procedure used for redeployment depends on whether the Web Application is deployed as an archived .war file or deployed in exploded directory format.
When you edit a component of a Web Application that is deployed as a war file, you will need to re-jar the archive and then upload the .war file again.by using one of the procedures described in step 5..
Components in Exploded Directory Format
When you edit a component of a Web Application that is deployed in the exploded directory format, keep in mind that WebLogic Server updates components differently:
Note: JSP files are redeployed automatically only to the administration server. If you want JSPs redeployed to managed servers targeted by the Web Application, you must redeploy the Web Application. For more information, see Redeploying a Web Application.
Redeploying a Web Application
Use one of the following three procedures to redeploy a Web Application:
Note: Redeploying a Web Application also redeploys the Web Application to all managed servers targeted by this Web Application.
Deploying Web Applications as Part of an Enterprise Application
You can deploy a Web Application as part of an Enterprise Application. An Enterprise Application is a J2EE deployment unit that bundles together Web Applications, EJBs, and Resource Adaptors into a single deployable unit. (For more information on Enterprise Applications, see Packaging Components and Applications .) If you deploy a Web Application as part of an Enterprise Application, you can specify a string that is used in place of the actual name of the Web Application when WebLogic Server resolves a request for the Web Application. You specify the new name with the <context-root> element in the application.xml deployment descriptor for the Enterprise Application. For more information, see Client Application Deployment Descriptor Elements.
For example, for a Web Application called oranges, you would typically request a resource from the oranges Web Application with a URL like:
http://host:port/oranges/catalog.jsp.
If the oranges Web Application is packaged in an Enterprise Application, you can specify a value for the <context-root> as shown in the following example:
<module>
<web>
<web-uri>oranges.war</web-uri>
<context-root>fruit</context-root>
</web>
</module>
You would then use the following URL to access the same resource from the oranges Web Application:
http://host:port/fruit/catalog.jsp
You construct the URL used to access a Web Application from a client by using the following pattern:
http://hoststring/ContextPath/servletPath/pathInfo
If you are using virtual hosting, you can substitute the virtual host name for the hoststring portion of the URL.
For additional information, see How WebLogic Server Resolves HTTP Requests.
Servlets are registered and configured as a part of a Web Application. To register a servlet, you add several entries to the Web Application deployment descriptor. The first entry, under the <servlet> element defines a name for the servlet and the compiled class that executes the servlet. This element also contains definitions for initialization parameters and security roles for the servlet.The second entry, under the <servlet-mapping> element defines the URL pattern that calls this servlet.
For complete instructions on editing the Web Application deployment descriptor, see:
Servlet mapping controls how you access a servlet. The following examples demonstrate some of the ways you can use servlet mapping in your Web Application. In the examples, a set of servlet configurations and mappings (from the web.xml deployment descriptor) is followed by a table (see url-patterns and Servlet Invocation) showing the URLs used to invoke these servlets.
Listing 8-1 Servlet Mapping Example
<servlet>
<servlet-name>watermelon</servlet-name>
<servlet-class>myservlets.watermelon</servlet-class>
</servlet>
<servlet>
<servlet-name>garden</servlet-name>
<servlet-class>myservlets.garden</servlet-class>
</servlet>
<servlet>
<servlet-name>list</servlet-name>
<servlet-class>myservlets.list</servlet-class>
</servlet>
<servlet>
<servlet-name>kiwi</servlet-name>
<servlet-class>myservlets.kiwi</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>watermelon</servlet-name>
<url-pattern>/fruit/summer/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>garden</servlet-name>
<url-pattern>/seeds/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>list</servlet-name>
<url-pattern>/seedlist</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>kiwi</servlet-name>
<url-pattern>*.abc</url-pattern>
</servlet-mapping>
|
URL |
Servlet |
|---|---|
|
http://host:port/mywebapp/fruit/summer/index.html |
watermelon |
|
http://host:port/mywebapp/fruit/summer/index.abc |
watermelon |
|
http://host:port/mywebapp/seedlist |
list |
|
http://host:port/mywebapp/seedlist/index.html |
The default servlet, if configured, or an HTTP 404 file not found error message If the mapping for the list servlet had been /seedlist*, the list servlet would be invoked. |
|
http://host:port/mywebapp/seedlist/pear.abc |
kiwi If the mapping for the list servlet had been /seedlist*, the list servlet would be invoked. |
|
http://host:port/mywebapp/seeds |
garden |
|
http://host:port/mywebapp/seeds/index.html |
garden |
|
http://host:port/mywebapp/index.abc |
kiwi |
Servlet Initialization Parameters
You define initialization parameters for servlets in the Web Application deployment descriptor, in the <init-param> element of the <servlet> element, using <param-name> and <param-value> tags. For example:
Listing 8-2 Example of Configuring Servlet Initialization Parameters
<servlet>
<servlet-name>HelloWorld2</servlet-name>
<servlet-class>examples.servlets.HelloWorld2</servlet-class>
<init-param>
<param-name>greeting</param-name>
<param-value>Welcome</param-value>
</init-param>
<init-param>
<param-name>person</param-name>
<param-value>WebLogic Developer</param-value>
</init-param>
</servlet>
For more information on editing the Web Application deployment descriptor, see Writing Web Applications Deployment Descriptors
You deploy JavaServer Pages (JSP) files by placing them in the root (or in a subdirectory below the root) of a Web Application. Additional JSP configuration parameters are defined in the <jsp-descriptor> element of the WebLogic-specific deployment descriptor, weblogic.xml. These parameters define the following functionality:
For a complete description of these parameters, see JSP Parameter Names and Values.
For instructions on editing the weblogic.xml file, see Creating the WebLogic-Specific Deployment Descriptor.
Weblogic Server, in accordance with the Servlet 2.2 specification provides the ability to create and use custom JSP tags. Custom JSP tags are Java classes that can be called from within a JSP page. To create custom JSP tags, you place them in a tag library and define their behavior in a tag library descriptor (TLD) file. This TLD must be made available to the Web Application containing the JSP by defining it in the Web Application deployment descriptor. It is a good idea to place the TLD file in the WEB-INF directory of your Web Application, because that directory is never available publicly.
In the Web Application deployment descriptor, you define a URI pattern for the tag library. This URI pattern must match the value in the taglib directive in your JSP pages. You also define the location of the TLD. For example, if the taglib directive in the JSP page is:
<%@ taglib uri="myTaglib" prefix="taglib" %>
and the TLD is located in the WEB-INF directory of your Web Application, you would create the following entry in the Web Application deployment descriptor:
<taglib>
<taglib-uri>myTaglib</taglib-uri>
<tablig-location>WEB-INF/myTLD.tld</taglib-location>
</taglib>
For more information on creating custom JSP tag libraries, see Programming JSP Tag Extensions.
WebLogic Server also includes several custom JSP tags that you can use in your applications. These tags perform caching, facilitate query parameter-based flow control, and facilitate iterations over sets of objects. For more information, see Using Custom WebLogic JSP Tags.
WebLogic Server allows you to set a page that is served by default if the requested URL is a directory. This feature can make your site easier to use, because the user can type a URL without giving a specific filename.
Welcome pages are defined at the Web Application level. If your Server is hosting multiple Web Applications, you need to define welcome pages separately for each Web Application.
To define Welcome pages, edit the Web Application deployment descriptor, web.xml. For more information, see Welcome Files .
If you do not define Welcome Pages, WebLogic Server looks for the following files in the following order and serves the first one it finds:
For more information, see How WebLogic Server Resolves HTTP Requests
Each Web Application has a default servlet. This default servlet can be a servlet that you specify, or, if you do not specify a default servlet, WebLogic Server uses an internal servlet called the FileServlet as the default servlet. For more information on the FileServlet see How WebLogic Server Resolves HTTP Requests.
You can register any servlet as the default servlet. Writing your own default servlet allows you to use your own logic to decide how to handle a request that falls back to the default servlet.
Setting up a default servlet replaces the FileServlet and should be done carefully because the FileServlet is used to serve most files, such as text files, HTML file, image files, and more. If you expect your default servlet to serve such files, you will need to write that functionality into your default servlet.
To set up a user-defined default servlet:
If you also want your default servlet to respond to files ending in *.htm or *.html, then you must map those extensions to your default servlet, in addition to mapping "/". For instructions on mapping servlets, see
Configuring Servlets.
How WebLogic Server Resolves HTTP Requests
When WebLogic Server receives an HTTP request, it resolves the request by parsing the various parts of the URL and using that information to determine which Web Application and or server should handle the request. The examples below various combinations of requests for Web Applications, virtual hosts, servlets, JSPs and static files and the resulting response.
Note: If you package your Web Application as part of an Enterprise Application you can provide an alternate name for a Web Application that is used to resolve requests to the Web Application. For more information, see Deploying Web Applications as Part of an Enterprise Application.
The table below provides some sample URLs and the file that is served by WebLogic Server. The Index Directories Checked column refers to the Index Directories attribute that controls whether or not a directory listing is served if no file is specifically requested. You set Index Directories using the Administration Console, on the Web Applications node, under the Configuration/Files tab.
|
URL |
Index Directories Checked? |
This file is served in response |
|---|---|---|
|
http://host:port/apples |
no |
Welcome file* defined in the apples Web Application. |
|
http://host:port/apples |
yes |
Directory listing of the top level directory of the apples Web Application. |
|
http://host:port/oranges/naval |
does not matter |
Servlet mapped with <url-pattern> of /naval in the oranges Web Application. There are additional considerations for servlet mappings. For more information, see Configuring Servlets. |
|
http://host:port/naval |
does not matter |
Servlet mapped with <url-pattern> of /naval in the oranges Web Application and oranges is defined as the default Web Application. For more information, see Configuring Servlets. |
|
http://host:port/apples/pie.jsp |
does not matter |
pie.jsp, from the top-level directory of the apples Web Application. |
|
http://host:port |
yes |
Directory listing of the top level directory of the default Web Application |
|
http://host:port |
no |
Welcome file* from the default Web Application. |
|
http://host:port/apples/myfile.html |
does not matter |
myfile.html, from the top level directory of the apples Web Application. |
|
http://host:port/myfile.html |
does not matter |
myfile.html, from the top level directory of the default Web Application. |
|
http://host:port/apples/images/red.gif |
does not matter |
red.gif, from the images subdirectory of the top-level directory of the apples Web Application. |
|
http://host:port/myFile.html |
does not matter |
Error 404 For more information, see Customizing HTTP Error Responses. |
|
http://www.fruit.com/ |
no |
Welcome file* from the default Web Application for a virtual host with a host name of www.fruit.com. |
|
http://www.fruit.com/ |
yes |
Directory listing of the top level directory of the default Web Application for a virtual host with a host name of www.fruit.com. |
|
http://www.fruit.com/oranges/myfile.html |
does not matter |
myfile.html, from the oranges Web Application that is targeted to a virtual host with host name www.fruit.com. |
* For more information, see Configuring Welcome Pages.
Customizing HTTP Error Responses
You can configure WebLogic Server to respond with your own custom Web pages or other HTTP resources when particular HTTP errors or Java exceptions occur, instead of responding with the standard WebLogic Server error response pages.
You define custom error pages in the <error-page> element of the Web Application deployment descriptor (web.xml). For more information on error pages, see error-page Element
Using CGI with WebLogic Server
WebLogic Server provides functionality to support your legacy Common Gateway Interface (CGI) scripts. For new projects, we suggest you use HTTP servlets or JavaServer Pages.
WebLogic Server supports all CGI scripts via an internal WebLogic servlet called the CGIServlet. To use CGI, register the CGIServlet in the Web Application deployment descriptor (see Example Entries to Be Included in the Web Application Deployment Descriptor when Registering the CGIServlet). For more information, see Configuring Servlets.
Configuring WebLogic Server to use CGI
To configure CGI in WebLogic Server:
Listing 8-3 Example Entries to Be Included in the Web Application Deployment Descriptor when Registering the CGIServlet
<servlet>
<servlet-name>CGIServlet</servlet-name>
<servlet-class>weblogic.servlet.CGIServlet</servlet-class>
<init-param>
<param-name>cgiDir</param-name>
<param-value>
/bea/wlserver6.0/config/mydomain/applications/myWebApp/cgi-bin
</param-value>
</init-param>
<init-param>
<param-name>*.pl</param-name>
<param-value>/bin/perl.exe</param-value>
</init-param>
</servlet>
...
<servlet-mapping>
<servlet-name>CGIServlet</servlet-name>
<url-pattern>/cgi-bin/*</url-pattern>
</servlet-mapping>
The URL used to request a perl script must follow the pattern:
http://host:port/myWebApp/cgi-bin/myscript.pl
Serving Resources from the CLASSPATH with the ClasspathServlet
If you need to serve classes or other resources from the system CLASSPATH, or from the WEB-INF/classes directory of a Web Application, you can use a special servlet called the ClasspathServlet. The ClasspathServlet is useful for applications that use applets or RMI clients and require access to server-side classes. The ClasspathServlet is implicitly registered and available from any application.
There are two ways that you can use the ClasspathServlet:
http://server:port/classes/my/resource/myClass.class
http://server:port/myWebApp/classes/my/resource/myClass.class
In this case, the resource is located in the following directory, relative to the root of the Web Application:
WEB-INF/classes/my/resource/myClass.class
Warning: Since the ClasspathServlet serves any resource located in the system CLASSPATH, do not place resources that should not be publicly available in the system CLASSPATH.
When you use WebLogic Server as your primary Web server, you may also want to configure WebLogic Server to pass on, or proxy, certain requests to a secondary HTTP server, such as Netscape Enterprise Server, Apache, Microsoft Internet Information Server, or another instance of WebLogic Server. Any request that gets proxied is redirected to a specific URL.You can even proxy to another Web server on a different machine.You proxy requests based on the URL of the incoming request.
The HttpProxyServlet (provided as part of the distribution) takes an HTTP request, redirects it to the proxy URL, and sends the response to the client's browser back through WebLogic Server. To use the proxy, you must configure it in a Web Application and deploy that Web Application on the WebLogic Server that is redirecting requests.
Setting Up a Proxy to a Secondary HTTP Server
To set up a proxy to a secondary HTTP server:
If you set the <url-pattern> to "/", then any request that cannot be resolved by WebLogic Server is proxied to the remote server. However, you must also specifically map the following extensions: *.jsp, *.html, and *.html if you want to proxy files ending with those extensions.
Sample Deployment Descriptor for the Proxy Servlet
The following is an sample of a Web Applications deployment descriptor for using the Proxy Servlet.
Listing 8-4 Sample web.xml for Use with ProxyServlet
<! DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.
//DTD Web Application 2.2//EN"
"http://java.sun.com/j2ee/dtds/web-app_2_2.dtd";>
<web-app>
<servlet>
<servlet-name>ProxyServlet</servlet-name>
<servlet-class>weblogic.t3.srvr.HttpProxyServlet</servlet-class>
<init-param>
<param-name>redirectURL</param-name>
<param-value>
http://tehama:7001
</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>ProxyServlet</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>ProxyServlet</servlet-name>
<url-pattern>*.jsp</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>ProxyServlet</servlet-name>
<url-pattern>*.htm</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>ProxyServlet</servlet-name>
<url-pattern>*.html</url-pattern>
</servlet-mapping>
</web-app>
Proxying Requests to a WebLogic Cluster
The HttpClusterServlet (provided with the WebLogic Server distribution) proxies requests from a WebLogic Server to other WebLogic Servers in a WebLogic Cluster. The HttpClusterServlet provides load balancing and failover for the proxied HTTP requests. For additional information on servlets and WebLogic Clusters, see Understanding HTTP Session State Replication.
Setting Up the HttpClusterServlet
To set up the HttpClusterServlet:
The class name for the HttpClusterServlet is weblogic.servlet.internal.HttpClusterServlet. A
Sample Deployment Descriptor for the HttpClusterServlet is included below.
If you set the url-pattern to "/", then any request that cannot be resolved by WebLogic Server is proxied to the remote server. However, you must also specifically map the following extensions: *.jsp, *.html, and *.html, if you want to proxy files ending with those extensions. Another way to set up the url-pattern is to map a url-pattern such as /foo and then set the pathTrim parameter to foo, which removes foo from the proxied URL.
Table 8-3 HttpClusterServlet Parameters
The following is a sample of a Web Applications deployment descriptor, web.xml, for using the HttpClusterServlet:
Listing 8-5 Sample web.xml for Use with HttpClusterServlet
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.
//DTD Web Application 2.2//EN" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd";>
<web-app>
<servlet>
<servlet-name>HttpClusterServlet</servlet-name>
<servlet-class>
weblogic.servlet.internal.HttpClusterServlet
</servlet-class>
<init-param>
<param-name>defaultServers</param-name>
<param-value>
myserver1:7736:7737|myserver2:7736:7737|myserver:7736:7737
</param-value>
</init-param>
<init-param>
<param-name>DebugConfigInfo</param-name>
<param-value>ON</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>HttpClusterServlet</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>HttpClusterServlet</servlet-name>
<url-pattern>*.jsp</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>HttpClusterServlet</servlet-name>
<url-pattern>*.htm</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>HttpClusterServlet</servlet-name>
<url-pattern>*.html</url-pattern>
</servlet-mapping>
</web-app>
Configuring Security in Web Applications
You can secure a Web Application by using authentication, by restricting access to certain resources in the Web Application, or by using security calls in your servlet code. Several types of security realms can be used. Security realms are discussed in the document Security Fundamentals. Note that a security realm is shared across multiple virtual hosts.
Setting Up Authentication for Web Applications
You define Authentication for Web Applications in the Web Application deployment descriptor using the <login-config> element. In this element you define the security realm containing the user credentials, the method of authentication, and the location of resources for authentication. For information on setting up a security realm, see Security Fundamentals.
To set up authentication for Web Applications:
ConfigurationOther tab of the Administration Console is used. For more
information, see <login-config>.
Multiple Web Applications, Cookies, and Authentication
By default, WebLogic Server assigns the same cookie name (JSESSIONID) to all Web Applications. When you use any type of authentication, all Web Applications that use the same cookie name use a single sign-on for authentication. Once a user is authenticated, that authentication will be valid for requests to any Web Application that uses the same cookie name. The user will not be prompted again for authentication.
If you want to require separate authentication for a Web Application, you can specify a unique cookie name for the Web Application. Specify the cookie name using the CookieName parameter, defined in the WebLogic-specific deployment descriptor weblogic.xml, in the <session-descriptor> element. For more information, see session-descriptor element.
Restricting Access to Resources in a Web Application
You can apply security constraints to specified resources (servlets, JSPs, or HTML pages) in your Web Application.To apply security constraints, you
To apply the security constraint to the entire Web Application, use the following <url-pattern>: <url-pattern>/*</url-pattern>
Listing 8-6 Sample of Restricting Resources:
web.xml entries:
<security-constraint>
<web-resource-collection>
<web-resource-name>SecureOrdersEast</web-resource-name>
<description>
Security constraint for resources in the orders/east directory
</description>
<url-pattern>/orders/east/*</url-pattern>
<http-method>POST</http-method>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<description>constraint for east coast sales</description>
<role-name>east</role-name>
<role-name>manager</role-name>
</auth-constraint>
<user-data-constraint>
<description>SSL not required</description>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>
...
<security-role>
<description>east coast sales</description>
<role-name>east</role-name>
</security-role>
<security-role>
<description>managers</description>
<role-name>manager</role-name>
</security-role>
weblogic.xml entries:
<security-role-assignment>
<role-name>east</role-name>
<principal-name>tom</principal-name>
<principal-name>jane</principal-name>
<principal-name>javier</principal-name>
<principal-name>maria</principal-name>
</security-role-assignment>
<security-role-assignment>
<role-name> manager </role-name>
<principal-name>peter</principal-name>
<principal-name>georgia</principal-name>
</security-role-assignment>
Using Users and Roles Programmatically in Servlets
You can write your servlets to programmatically access users and roles in your servlet code using the method javax.servlet.http.HttpServletRequest.isUserInRole(String role). The string role is mapped to the name supplied in the <role-name> element nested inside the <security-role-ref> element of a <servlet> declaration in the Web Application deployment descriptor. The <role-link> element maps to a <role-name> defined in the <security-role> element of the Web Application deployment descriptor.
Listing 8-7 Example of Security Role Mapping
Servlet code:
isUserInRole("manager");
web.xml entries:
<servlet>
. . .
<role-name>manager</role-name>
<role-link>mgr</role-link>
. . .
</servlet>
<security-role>
<role-name>mgr</role-name>
</security-role>
weblogic.xml entries:
<security-role-assignment>
<role-name>mgr</role-name>
<principal-name>al</principal-name>
<principal-name>george</principal-name>
<principal-name>ralph</principal-name>
</security-role-ref>
Configuring External Resources in a Web Application
When accessing external resources, such as a DataSource from a Web Application via JNDI, you can map the JNDI name you look up in your code to the actual JNDI name as bound in the JNDI tree. This mapping is made using both the web.xml and weblogic.xml deployment descriptors and allows you to change these resources without changing your application code. You provide a name that is used in your Java code, the name of the resource as bound in the JNDI tree, and the Java type of the resource, and you indicate whether security for the resource is handled programmatically by the servlet or from the credentials associated with the HTTP request.
To configure external resources:
This example assumes that you have defined a data source called accountDataSource. For more information, see JDBC Data Sources.
Listing 8-8 Example of Using a DataSource
Servlet code:
javax.sql.DataSource ds = (javax.sql.DataSource) ctx.lookup
("myDataSource");
web.xml entries:
<resource-ref>
. . .
<res-ref-name>myDataSource</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>CONTAINER</res-auth>
. . .
</resource-ref>
weblogic.xml entries:
<resource-description>
<res-ref-name>myDataSource</res-ref-name>
<jndi-name>accountDataSource</jndi-name>
</resource-description>
Referencing EJBs in a Web Application
You reference EJBs in a Web Application by giving them a name in the Web Application deployment descriptor that is mapped to the JNDI name for the EJB that is defined in the weblogic-ejb-jar.xml file deployment descriptor.
To configure EJBs for use in a Web Application:
If the Web Application is part of an Enterprise Application Archive (.ear file), you can reference an EJB by the name used in the .ear with the <ejb-link> element.
WebLogic Server is set up to handle session tracking by default. You need not set any of these properties to use session tracking. However, configuring how WebLogic Server manages sessions is a key part of tuning your application for best performance. Tuning depends upon factors such as:
You configure WebLogic Server session tracking with properties in the WebLogic-specific deployment descriptor, weblogic.xml file. For instructions on editing the WebLogic-specific deployment descriptor, see Define Session Parameters.
A complete list of session attributes is available .
You can specify an interval of time after which HTTP sessions expire. When a session expires, all data stored in the session is discarded. You can set the interval in one of two ways:
WebLogic Server uses cookies for session management when supported by the client browser.
The cookies that WebLogic Server uses to track sessions are set as transient by default and do not out-live the life of the browser. When a user quits the browser, the cookies are lost and the session lifetime is regarded as over. This behavior is in the spirit of session usage and it is recommended that you use sessions in this way.
It is possible to configure many aspects of the cookies used to track sessions with attributes that are defined in the WebLogic-specific deployment descriptor, weblogic.xml. A complete list of session and cookie-related attributes is available .
For instructions on editing the WebLogic-specific deployment descriptor, see Define Session Parameters.
For longer-lived client-side user data, your application should create and set its own cookies on the browser via the HTTP servlet API, and should not attempt to use the cookies associated with the HTTP session. Your application might use cookies to auto-login a user from a particular machine, in which case you would set a new cookie to last for a long time. Remember that the cookie can only be sent from that client machine. Your application should store data on the server if it must be accessed by the user from multiple locations.
You cannot directly connect the age of a browser cookie with the length of a session. If a cookie expires before its associated session, that session becomes orphaned. If a session expires before its associated cookie, the servlet is not be able to find a session. At that point, a new session is assigned when the getSession() method is called. You should only make transient use of sessions.
Configuring Session Persistence
There are four different implementations of session persistence:
The first three are covered here; in-memory replication is covered in Understanding HTTP Session State Replication.
For file, JDBC, and in-memory replication, you need to set additional attributes, including PersistentStoreType. Each method has its own set of properties as shown below.
You can configure the number of sessions that are held in memory by setting the following attributes in the WebLogic-specific deployment descriptor, weblogic.xml. These attributes are only applicable if you are using session persistence:
If unset, this property defaults to 10 seconds; minimum is 1 second, and maximum is 604800 (1 week).
The minimum value is every second (1). The maximum value is once a week (604,800 seconds). If unset, the parameter defaults to 60 seconds.
You set <session-timeout> in the <session-config> element of the Web Application deployment descriptor web.xml.
Using Memory-based, Single-server, Non-replicated Persistent Storage
To use memory-based, single-server, non-replicated persistent storage, set the property PersistentStoreType to memory. When you use memory-based storage all session information is stored in memory and is lost when you stop and restart WebLogic Server.
Using File-based Persistent Storage
For file-based persistent storage for sessions:
If you do not explicitly set a value for this attribute, a temporary directory is created for you by WebLogic Server. If you are using file-based persistence in a cluster, you must explicitly set this attribute to a shared directory that is accessible to all the servers in a cluster. You must create this directory yourself.
Using a Database for Persistent Storage
For JDBC-based persistent storage for sessions:
For more details on setting up a database connection pool, see Managing JDBC Connectivity.
Table 8-4 wl_servlet_sessions table
If you are using an Oracle DBMS, you can use the following SQL statement to create the wl_servlet_sessions table:
create table wl_servlet_sessions
( wl_id VARCHAR2(100) NOT NULL,
wl_context_path VARCHAR2(100) NOT NULL,
wl_is_new CHAR(1),
wl_create_time NUMBER(20),
wl_is_valid CHAR(1),
wl_session_values LONG RAW,
wl_access_time NUMBER(20),
wl_max_inactive_interval INTEGER,
PRIMARY KEY (wl_id, wl_context_path) );
You can modify the proceeding SQL statement for use with your DBMS.
Note: You can configure a maximum duration that the JDBC session persistence should wait for a JDBC connection from the connection pool before failing to load the session data with the JDBCConnectionTimeoutSecs attribute.
In some situations, a browser may not accept cookies, which makes session tracking using cookies impossible. URL rewriting is a solution to this situation that can be substituted automatically when WebLogic Server detects that the browser does not accept cookies. URL rewriting involves encoding the session ID into the hyper-links on the Web pages that your servlet sends back to the browser. When the user subsequently clicks these links, WebLogic Server extracts the ID from the URL address and finds the appropriate HttpSession when your servlet calls the getSession() method.
To enable URL rewriting in WebLogic Server, set the URLRewritingEnabled attribute in the WebLogic-specific deployment descriptor, weblogic.xml, under the <session-descriptor> element. to true. (The default value for this attribute is true.)
Coding Guidelines for URL Rewriting
There are some general guidelines for how your code should handle URLs in order to support URL rewriting.
out.println("<a href=\"/myshop/catalog.jsp\">catalog</a>");
Instead, use the HttpServletResponse.encodeURL() method, for example:
out.println("<a href=\""
+ response.encodeURL("myshop/catalog.jsp")
+ "\">catalog</a>");
Calling the encodeURL() method determines if the URL needs to be rewritten, and if so, it rewrites it, by including the session ID in the URL. The session ID is appended to the URL and begins with a semicolon.
if (session.isNew())
response.sendRedirect (response.encodeRedirectUrl(welcomeURL));
WebLogic Server uses URL rewriting when a session is new, even if the browser does accept cookies, because the server cannot tell if a browser accepts cookies in the first visit of a session.
If you are writing a WAP application, you must use URL rewriting because the WAP protocol does not support cookies. In addition, some WAP devices have a 128-character limit on the length of a URL (including parameters), which limits the amount of data that can be transmitted using URL rewriting. To allow more space for parameters, you can limit the size of the session ID that is randomly generated by WebLogic Server by specifying the number of bytes with the IDLength attribute.
Using Character Sets and POST Data
You can set the character set that is used when processing data from a form that uses the POST method. To inform the application that processes the form data that a particular character set is in use, you add specific "signal" characters to the URL used to process the form data (specified with the action attribute of the <form> tag) and then map those characters to an encoding in the Web Application deployment descriptor, web.xml. POST data is normally read as ASCII unless specified using the following procedure.
To process POST data in a non-ASCII character set:
<context-param>
<param-name>weblogic.httpd.inputCharset./rus/jo*</param-name>
<param-value>windows-1251</param-value>
</context-param>
<form action="http://some.host.com/myWebApp/rus/jo/index.html"> Place the signal string after the Web Application name (also called the context path-myWebApp- in this case) and before the remaining portion of the URL.
...
</form>
For more information on the Web Application deployment descriptor, see Define Context Parameters.
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|