Developing Web Applications for WebLogic Server
WebLogic Server application deployment is covered in more detail in Deploying WebLogic Server Applications. This topics covered in this section explain only deployment procedures that are specific to Web applications.
Deployment of a Web application is similar to deployment of Connectors, EJBs, and Enterprise Applications. Like these deployment units, you can deploy a Web application in an exploded directory format or as an archive file.
Note: For development and production purposes, BEA recommends that you deploy applications in exploded (unarchived) directory format. This applies also to stand-alone Web applications, EJBs, and connectors packaged as part of an Enterprise application. Using this format allows you to update files directly in the exploded directory rather than having to unarchive, edit, and rearchive the whole application. Using exploded archive directories also has other benefits, as described in Exploded Archive Directories in Deploying WebLogic Server Applications.
Deploying a Web application enables WebLogic Server to serve the components of a Web application to clients. You can deploy a Web application using one of several procedures, depending on your environment and whether or not your Web application is in production. You can use the WebLogic Server Administration Console, the
weblogic.Deployer utility, or you can use auto-deployment.
In the procedures for deploying a Web application, it is assumed that you have created a functional Web application that uses the correct directory structure and contains the
web.xml deployment descriptor and, if needed, the
weblogic.xml deployment descriptor. For an overview of the steps required to package and create a Web application, see Main Steps to Create a Web Application.
Web applications use two deployment descriptors to define their operational attributes. A web.xml deployment descriptor is a J2EE standard XML document that describes the contents of a WAR file. The weblogic.xml deployment descriptor is an XML document containing WebLogic Server-specific elements for Web applications.
WebLogic Builder provides a visual environment for editing an application's deployment descriptor XML files. You can view these XML files as you visually edit them in WebLogic Builder, but you do not need to make textual edits to the XML files.
For instructions on using WebLogic Builder, refer to the WebLogic Builder documentation.
When editing or creating XML deployment files, it is critical to include the correct
DOCTYPE header for each deployment file. In particular, using an incorrect
PUBLIC element within the
DOCTYPE header can result in parser errors that may be difficult to diagnose.
The header refers to the location and version of the Document Type Definition (DTD) file for the deployment descriptor. Although this header references an external URL at
java.sun.com, WebLogic Server contains its own copy of the DTD file, so your host server need not have access to the Internet. However, you must still include this
<!DOCTYPE...> element in your
weblogic.xml file, and have it reference the external URL because the version of the DTD contained in this element is used to identify the version of this deployment descriptor.
This release of WebLogic Server has deprecated the Administration Console Deployment Descriptor Editor. A new Descriptor tab in the Administration Console has replaced it. The Descriptor tab is intended for administrative purposes.
Using the Descriptor tab, you can view, modify, and persist deployment descriptor elements to the descriptor file within the Web application. You can also the apply descriptor file changes to the deployed application on all its targets.
However, these changes take effect dynamically at runtime without requiring the Web application to be redeployed. The descriptor element attributes contained in the Descriptor tab are limited to only those that may be dynamically changed at runtime. These include the following:
For both production and development purposes, BEA recommends that you package and deploy your stand-alone Web applications, EJBs, and resource adapters as part of an Enterprise application. This practice allows for easier application migration, additions, and changes. For example, to add more than one Web application, EJB, or resource adapter module to an application, you must package the modules in an Enterprise application. Packaging and deploying stand-alone applications in an Enterprise application from the start saves you a lot of time. It also allows you to take advantage of the split development directory structure, which provides a number of benefits over the traditional single directory structure.
For more information, see Creating WebLogic Server Applications in Developing WebLogic Server Applications.
When WebLogic Server is running in development mode, Web applications that are copied into the applications/ directory are automatically deployed. In addition, modifications to files within these applications can trigger either partial or full redeployment.
Auto-deployment of the
applications/ directory is intended for iterative development (not for production) and only for single server (specifically, the Administration Server). That is, applications deployed using the
applications/ directory should not be targeted to servers other than the Administration Server.
When a Web application is deployed in exploded directory format, redeployment is affected by changing specific files within the directory structure. If the Web application is deployed using auto-deployment, you must modify a special file named REDEPLOY, which is located in the WEB-INF/ directory of your Web application, to redeploy the entire application.
Modifying individual files of an exploded Web application can cause partial redeployment of the Web application, depending on the files you changed. For example, modifying servlets or other classes in the
WEB-INF/classes directory can cause the associated classloader to be replaced, so that the application uses the latest version of the class. (This is one reason why objects stored in a session should be serializable.) You can control the timing of automatic class updates by setting the
servlet-reload-check-secs element, as described in weblogic.xml Deployment Descriptor Elements.
REDEPLOYand place it in the
WEB-INFdirectory of your Web application. (You may have to create this directory.)
The servlet container detects changes to servlet and filter classes and resets its classloader when a change is detected. Note that all servlets and filters are reloaded together, so changing one servlet or filter causes all to be reloaded. For more information, refer to Using Command Line Deployment.
Because static content is served directly from the disk, no redeployment is necessary for HTML pages, image files, and so on. However, if you are using caching tags or filters, you must ensure that the cache is flushed when modifying content.
You can redeploy a Web application deployed in exploded directory format when using auto-deployment by modifying a special file called
REDEPLOY. You can also cause a partial redeploy by copying a new version of a class file over an old in the WEB-INF/classes directory.
You use command line deployment for applications that are not auto-deployed. This includes any applications that are deployed from locations other than the applications/ directory. In addition, auto-deployment is disabled when the server is running in production mode. Therefore, command line deployment is necessary for all applications when production mode is enabled.
You enable production mode by starting the domain's Administration Server using the following flag: -Dweblogic.ProductionModeEnabled=true. This sets the production mode for all server instances in the domain.
When you modify a component (for instance, a servlet, JSP, or HTML page) of a Web application, you must take additional steps to refresh the modified component so that it is also deployed on any targeted Managed Servers. One way to refresh a component is to redeploy the entire Web application. Redeploying the Web application means that the entire Web application (not just the modified component) is re-sent over the network to all of the Managed Servers targeted by that Web application.
BEA recommends that you use the weblogic.Deployer utility to refresh static components (such as JSP files, HTML files, image files, and so on). For information about the weblogic.Deployer utility, see Deployment Tools Reference in Deploying WebLogic Server Applications.
In order to deploy multiple Web applications, context roots must be unique. For example, /test-1, /test-2, and so on. This prevents the context root display for Web application modules from becoming corrupted as the number of Web application modules grows.