Skip navigation.
Downloads | Product Documentation | Support

Deploying WebLogic Platform Applications

# Preparing the Application for Deployment

As the application moves through the promotion stages, application source and configuration files may need to be modified before the application can be deployed. Modifications are necessary if the new target environment is different from the previous one in the following ways:

- The application will be used in a high-availability environment. For example, being moved from a non-clustered to a clustered domain.
- Web services or other applications accessed by the application are no longer located on the same server, or the same domain.
- Security features are being added to the application, such as restricting access to authenticated users; or the application is restricted to receiving only SSL requests.

This chapter explains specific changes that you may need to make, the circumstances in which you might need to make those changes, and how to make them. The following topics are included:

- Summary of Application Preparation Tasks
- Summary of Changes to Deployment Descriptors and Configuration Files
- Managing Application Files for Promotion to Production
- Enabling High Availability
- Reconfiguring Application Views and Adapters
- Preparing Application Security
- Packaging the Application

# Summary of Application Preparation Tasks

Table 7-1 lists tasks that you may need to perform for application files depending on the characteristics of the application, on the target environment, or both, and provides links to topics that explain how to do those tasks.

Table 7-1 List of Application Preparation Tasks You Might Need to Perform

Application or Target Environment Characteristics | Tasks You May Need to Perform | For more information, see . . .
--- | --- | ---
Any post-development environment | Obtain application files. | Access to Application Files
Update application project files to point to the domain in the target environment on which the application runs. | Updating the Server Path Attribute
Update WebLogic Portal cache configuration, behavior tracking, campaign, and commerce tax settings. | Instructions about updating the `application-config.xml` file in Summary of Changes to Deployment Descriptors and Configuration Files
Tune the application for a production environment. | Instructions for modifying the `<jsp-descriptor>` element of the `weblogic.xml` deployment descriptor in Summary of Changes to Deployment Descriptors and Configuration Files.
Tune WebLogic Workshop dispatcher and container EJBs for a production environment. | Instructions for modifying these EJBs in Summary of Changes to Deployment Descriptors and Configuration Files.
The application is targeted to a cluster. | Enable session replication to maintain information about object state in the event of a server failure. | Enabling Session Replication
The application uses Web service controls to access other applications. | Update host, port, and optionally security protocol of target service specified in the Web service controls. | Enabling Inter-Application Communication
The application uses the Business Process Monitoring features of WebLogic Integration. | Set the concurrency strategy for stateful business process entity beans. | Specifying a Concurrency Strategy for Stateful Business Process Entity Beans
The application uses Application Integration features of WebLogic Integration. | Update the WebLogic Integration application views. | Reconfiguring Application Views
Specify Application Integration adapter target event generators. | Specifying Event Generator Targets
Secure access to the application is needed. | Restrict application access to authenticated users only. | Limiting Access to Authenticated Users
Restrict application access to SSL requests only. | Restricting Application Access to SSL Traffic Only

# Summary of Changes to Deployment Descriptors and Configuration Files

Like any J2EE application, a WebLogic Platform application has a number of deployment descriptors that you might need to tune for your production environment. The production environment also has a number of properties files that you might need to modify as well. The following table identifies these files, summarizes the changes that may be needed, identifies how to make the changes and when they can take effect, and provides links to topics that provide more information. Each file described in the following table, and the directory in which it is located, is shown in bold in the first column. In this table:

- `<App-dir>` represents the root directory of the application.
- `<Web-project>` represents the top-level directory of a Workshop project in the application.
- `<Domain-root>` represents the root directory of the domain.

Table 7-2 Summary of Changes that May Be Needed to Deployment Descriptors and Configuration Files

File and Location | Description
--- | ---
| Description: WebLogic Portal application configuration file. Contains cache configuration, behavior tracking, campaign, and commerce tax settings. When changes might be necessary: If these values are different in the new target environment, modify this file appropriately in a text editor before building the portal application. When changes take effect: After the application is rebuilt. For more information, see: "Preparing and Deploying the EAR File" in the WebLogic Portal Production Operations User Guide at http://e-docs.bea.com/wlp/docs81/prodOps/deployment.html
| Description: J2EE Web application deployment descriptor. When changes might be necessary: If the application is to be restricted to receiving SSL requests, you may need to specify the `CONFIDENTIAL` parameter in the `<user-data-constraint>` element. When changes take effect: If you make changes to this deployment descriptor, changes take effect when the application is redeployed. For more information, see: Restricting Application Access to SSL Traffic Only
| Description: The standard WebLogic deployment descriptor for Web applications. When changes might be necessary: Applications targeted to a cluster should have session replication enabled, which you configure via the `<session-param>` descriptor element using a text editor. We also recommend the following changes to the `<jsp-descriptor>` element to tune the application appropriately for a production environment: Turn off debugging by setting debug to `false`. Precompile the JSPs in the Web application to reduce the time needed to display pages on their first invocation by setting `precompile` and `preCompileContinue` to `true`. Disable polling of JSP pages for changes by setting `pageCheckSeconds` to `-1`. When changes take effect: Changes to this file require redeployment of the application. For more information, see: For enabling session replication, see Enabling Session Replication.
Deployment descriptors for the following EJBs created in WebLogic Workshop: Dispatcher EJBs Container EJBs | Description: Additional deployment descriptors for Web services created in WebLogic Workshop. When changes might be necessary: You may need to modify these deployment descriptors if those Web services are being moved to a production environment. When changes take effect: Changes to these files require redeployment of the application. For more information, see: Information is available on dev2dev in the WebLogic Workshop Internals document, in the topic "Application Customization," at the following URL: http://dev2dev.bea.com/products/wlworkshop81/articles/wlw_internals.jsp#65
| Description: Properties file that defines resources used by the WebLogic Workshop run-time framework, such as the data source used to persist conversational state and the JMS server used to buffer asynchronous service requests. When changes might be necessary: If the location or configuration of these resources changes in the new target environment, updates to this properties file will be necessary. When changes take effect: Changes to this properties file take effect on server restart. For more information, see: "jws-config.properties Configuration File" in the WebLogic Workshop Help at the following URL: http://edocs.bea.com/workshop/docs81/doc/en/workshop/reference/configfiles/con_jws-config_properties_ConfigurationFile.html
| Description: Web application project configuration file. When the application is built into an EAR file for deployment, the values in this file override the application's default values. When changes might be necessary: Specifying values in this file is useful for setting the concurrency strategy for stateful business process entity beans. When changes take effect: If you modify this file, you must rebuild and redeploy the application. For more information, see: Specifying a Concurrency Strategy for Stateful Business Process Entity Beans "wlw-config.xml Configuration File" in the WebLogic Workshop Help at the following URL: http://e-docs.bea.com/workshop/docs81/doc/en/workshop /reference/configfiles/con_wlw-config_xml_Configurati onFile.html
| Description: Properties file that defines resources used by the WebLogic Integration run-time framework, such as the document size threshold for using the document store. When changes might be necessary: If the location or configuration of these resources changes in the new target environment, updates to this properties file will be necessary. When changes take effect: If you make modifications, they take effect only after a restart of the WebLogic Server instance on which the application is deployed. For more information, see: "wli-config.properties Configuration File" in Deploying WebLogic Integration Solutions at the following URL: http://edocs/wli/docs81/deploy/wliconfig_appx.html

# Managing Application Files for Promotion to Production

This section contains the following topics, which make recommendations for managing application files for promotion to production:

- Access to Application Files
- Using a Version Control System
- Files that Should Not Be Under Version Control

## Access to Application Files

The two primary mechanisms for providing access by an application administrator to application files include the following:

- The files are accessed from a version control system, such as the Revision Control System (RCS) or Perforce
- An application administrator is given an application EAR file

Two considerations for choosing a mechanism include:

- The role of the application administrator, particularly whether he or she should be responsible for making source code changes
- The method chosen for making source file changes: in the build environment, or by editing deployment descriptors directly

