Deployment Best Practices

The following are suggested practices when deploying applications to WebLogic Server. Deployment methodology should provide deployment procedures that are orderly (to avoid development team confusion) and repeatable (to guarantee application state).

Archived Versus Exploded Applications

We recommend that, when deploying applications, it's best to deploy archived applications rather than exploded applications. This facilitates transport and management of the application; that is, controlling one .ear file as opposed to controlling 100 individual files of various types. We further suggest that all application modules (EJB applications, Web applications, supporting JARs) be packaged within one .ear file. For example, our global auctions application contains 13 JSPs, 10 servlets, 4 EJBs, and other support files. We would package the EJBs within one EJB .jar file (see Chapter 20 for EJB packaging); servlets, JSPs, and JSP tag libraries and all other files supporting the Web application within a separate .war file (refer to Chapter 6 for Web application packaging). All archives (EJB JAR, Web application WAR files, and support enterprise application–level JAR files) would then be packaged within the one .ear file for deployment.

Exploded Applications

However, if you choose to deploy an exploded application, ensure that your file structure facilitates WebLogic Server implementation; that is, modules should be deployed under a top-level source or staging directory. Each individual application should reside within a separate subdirectory as shown:

/sourceDirectory
  /module1
   /WEB_INF
    web.xml
    module1Files
  /module2
   /WEB-INF
    ejb-jar.xml
    module2Files

Development

During development, it's best to work in a single server environment until your application is stable enough for multiserver testing. This single server should be an administration server, set to auto-deployment to facilitate changes. When you're ready to test your application on multiple servers, either modify the application's targets using the Administration Console or use weblogic.Deployer as discussed earlier.

Staging Modes

WebLogic Server gives you the flexibility to determine where application files are located. There are three options: nostage (administration server default; application files are maintained on the administration server and not copied to managed servers), stage (managed server default; application files are copied to domain's managed servers), and external_stage (files are expected in a staging directory but the user, not WebLogic, posts the files to the target staging location).

Use the system defaults for staging mode, nostage for administration servers, and stage for managed servers. Two exceptions would be if you're using a third-party application to implement your deployments or if you're using a shared file system across managed servers. Use the external_stage mode for these exceptions. To set the staging mode using the WebLogic Administration Console, start the console as discussed earlier, navigate to the target Web application under Deployments→Web Application. Select the target Web application and then select the desired staging option, as shown in Figure 7.10.

To set the staging mode manually, adjust the staging mode attribute within the domain's config.xml file as shown here:

<Application Name="gams" Path="E:\bea\user_projects\gams.ear" TwoPhase="true"
  StagedTargets="" StagingMode="nostage" TwoPhase="true">
  <EJBComponent Name="customer.jar" Targets="adminServer" URI="customer.jar"/>
  <EJBComponent Name="item.jar" Targets="adminServer" URI="item.jar"/>
  <EJBComponent Name="processbid.jar" Targets="adminServer" URI="processbid.jar"/>
  <WebAppComponent Name="gams.war" Targets="adminServer" URI="gams.war"/>
</Application>