WebLogic 8.1 Deploying

 

+

Search Tips   |   Advanced Search

 


Contents

  1. Deployment Tools
  2. Deployable Modules
  3. J2EE and WebLogic Deployment Descriptors
  4. Exploded Directories
  5. Deployment Targets
  6. Staging Modes
  7. Deployment Names

See also

  1. Overview
  2. Quickstart
  3. Packaging Overview
  4. Performing Common Deployment Tasks
  5. console Deployment Assistant
  6. weblogic.Deployer Utility
  7. EJBGen
  8. weblogic.management.deploy API
  9. Concepts

 


Deployment Tools

Admin Console Provides Deployment Assistants and controls for changing and monitoring deployment status and descriptors.
weblogic.Deployer Command-line based interface for performing both basic and advanced deployment tasks. weblogic.Deployer can be used to perform certain advanced deployment tasks, such as refreshing static content for webapps.
wldeploy Ant task version of the weblogic.Deployer utility. Use with an Ant build.xml file.

 

Deployment Terminology

Deploy Make deployment source files available to target servers and load classes into classloaders so that applications are available to clients.
Distribute For stage mode deployments. Only copy the deployment files to the target servers (but do not start the deployment).
Redeploy Update an application or part of an application (for example, an .EAR, a module within an .EAR, or a static file) that is currently deployed and available to clients. When redeploying an entire application, all of the application's modules must redeploy successfully or the entire application is stopped.
Stop Unload an application's classes and making an application unavailable to clients. Stopping still leaves the deployment files and deployment name available to target servers for subsequent Redeployment or Starting.
Start Reload an application's classes into classloaders and making the application available to clients. Starting requires that the deployment files be available on target servers as a result of an earlier deployment.
Undeploy stopping an application and then removing its deployment files and deployment name from target servers.

 


Deployable Modules

  1. Standalone

    Include Enterprise JavaBeans and resource adapter modules. WebLogic Server also supports deploying Web Services modules, which are not part of the J2EE specification. Standalone modules generally provide parts of a larger, distributed application, but do not necessarily provide a direct user interface.

  2. EJB

    Packaged as archive files having a .jar extension, but are generally deployed as exploded archive directories.

  3. Resource Adapters (connectors)

    Packaged as archive files having a .rar extension. Provide a software driver for use in connecting to an Enterprise Information System. Resource Adapters cannot be deployed as exploded archive directories.

  4. Web Service

    Virtual modules that, at a minimum, include both a webapp (.war) and a Web Service deployment descriptor. A Web Service module may also include EJBs that implement the Web Service.

  5. webapp

    Consist of a servlet or JSP page, along with any helper classes, as well as a web.xml deployment descriptor. Can also contain JSP tag libraries, static .html and image files, supporting classes and .jar files, and a weblogic.xml deployment descriptor, which configure WebLogic Server-specific elements for webapps.

  6. Enterprise Application

    Consists of one or more of the following J2EE applications or modules:

    1. webapps
    2. Enterprise Java Beans (EJB) modules
    3. Resource Adapter modules
    4. RAR modules
    5. XML descriptor files

    Packaged as JAR files with an .ear extension. Can be deployed as an exploded EAR directory.

  7. Client Application Archives

    Contains the Java classes that execute in the client JVM and deployment descriptors that describe EJBs and other WebLogic Server resources used by the client. Allows both the server-side and client-side components to be distributed as a single unit. Defined using application-client.xml deployment descriptor and an optional WLS81 descriptor, client-application.runtime.xml.

 


J2EE and WebLogic Deployment Descriptors

module Deployment Descriptors
webapp WEB-INF/web.xml
WEB-INF/weblogic.xml
Enterprise Bean META-INF/ejb-jar.xml
META-INF/weblogic-ejb-jar.xml
META-INF/weblogic-cmp-rdbms-jar.xml
Connector META-INF/ra.xml
META-INF/weblogic-ra.xml
Web Service Web Services have no J2EE descriptor. However, Web Services modules are typically packaged as an Enterprise Applications that contain both a webapp and EJB modules. For this reason, Web Services modules generally require J2EE descriptors required for those modules.

