The following topic explains the basic concepts of deploying WebLogic Workshop applications to WebLogic Server running in production mode.
For step-by-step instructions on deploying a WebLogic Workshop application to a production server see How Do I: Deploy a WebLogic Workshop Application to a Production Server?.
Weblogic Server can be started in one of two modes: development or production mode. Development mode is the default. When you are developing, deploying and testing an application with WebLogic Workshop, the instance of Weblogic Server you are running is in development mode. In development mode, WebLogic Server behaves in ways that make it easier to iteratively develop and test an application: it automatically deploys the current application in an exploded format, server resources such as databases and JMS queues necessary for the application to run are automatically created, etc.
When the development cycle is complete, and the application is ready for use, you deploy it to an instance (or instances) of WebLogic Server running in production mode. In production mode applications are not automatically deployed. The server resources necessary for running an application are not automatically generated, you must generate them manually.
To set the server to start in production mode, you specify the Java property mode in the startup script as:
-Dweblogic.ProductionModeEnabled=true
For detailed information on starting WebLogic Server in production or development mode see startWebLogic Command.
WebLogic Workshop produces J2EE enterprise applications for deployment to a production server. You cannot deploy a web application project alone as a Web Application Archive (WAR) file; it must be deployed as a part of an entire application. There are two ways to deploy an application on the production server: in an exploded directory, or in an archive.
In an archived format, use EAR files if you are deploying an entire application; or use a JAR file if you are deploying a specific project within an application, (provided that specific project is a custom Java control or a Schema project).
You can generate an EAR file for a WebLogic Workshop application either (1) from the menu bar by selecting Build-->Build EAR or (2) by using the wlwBuild.cmd command line tool. The wlwBuild.cmd line tool is somewhat more flexible in that you can set flags to build a JAR file for a specific project, instead of building an EAR file for the entire application.
For information generating an ANT build.xml file that calls wlwBuild.cmd, see How Do I: Call wlwBuild.cmd from an ANT build.xml file?
EAR files can be deployed to WebLogic Server using either (1) the WebLogic Server console, or (2) the weblogic.Deployer utility.
To use the WebLogic Server console to deploy an EAR file, start the console, expand the Deployments node in the left-hand pane, right-click the Applications node, and select Deploy a new Application.
To use the weblogic.Deployer utility see the Deployment Tools Reference in the WebLogic Server 8.1 documentation.
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-manifiest.xml file lists the server resources that must be created on the production server for the application EAR to run successfully. See the next section for information relating to the wlw-manifest.xml file.
Note: Values specified in a project's WEB-INF/wlw-config.xml file, such as hostname, http-port, and https-port, will be hard-coded into the EAR file. The result will be an EAR file that can be run only on the machine named in the wlw-config.xml file. For this reason, it is recommended that you do not write to the wlw-config.xml file before producing an EAR file. If you need to override the hostname and ports dynamically determined by the server at runtime, use the wlw-runtime-config.xml file instead of wlw-config.xml.
When deploying EAR files to a production server, a certain amount of manual resource creation is necessary. When an application is built in an EAR file, a wlw-manifest.xml file is produced and placed in the application's META-INF directory. This file lists the JMS queues and database tables that need to be manually created on the target WebLogic Server for the application to run properly.
Note: When you use iterative builds, the builds do not include a clean step. To ensure an accurate wlw-manifest.xml file, make sure your final build includes a clean step. Otherwise, the contents of the wlw-manifest.xml may not be correct.
Note: When you are developing and testing
an application with WebLogic Workshop, the creation of the necessary JMS
queues and datatables on WebLogic Server takes places automatically on demand.
Required database tables are indicated by a <con:conversation-state-table /> tag. These tables are used by web services to store conversational state. For each occurrence of the <con:conversation-state-table /> tag in the wlw-manifest.xml file, you must create a corresponding datatable on WebLogic Server. For detailed information about the schema required for these tables, see How Do I: Deploy a WebLogic Workshop Application to a Production Server?
Required JMS queues are indicated by pairs of <con:async-request-queue> and <con:async-request-error-queue> tags. For each occurrence of these tags in the wlw-manifest.xml file, you must create a corresponding JMS queue on WebLogic Server and you must associate the members of the pair by referencing the <con:async-request-error-queue> in the ErrorDestination attribute of the <con:async-request-queue>. For detailed information about how to create these queues, see How Do I: Deploy a WebLogic Workshop Application to a Production Server?
Optionally, you may want to enforce role restrictions on any controls that receive external callbacks. Controls that can receive external callbacks are indicated within a <con:external-callbacks/> tag in the wlw-manifest.xml file. Since the compilation process turns control files into individual methods on an EJB, you enforce the role restrictions on these post-compilation EJB methods. For detailed information about applying role restrictions in this case see How Do I: Deploy a WebLogic Workshop Application to a Production Server?
How Do I: Deploy a WebLogic Workshop Application to a Production Server?