One main advantage of using a version control system is that changes to application files can be tracked, and such a system is usually integrated with the WebLogic Workshop IDE. This integration provides a convenient means to rebuild application files. However, changes made to those files for the purposes of deploying into a target environment need to be tracked. In larger team environments, complications may arise if changes are made simultaneously by multiple team members.

However, when an application administrator is given an application EAR file, access to the build environment might not be available. If a change requires a rebuild of the application files, the application administrator might not be able to make the change, which could be a limitation. But when the method chosen for making file changes is to edit deployment descriptors directly, nothing more than access to the EAR file is needed. Deployment descriptors can be easily extracted, modified, and staged. In addition, handing off the EAR file to the application administrator might work better to control changes made to application source files. Moreover, it is usually easier to create scripts that work directly with EAR files. Depending on the policies that an IT team uses, the role of the application administrator, the promotion process, and the application, one mechanism might be more appropriate than the other.

Most of the changes described in this chapter are made to the deployment descriptors, which are automatically available in the EAR file, and not to application source files. So the issue of source file control, unless otherwise noted, is not a factor regarding this chapter's scope.

## Using a Version Control System

It is highly recommended to use a source control tool for version control and maintain an archive of application files. WebLogic Workshop integrates directly with CVS, Perforce, and IBM Rational ClearCase. Once you have added the files in your WebLogic Workshop application to a repository managed by one of these source control products, you can check files in and out using commands available in WebLogic Workshop.

When developing an application in WebLogic Workshop, the files to add to source control are:

- The `.work` file that represents the application. It appears at the root of the application directory.
- All source files that you have added or modified—Web services, Java controls, JSPs, business processes, and so on.
- Any XML schema files that you have added to the Schemas project.
- The files in the `resources` directory in a Web project.
- Any JAR files that you have added to the `modules` directory. These files are stored at the root of your application in the file system.
- Any JAR files that you have added to the libraries folder. These files are stored in the `APP-INF/lib` directory in the file system.
- The following files in the `WEB-INF` folder in a Web project:

- `web.xml`
- `weblogic.xml`
- `wlw-config.xml`

- The `global.app` file in the `WEB-INF/src/global` directory.
- The tag libraries that appear in the `WEB-INF` directory in a Web project, if you have page flows and JSP files in your project. These files end with the `.tld` and `.tldx` extensions.
- The JAR files that appear in the `WEB-INF/lib` directory in a Web project.

For more information about integrating a version control system with WebLogic Workshop projects, see "Integrating with Source Control Systems" in the WebLogic Workshop Help at the following URL:

http://e-docs.bea.com/workshop/docs81/doc/en/workshop/guide/devenv/conIntegratingWithSourceControlSystems.html

## Files that Should Not Be Under Version Control

While it is important to use a source control tool, such as Perforce or CVS, there are files that should not be checked into the source tree managed by such a tool. These include files that need to be installed before building the application for production deployment. These include JAR and library files provided by WebLogic Workshop for WebLogic Portal and WebLogic Integration, and also include files such as NetUI tag libraries and Liquid Data Control files. These files are staged by WebLogic Workshop automatically when you enable the templates for the applications you create for those products.

In addition, you should not check in files that are automatically generated by WebLogic Workshop during development, which include the following:

`.workshop` directory
`META-INF` (except the `application-config.xml` file)
`<web-project>``/WEB-INF/*.tld
``<web-project>``/WEB-INF/*.tldx
``<web-project>``/WEB-INF/jpf-struts-config*.xml
``<web-project>``/WEB-INF/classes
``<web-project>``/WEB-INF/lib
``<schema-project>``/system/*.*
*.jar
*.war`

In the preceding list:

- `<web-project>` represents the top-level directory name for your application's WebLogic Workshop project in the domain directory; for example:

`c:\bea\user_projects\domains\workshop\MyPlat-web-project`

- `<schema-project>` represents the top-level directory of the optional schema project, which contains your application's schema (XSD) files.

Note: If a JAR file was generated in a different application and you add it as a library or a module to the current application, put it under source control. However, if you build the library in your application, do not put it under source control, and do not copy it into the production domain. Remember that JAR files added as a module in the Modules folder of WebLogic Workshop's Application pane are placed by WebLogic Workshop in the root folder of your application, while JARs added as a library in the Libraries folder of WebLogic Workshop are placed in the `APP-INF/lib` directory.

# Enabling High Availability

When developing an application in WebLogic Workshop, you typically do not need to be concerned with several aspects of the production environment, such as:

- Access to resources in a distributed, heterogeneous environment
- High availability considerations, such as clustering and load balancing

The strength of WebLogic Workshop is that it allows you to focus on the business logic of your application, freeing you from having to write code that enables the portability, reliability, availability, and scalability features that typically are required for an enterprise-level application in a production environment. WebLogic Workshop does this, in part, by making a number of resources and capabilities available automatically, or in a very simplified way, in the development environment; for example, database access, client access, and communication with other applications.

When you move an application from development to production, however, you need to make a small number of modifications to application files to enable the application to access resources, and be accessible by clients, in a clustered environment. By making these simple modifications, you enable your application to fully leverage the high-availability and load-balancing capabilities provided by a clustered WebLogic domain environment.

There are three key areas where you typically need to make modifications so your application can function in a clustered production domain:

- Enabling Inter-Application Communication
- Enabling Session Replication
- Specifying a Concurrency Strategy for Stateful Business Process Entity Beans

## Enabling Inter-Application Communication

When building applications that must interoperate with distributed systems over a network, using Web service controls can be a powerful and convenient means to enable communication with back-end resources and other applications. In a development environment, applications can use direct access to invoke a Web service or Web application—for example, by specifying `localhost:7001` as the service's host and port. However, in a production environment, those Web services typically are not available locally, or their locations may have changed, or they may be accessed only via a Web proxy server or a load balancer to servers in the target environment.

Therefore, one challenge of moving an application from the WebLogic Workshop development environment to a production environment is ensuring that Web service controls used in that application contain correctly updated URLs. The information presented in this section does not simply explain a procedural step for application deployment, but also provides important considerations for the proper design of the application.

The need to update URLs in Web service controls typically occurs in the following situations:

- The target Web service and the application that invokes the Web service are being developed simultaneously, and the host and port of the target Web service in the production environment is either not established or subject to change.
- The target Web service is currently deployed in the production environment, but the application under development must use a staged version of that Web service until the application is also in production.

In either situation, the host and port specified in the Web service control is subject to change until the application is deployed in the production environment. This section shows an example Web service control URL, and describes four techniques you can use to update that URL.

### Example Web Service Control URL

When you incorporate a Web service control in an application to invoke a Web service, WebLogic Workshop generates the host and port of the invoked Web service into a JCX file, and includes the host and port as part of the `@jc:location` annotation. The following example shows the `@jc:location` annotation for the Web service control generated during development. The host and port are shown in bold.

>     /**
>      * @jc:location http?url="http://localhost:7001/processes/CSR.jpd"
>      * @jc:wsdl file="#CSR_ProcessWsdl"
>      */

### Techniques for Updating URLs in Web Service Controls

Before you build the application EAR file for production deployment, the host and port in the `@jc:location` annotation must updated to specify the Web proxy server or load balancer of the production domain in which the target Web service is deployed, as in the following example.

>     /**
>       * @jc:location http?url="http://proxysvr2:9201/processes/CSR.jpd"
>       * @jc:wsdl file="#CSR_ProcessWsdl"
>       */

You can use the following techniques to update host and port information specified for Web service controls in your application:

- Technique 1: Reimport the target Web service's WSDL file into your project
- Technique 2: Manually update your application's @jc:location annotations
- Technique 3: Implement an invocation to the setEndPoint() method on the service control
- Technique 4: Implement a Service Broker control

Techniques 1 and 2 involve source-level changes to the application, so access to the build environment is required to make these changes, and the application must be rebuilt for the changes to take effect. Techniques 3 and 4 do not require source-level changes to application files at deployment time as the previous two techniques do, but they do reflect features that would need to have been designed into the application during development.

