The following sections provides information on key topics required to prepare applications for deployment:
WebLogic Server supports deployments that are packaged either as archive files using the
jar utility or Ant’s
jar tool, or as exploded archive directories.
|Note:||In general, using archived files is more efficient when deploying applications to managed servers. However, it makes updating the application, such as updating web content, more difficult as it requires a redeployment of the application.|
An archive file is a single file that contains all of an application’s or module’s classes, static files, directories, and deployment descriptor files. In most production environments, the applications an Administrator receives for deployment are stored as archive files.
Deployment units that are packaged using the
jar utility have a specific file extension depending on the type:
.earfiles, and can contain other Java EE modules such as EJBs, JDBC, JMS, Web Applications, and Resource Adapters.
.warfiles or as
.jarfiles, depending on whether they are implemented using Java classes or EJBs. Typically, the .
.jarfiles are then packaged in an Enterprise Application
.earfile) or as a standard Java EE module.
In addition to an archive file, you may also receive a deployment plan, which is a separate file that configures the application for a specific environment. Configuring Applications for Production Deployment describes deployment plans in more detail.
An exploded archive directory contains the same files and directories as a JAR archive. If you choose to use an exploded archive directory, you may be required to manually unpack a previously-archived deployment. However, the files and directories reside directly in your file system and are not packaged into a single archive file with the
You may choose to deploy from an exploded archive directory under the following circumstances:
The Java EE specification recommends that archived EARs (Enterprise Application Archives) can be deployed to a Java EE-compliant server without any deployment descriptors. To achieve this, all containers assume reasonable defaults or use annotated classes. In addition to supporting this mandate, WebLogic Server also allows deploying exploded EAR directories without deployment descriptors.
Since this applies to directories, certain rules are used to identify EARs and their nested modules. Otherwise, the WebLogic Server Administration Console or deployment tools will not treat the directories as valid exploded Java EE directories.
.earsuffix. Within the application, the directory of exploded Web module should have a
.warsuffix. Similarly, the exploded EJB module should have a
.jarsuffix and the exploded RAR module should have a
File.listFiles()method order. To ensure a specific order in which modules are deployed, you must add an application.xml descriptor and list the modules in the desired order.
If you have an archive file that you want to deploy as an exploded archive directory, use the
jar utility to unpack the archive file in a dedicated directory. For example:
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 JAR or WAR files) and you want to perform partial updates of those modules, you must expand the embedded archive files as well. Make sure that you 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.
|Note:||If you want to use different subdirectory names for the archived modules in an exploded EAR file, you must modify any references to those modules in the application itself. For example, you must update the URI values specified in
When you first deploy an application or stand-alone module to one or more WebLogic Server instances, you specify a deployment name to describe collectively the deployment files, target servers, and other configuration options you selected. You can later redeploy or stop the deployment unit on all target servers by simply using the deployment name. The deployment name saves you the trouble of re-identifying the deployment files and target servers when you want to work with the deployment unit across servers in a domain.
If you do not specify a deployment name at deployment time, the deployment tool selects a default name based on the deployment source file(s). For archive files,
weblogic.Deployer uses the name of the archive file without the file extension. For example, the file
myear.ear has a default deployment name of
myear. For an exploded archive directory,
weblogic.Deployer uses the name of the top-level directory you deploy.
For Java EE libraries and optional packages,
weblogic.Deployer uses the name specified in the library’s manifest file. If no name was specified in the library’s manifest file, you can specify one with the
See the following section, Understanding Application Naming Requirements for information on application naming requirements; See Deploying Applications and Modules with weblogic.deployer to specify a non-default deployment name.
In order to successfully deploy an application to WebLogic Server, the application name must be valid. Application naming requirements are as follows:
.” character must contain at least one additional different character; “
.” and “
..” are not valid application names.
In addition to a deployment name, an application or module can also have an associated version string. The version string distinguishes the initial deployment of the application from subsequent redeployed versions. For example, you may want to later update the application to fix problems or add new features. In production systems, it is critical to maintain a version string for both the initial and subsequent deployments of an application. Doing so allows you to update and redeploy an application version without interrupting service to existing clients. See Redeploying Applications in a Production Environment for more information.
The version string is specified in the manifest file for the application, and should be provided by your development team along with the other deployment files.in Developing WebLogic Server Applications describes the conventions for specifying the version string.
The application installation directory separates generated configuration files from the core application files, so that configuration files can be easily changed or replaced without disturbing the application itself. The directory structure also helps you to organize and maintain multiple versions of the same application deployment files.
The following figure shows the application installation directory hierarchy for storing a single version of a deployable application or module.
Oracle recommends copying all new production deployments into an application installation directory before deploying to a WebLogic Server domain. Deploying from this directory structure helps you easily identify all of the files associated with a deployment unit—you simply deploy the installation root using the Administration Console, and the Console automatically locates associated files such as deployment plans and WebLogic Server deployment descriptors that were generated during configuration.
To create an application installation directory:
planunder the version subdirectory:
|Note:||If you have more than one deployment plan associated with the application, create one
\appsubdirectory. If you are deploying from an archive file, simply copy the archive file, as in:
cp c:\downloads\myApplication.ear c:\deployments\production\myApplication\91Beta\app
cp -r c:\downloads\myApplication c:\deployments\production\myApplication\91Beta\app
cp c:\downloads\myApplicationPlans\plan.xml c:\deployments\production\myApplication\91Beta\plan
cp c:\downloads\myApplicationPlans\plan1.xml c:\deployments\production\myApplication\91Beta\plan1
cp c:\downloads\myApplicationPlans\plan2.xml c:\deployments\production\myApplication\91Beta\plan2
|Note:||If you do not have an existing deployment plan, you can create one using the Administration Console as described in Configuring Applications for Production Deployment. The Administration Console automatically stores newly-generated deployment plans in the
plan.xml, if one is available in the \
plansubdirectory. The Administration Console does not identify plans in subdirectories other than the \
plansubdirectory; in other words, plans in \
plan2subdirectories are not identified by the Administration Console. Therefore, if multiple plans for your application are available, you must indicate, in
config.xml, the plan you would like to use. See Configuring Applications for Production Deployment. For information on config.xml, see Creating WebLogic Domains Using the Configuration Wizard.
|Note:||You cannot specify an application installation directory when using the
Today’s web application developers expect to make changes to a deployed application and see those changes immediately by refreshing the browser. On the Java EE side, developers have to typically go through the following cycle to see their changes in action.
Edit -> Build -> Deploy -> Test
These steps, along with the many required descriptor elements, makes developing applications with Java EE seem complex and top-heavy. Among these steps, the Build and Deploy cycles are necessitated by Java and by the application server being employed. IDEs are trying to make the Edit and Build steps seamless by providing incremental compilation support. On the server side, the WLS FastSwap deployment feature makes the Deploy and Test cycles just as seamless.
Java EE 5 introduces the ability to redefine a class at runtime without dropping its ClassLoader or abandoning existing instances. This allows containers to reload altered classes without disturbing running applications, vastly speeding up iterative development cycles and improving the overall development and testing experiences. The usefulness of the Java EE dynamic class redefinition is severely curtailed, however, by the restriction that the shape of the class – its declared fields and methods – cannot change. The purpose of FastSwap is to remove this restriction in WLS, allowing the dynamic redefinition of classes with new shapes to facilitate iterative development.
With FastSwap, Java classes are redefined in-place without reloading the ClassLoader, thereby having the decided advantage of fast turnaround times. This means that you do not have to wait for an application to redeploy and then navigate back to wherever you were in the Web page flow. Instead, you can make your changes, auto compile, and then see the effects immediately.
The following application configuration are supported when using FastSwap deployment:
WEB-INF/classesdirectory; the FastSwap agent does not pick up changes to archived jars residing in
To enable FastSwap in your application, add the following element to the
For more information on the
weblogic-application.xml elements, see in Developing Applications with WebLogic Server.
FastSwap can also be enabled for a standalone web-application by adding the
<fast-swap> element to the
weblogic.xml file. For more information on the
weblogic.xml elements, see in Developing Web Applications, Servlets, and JSPs for WebLogic Server.
The following steps describe how the FastSwap deployment process works:
It is recommended that you use an IDE such as Eclipse or IntelliJ and setting the compile-on-save option so that java files are compiled on saving. Also note that the FastSwap agent does not compile Java files.
The FastSwap agent tries to find all classes that have been modified since the last iteration by looking at all directories in the classpath. Considering an exploded application with a single web application, the following directories are examined for any class file modifications based on their timestamps:
For headless applications (that is, applications not fronted by a web application), class redefinition can be explicitly initiated using the JMX interface. An Ant task that uses the JMX interface can be used to initiate class redefinition, as shown in following Ant FastSwapTask example.
<project name='MyProject' default='all' >
<taskdef name='fast-swap' classname='com.bea.wls.redef.ant.FastSwapTask'/>
Redefine classes which have changed since they were last loaded.
adminUrl: Connection url
user: User name
password: User password
server: Managed server name
application: Deployed application name
module: Name of the module within the application.
If not specified, all modules within the application
will be processed.
failonerror: Default=true. If true, task will fail if fast-swap failed.
Otherwise, a message will be displayed and the task will
timeout: Default=300. Timeout in seconds.
classnames: Comma separated list of classnames to process. If not
specified, all classes within specified modules (if any)
in the application will be considered.
FastSwap is supported with POJOs (JARs), Web applications (WARs) and enterprise applications (EARs) deployed in an exploded format. FastSwap is not supported with resource adapters (RARs).
The following types of changes are supported with FastSwap:
The following table lists detailed change types supported with FastSwap:
The following limitation apply when using FastSwap deployment:
When FastSwap is enabled, after you recompile a class, FastSwap attempts to redefine classes in existing classloaders. If redefinition fails because your changes fall outside the scope of supported FastSwap changes, the JVM throws an
UnsupportedOperationException in the WLS window and in the server log file. Your application will not reflect the changes, but will continue to run.
To implement your changes, you can redeploy the application or affected modules (partial redeploy), depending on the application type and the extent of your changes.
The following best practices are recommended when preparing applications and modules for deployment: