Preparing Applications and Modules for Deployment 3-7
7.
To install the application using Administration Console, select the application installation directory. By default, the Administration Console will use a plan
named plan.xml, if one is available in the \plan subdirectory. The Administration Console does not identify plans in subdirectories other than the
\plan subdirectory; in other words, plans in \plan1 or \plan2 subdirectories 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
Chapter 4, Configuring Applications for Production Deployment
. For information on config.xml, see Creating Domains Using the Configuration Wizard.
After installing the application, you can configure, deploy, or distribute the application as necessary.
3.6 Using FastSwap Deployment to Minimize Redeployment
Todays 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 typically have to 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 WebLogic Server FastSwap
deployment feature makes the deploy and test cycles just as seamless.
3.6.1 How FastSwap Deployment Works
Java EE 5 introduces the ability to redefine a class at run time 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 WebLogic Server, 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.
Note: You cannot specify an application installation directory when using the
weblogic.Deployer tool, and the tool does not use an available plan.xml file by default. You must specify the actual deployment files and plan to use for
deployment. See Chapter 6, Deploying Applications and Modules with
weblogic.Deployer .
3-8 Deploying Applications to Oracle WebLogic Server
3.6.2 Supported FastSwap Application Configurations
The following application configuration are supported when using FastSwap deployment:
■
FastSwap is only supported when WebLogic Server is running in development mode. It is automatically disabled in production mode.
■
Only changes to class files in exploded directories are supported. Modifications to class files in archived applications, as well as archived JAR files appearing in the
applications classpath are not supported. Examples are as follows:
– When a Web application is deployed as an archived WAR within an EAR,
modifications to any of the classes are not picked up by the FastSwap agent.
– Within an exploded Web application, modifications to Java classes are only
supported in the WEB-INFclasses directory; the FastSwap agent does not pick up changes to archived jars residing in WEB-INFlib.
3.6.3 Enabling FastSwap In Your Application