Regardless of which technique you use, the development team needs to provide a list of remote services that are used by the application so that production environment system administrator can update the corresponding service control files appropriately before doing the final production environment build and deployment.

#### Technique 1: Reimport the target Web service's WSDL file into your project

When you move your application into a production domain, you can reimport the target Web service's WSDL file into your project. This WSDL file needs to have been generated from the target Web services after they have been deployed in the production environment. This method ensures an accurate update of your application's Web service controls.

#### Technique 2: Manually update your application's @jc:location annotations

In WebLogic Workshop, you can manually update each `@jc:location` to specify the correct host and port for each target Web service. This method may be quickest and simplest, but this also requires a recompilation of your application in the IDE. Because you are doing the updates manually, there is the risk of errors.

#### Technique 3: Implement an invocation to the setEndPoint() method on the service control

Each service control has a `setEndPoint()` method that you can implement to force the control, at run time, to use URL endpoint information included in a properties file that you create. Considerations for using this technique include:

- Determining where and how you obtain the endpoint information, which can be specified in a separate file, and ensuring that the information is correct and available in each target environment in which the application is deployed.
- Making this endpoint information available to the application at run time in an efficient way; for example, by not forcing the application to obtain the endpoint information more than once.
- Updating the endpoint information if the production deployment changes.

#### Technique 4: Implement a Service Broker control

The Service Broker control allows a business process to send requests to and receive callbacks from another business process, a Web service, or a remote Web service or business process. The Service Broker control is an extension of the Web service control, and it allows you to pass endpoint information to your application dynamically. For example, you can specify properties in the WebLogic Integration Administration Console. Implementing this method does not require a rebuild of the application.

## Enabling Session Replication

WebLogic Server uses standards-based communication techniques and facilities to share and maintain information about the availability of objects in a cluster. These techniques allow WebLogic Server to determine whether an object has stopped before finishing its job (because the machine on which the application is running has failed), and where there is a copy of the object to complete the job that was interrupted.

Information about what has been done on a job is called state. One technique used by WebLogic Server to maintain information about state is session replication. When a particular object unexpectedly stops doing its job, session replication enables a copy of the object to pick up where the failed object stopped, and finish the job.

Applications that are deployed in a WebLogic Platform domain should have session replication enabled. Without this setting, you will not have failover of a user's state information if a server in the cluster is stopped. To enable session replication across the cluster, configure the `<session-param>` descriptor element in the `weblogic.xml` deployment descriptor file for the application, as in the following example:

>     <session-descriptor>
>             <session-param>
>                     <param-name>PersistentStoreType</param-name>
>                     <param-value>replicated_if_clustered</param-value>
>             </session-param>
>     </session-descriptor>

## Specifying a Concurrency Strategy for Stateful Business Process Entity Beans

Most database systems, such as Oracle, do not hold a lock after an `insert` operation. The first transaction of a business process always includes an `insert` operation. If a business process is intended to receive another message or callback before the first transaction completes, database concurrency may be insufficient. In this case, use exclusive concurrency. Note that the subsequent messages or callbacks must originate on the local server for this to work.

To enable exclusive concurrency, make sure that the `<ejb-concurrency-strategy>` element in the `wlw-config.xml` file is set to `exclusive` for stateful business process entity beans. For information about issues regarding specific databases, see the BEA WebLogic Integration Release Notes at the following URL:

http://e-docs.bea.com/wli/docs81/relnotes/index.html

For information about modifying the `wlw-config.xml` file, see "wlw-config.xml Configuration File" in the WebLogic Workshop Help at the following URL:

http://e-docs.bea.com/workshop/docs81/doc/en/workshop/reference/configfiles/con_wlw-config_xml_ConfigurationFile.html

# Reconfiguring Application Views and Adapters

The `aiConfigurator` utility allows an administrator to modify environment-specific information across application view, adapter, and connection factory descriptors used with WebLogic Integration. This allows an administrator to preconfigure application integration resources to deploy correctly in a production system environment. Further tuning of these resources can then be performed using the WebLogic Integration Administration Console.