WEB-INF/web-services.xml

Enterprise Application META-INF/application.xml
META-INF/weblogic-application.xml
Client Application META-INF/application-client.xml
client-application.runtime.xml

 


Exploded Directories

Deploy a module as an exploded archive directory, rather than a single archive file, in the following circumstances:

  • To perform partial updates to a deployed application without redeploying the entire application.

  • To deploy a Web or Enterprise app that performs direct file system I/O. In this case, the modules that perform the I/O operations should have a physical filesystem directory in which to work; you cannot obtain a file when the application is deployed as an archive.

  • To deploy a Web Enterprise app that contains static files that you will periodically update. In this case, it is more convenient to deploy the module as an exploded directory, because you can update and refresh the static files without re-creating the archive.

  • To use the console to dynamically edit and persist selected deployment descriptor values for the deployment. (You cannot edit deployment descriptor values in the console for modules deployed as archive files.)

If you choose to deploy an exploded archive directory, use the jar utility to unpack the archive file in a dedicated directory. For example:

  1. mkdir /myapp
  2. cd /myapp
  3. jar xvf /dist/myapp.ear

If you are unpacking an archive file that contains other module archive files (for example, an Enterprise Application or Web Service that includes .EJB or .WAR files) and you want to perform partial updates of those modules, expand the embedded archive files as well. Unpack each module into a subdirectory having the same name as the archive file. For example, unpack a module named myejb.jar into a /myejb.jar subdirectory of the exploded Enterprise Application directory.

To use different subdirectory names for the archived modules in an exploded .EAR file, modify any references to those modules in the application itself. For example, updated the URI values specified in application.xml and CLASSPATH entries in the manifest.mf file.

 


Deployment Targets

Deployment Targets are the servers to which you deploy a module. During the deployment process, you select the list of targets from the available servers, clusters, and Virtual Hosts configured in your domain. You can also change the target list at any time after you have deployed a module.

 


Staging Modes

The deployment staging mode determines how a application or module's deployment files are made available to target servers that must deploy the module.

Deployment Staging Mode Behavior When to Use
stage The Admin server first copies the deployment source files to the staging directories of target servers. (The staging directory is named stage by default, and it resides under the target server's root directory.)

The target servers then deploy using their local copy of the deployment files.

Deploying small or moderate-sized applications to multiple WebLogic Server instances.

Deploying small or moderate-sized applications to a cluster.

nostage The Admin server does not copy deployment files. Instead, all servers deploy using the same set of deployment files, which must be directly accessible by the Admin server and target servers.

With nostage deployments of exploded archive directories, WebLogic Server automatically detects changes to a deployment's JSPs or Servlets and refreshes the deployment. (This behavior can be disabled if necessary.) Deploying to a single-server domain.

Deploying to a cluster on a multi-homed machine.

Deploying very large applications to multiple targets or to a cluster where deployment files are available on a shared directory.

Deploying exploded archive directories that you want to periodically update by changing JSPs or Servlets.

external_stage The Admin server does not copy deployment files. Instead, the Administrator must ensure that deployment files are copied to the correct staging directory location before deployment. Deploying very large applications to multiple targets or to a cluster where deployment files are manually copied to servers' staging directories. Manually copying the files before deployment can reduces the time required to deploy very large applications.

Deploying to domains where third-party applications or scripts manage the copying of deployment files to the correct staging directories.

 


Deployment Names

When you first deploy a module to one or more WebLogic Server instances, you can specify a deployment name to describe the deployment files, target servers, and other configuration options you selected. You can later redeploy or stop the module on all target servers by simply using the deployment name. The deployment name saves you the trouble of re-identifying the deployment name files and target servers when you want to work with the module across servers in a domain.

If you do not specify a deployment name at deployment time, the deployment tool selects a default name. For exploded archive directories, the default deployment name is the name of the top-level directory you deploy. For archive files, the deployment name is the name of the archive file without the file extension (myear for the file myear.ear).

  Home