The following sections explain and provide examples of how you can use the `aiConfigurator` utility to reconfigure application views and target event generators:

- Reconfiguring Application Views
- Specifying Event Generator Targets

## Reconfiguring Application Views

If your application uses application views from WebLogic Integration as interfaces to services and events in an application enabled by one or more adapters, those applications views must be updated as appropriate for the configuration in the production environment. For example, if your application uses an application view with a DBMS adapter, the settings for the DBMS used in the production domain will be different from those in the development domain.

BEA provides the `aiConfigurator` utility to automate the reconfiguration of application views. For information about using the `aiConfigurator` utility, see "Administering Environment-Specific Application Integration Information" in Deploying WebLogic Integration Solutions at the following URL:

http://e-docs.bea.com/wli/docs81/deploy/config_appx.html

## Specifying Event Generator Targets

When using an Application Integration adapter that supports multiple generator instances, such as the sample DBMS adapter, event generators can be distributed to each node in the cluster. This is done by specifying the Event Generation Targets using the `-inboundMessagingTargets` option to the `aiConfigurator` utility.

The target specification depends on whether the adapter has implemented event generator instance support. Considerations for implementing event generator support are described in "Developing an Event Adapter" in Developing Adapters at the following URL:

http://e-docs.bea.com/wli/docs81/devadapt/7devea.html

# Preparing Application Security

The following sections explain changes that may need to be made to application files depending on the security requirements of the target environment:

- Limiting Access to Authenticated Users
- Restricting Application Access to SSL Traffic Only

## Limiting Access to Authenticated Users

If access to the application in the target environment is to be restricted only to authenticated users, you need to specify either `FORM` or `CLIENT-CERT`, as appropriate, in the `<login-config>` element of the `web.xml` deployment descriptor.

- Specify `FORM` to use form authentication, which requires a user to provide a valid username and password to use the application. The user must be a member of an appropriate role before the user can access the application.
- Specify `CLIENT-CERT` to use client certificate authentication, which requires the use of client certificates to enable access to the application.

The following example shows setting the `<auth-method>` subelement of the `<login-config>` element to `CLIENT-CERT`:

>     <login-config>
>       <auth-method>CLIENT-CERT</auth-method>
>     </login-config>

## Restricting Application Access to SSL Traffic Only

If the security model for the target environment is to restrict the application to receive SSL requests only, regardless of whether the host server is configured to receive requests only on an SSL listening port, complete the following steps.

1. Update Web Service controls for the invoking application

Enabling Inter-Application Communication explains how to update Web service controls to specify the host and port of the Web proxy or load balancer that handles access to target Web services invoked by your application. If you want to restrict application access to SSL requests only, you need to update the same Web service controls to specify a secure transport in the Web service URLs.

The following code snippet shows the secure transport that needs to be specified in the target Web service URL in a service control:

`/**
* @jc:location http-url="https://proxysvr1:7002/webservice/Report.jws"
* @jc:wsdl file="#ReportWsdl"
*/
public interface ReportControl extends com.bea.control.ControlExtension, com.bea.control.ServiceControl`

This update can be made at the same time you modify the host and port in the target Web service URL, as explained in Techniques for Updating URLs in Web Service Controls.

Note: The application also needs to have additional mechanisms implemented in its code in order to use one or two-way SSL; however, this is a development task, not deployment. For more information, see "WebLogic Workshop Security Overview" in the WebLogic Workshop Help at the following URL:

http://e-docs.bea.com/workshop/docs81/doc/en/workshop/guide/security/navSecurity.html

2. For an application to receive only requests delivered via SSL, specify CONFIDENTIAL in the <transport-guarantee> section of the `<user-data-constraint>` element in the application's `web.xml` deployment descriptor, located in the `WEB-INF` directory. For example:

`<security-constraint>
<!-some other configs -->
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>`

Warning: Domain-level security also needs to be set up properly; namely, the SSL listen port has to be configured. Corresponding changes to the invoking application are needed to enable the use of SSL. For an example of sending a client certificate, see "WebServiceA.jws Sample" in the WebLogic Workshop Help at the following URL:

Warning: http://e-docs.bea.com/workshop/docs81/doc/en/samplesrc/SamplesApp/WebServices/security/transport/clientCert/WebServiceA-jws.html

# Packaging the Application

WebLogic Workshop produces J2EE enterprise applications for deployment in a production domain. In an archived format, these are typically EAR files. Note that you cannot deploy a Web application project alone; you can deploy a Web application project only as part of an entire application.

The following topics are included:

- Updating the Server Path Attribute
- Generating the EAR File

## Updating the Server Path Attribute

When you move an application from one environment to another, which you do at each stage of promotion, the application EAR file must be rebuilt via the `wlwBuild` command. When an application's projects are moved to another environment, you must reset the `server.path` attribute of the application's `.work` file to point to the target environment's root domain directory.

The application's`.work` file is located in the root of the application directory.

In the following example, the `server.path` attribute is set to the domain `platDomain`:

>     <option name="server.path" value="../../../domains/platDomain"/>

For more information about the `wlwBuild` command, see "wlwBuild Command" in the WebLogic Workshop Help at the following URL:

http://e-docs.bea.com/workshop/docs81/doc/en/workshop/reference/commands/cmdWlwBuild.html

## Generating the EAR File

You can generate an EAR file for a WebLogic Workshop application using either of the following methods:

- In the IDE, by selecting Build EAR from the Build menu
- Using the `wlwBuild` command line tool

The `wlwBuild` tool is somewhat more flexible because you can set flags to build a JAR file for a specific project, instead of building an EAR file for the entire application. In addition, the `wlwBuild` tool can be easily invoked from an Ant task that you can either autogenerate or create manually. For details, see "How Do I: Call wlwBuild.cmd from an Ant build.xml file?" in the WebLogic Workshop Help at the following URL:

http://e-docs.bea.com/workshop/docs81/doc/en/workshop/guide/deployment/howCallWLWBuildFromAnt.html

When building an application, note the following:

- Before packaging a Portal application into an EAR file, use the WebLogic Administration Portal to create any content management repositories you want to use in your application. For details, see "Add a New Repository Connection" in the WebLogic Administration Portal Help at the following URL:

http://e-docs.bea.com/wlp/docs81/adminportal/help/CM_CreateNewRepository.html

- If you are going to use a particular Java Virtual Machine (JVM) in your production environment, and that JVM is supported in the IDE on the development machine you are using, it is a good idea to compile the EAR application with the SDK for that JVM. You can change the JVM for your WebLogic Workshop project by going to Tools—> Application Properties, selecting WebLogic Server, and specifying the path to the JDK Home (root directory) you want to use. For complete details about SDK support, see WebLogic Platform 8.1 Supported Configurations at the following URL:

http://e-docs.bea.com/platform/suppconfigs/configs81/81_over/overview.html

- Reliable Web services should not be used in an application deployed to a cluster. This is current known limitation in the 8.1 release. If your application includes a Web service with methods that use reliable messaging, you need to disable reliable messaging for those methods before you deploy. For more information, see "Java Web Service Annotations" in the WebLogic Workshop Help at the following URL:

`http://e-docs.bea.com/workshop/docs81/doc/en/workshop/reference/tags/navJwsAnnotations.html`

- When you compile an EAR file using Build EAR, a `wlw-manifest.xml` file is produced and placed in the application's `META-INF` directory. This `wlw-manifest.xml` file lists the server resources that must be created on the production server for the application EAR to run successfully.

For more information about packaging applications for deployment, see the following topics:

- "Deploying an Application to a Production Server" in the WebLogic Workshop Help at the following URL:

http://e-docs.bea.com/workshop/docs81/doc/en/workshop/guide/deployment/navDeployingApplications.html

- "wlwBuild Command" in the WebLogic Workshop Help at the following URL:

http://e-docs.bea.com/workshop/docs81/doc/en/workshop/reference/commands/cmdWlwBuild.html