The WebLogic Server Deployment Tools

WebLogic Server provides a set of tools for deploying applications to WebLogic Servers and clusters. The following tools are provided:

• The Administration Console

• The weblogic.Deployer utility

• The WebLogic Builder

• The auto-deploy feature for WebLogic Server in development mode

This section discusses each of these tools and how they can be used to deploy applications in detail.

Using the Administration Console to Deploy Applications

The Administration Console provides a browser-based GUI to configure, administer, and monitor the WebLogic Server domain. Administration Console is a Web-based application that's deployed on the Administration Server. This subsection shows how you can use the Administration Console to configure and deploy applications to the WebLogic Server domain.

Configuring and Deploying J2EE Applications Using the Administration Console

Follow these steps to configure a new J2EE application using the Administration Console:

1. Access the Administration Console through the browser using the following URL:

     http://  <adminServerListenAddress>:<adminServerListenPort>/  console  

   Because the Administration Console is deployed on the Administration Server, the Administration Server must be running for you to access it. After you've launched the Administration Console in a browser, you must log in using the Administration Server's system username and password.

2. The Administration Console has a navigation tree in the left frame that enables the user to navigate through the complete domain configuration. Start by selecting the domain that you want to work with.

3. Expand the Deployments node. The node expands to show the various J2EE components that can be deployed onto the server. This includes enterprise applications (EAR files), EJBs (JAR files), Web applications (WAR files), and connectors (RAR files). It also includes nodes for startup and shutdown classes and Web Service components .

4. Click on the Applications node. The right frame will display a list of applications that have already been configured. If you have not yet deployed any applications to the domain, the right pane displays only the Configure a new Application link, as shown in Figure 27.4.

   Figure 27.4. The Applications screen in the Administration Console when you have no applications deployed to your WebLogic domain.

   

5. To configure a new application in your WebLogic domain, click the Configure a new Application link.

6. This action opens the Locate Application or Component to Configure screen to guide you through deploying a J2EE application/component, as shown in Figure 27.5.

   Figure 27.5. The Locate Application or Component to Configure screen.

   

   The J2EE application/component files should be accessible or be present on the Administration Server's local file system for them to be configured through the Administration Console. If the application files are not present on the local file system, you can upload them to the Administration Server using the upload it through your browser link on the screen.

   From this screen, you can either select an archived application file (EAR, WAR, JAR, or RAR file) or an application in the exploded directory format for configuration. If you select an application in an exploded directory format, the server deploys all the components in that selected directory.

7. Select the archive file you want to configure by clicking the [select] link to the left of the archive file or the exploded directory.

8. After you've selected the application you want to deploy, the Configure Application or Component screen will be displayed. From this screen, select the WebLogic Server or cluster to which you would like to deploy your application. You also have to enter a name that will be assigned to your application to identify it in the Administration Console.

   Note

   If you don't select any servers or clusters, the application/component is only configured and is not deployed to any of the servers. You can, at a later time, make the appropriate target server selections and then choose to deploy the application.

   For example, Figure 27.6 shows that an application named app1 is targeted to be deployed to the AdmminServer WebLogic Server.

   Figure 27.6. Name and target your applications for deployment using the Administration Console.

   

9. To deploy your application to your target WebLogic Server(s), click the Configure and Deploy button. Upon clicking this link, you're presented with the Deployment Panel indicating the status and activity of your initiated deployment process. An example of the Deployment Panel screen for the application named app1 is shown in Figure 27.7.

   Figure 27.7. The Deployment Panel of the Administration Console indicates the status and activity related to an application deployment.

   

After your application is deployed, the Deployed column of the Deployment Status by Target table shows Deployed next to each of the deployed J2EE component(s). For example, Figure 27.8 shows the three components that were packaged in the app1 application have all been successfully deployed to their target server.

Figure 27.8. The Deployment Status by Target table indicates a successful deployment.

From the Deployment Panel, you can undeploy or redeploy an entire application or its individual components. By selecting one of the deployed application components in the Deployment Panel, you're provided with a Deployed Component screen, similar to Figure 27.9, from which you can perform the actions in the list that follows the figure.

Figure 27.9. The Deployed Component screen.

• Use the Configuration tab to change the deployment order and staging mode for the application

• Use the Targets tab to add or remove servers and clusters from the targeted list

• Use the Deploy tab to deploy or undeploy to all targeted servers, or deploy, undeploy, or redeploy to a selected server at a time

• Use the Monitoring tab to monitor the application at runtime

• Use the Notes tab to make a note for that application

If you need to reconfigure a deployed application, such as adding or removing target server(s) or changing the staging mode or deployment order, you can perform these tasks directly from the Administration Console screens shown in Figures 27.8 and 27.9, respectively. To reach these screens after you've deployed your application, select the node of the application or component you want to reconfigure from the left pane of the Administration Console. Application components are listed as subnodes of their application name node, which you assigned during their deployment. For example, in Figure 27.8, app1 is the application name node in the Administration Console that contains the following deployed components:

• WebApp1.war A Web application

• ejb1.jar An EJB

• ejb2.jar An EJB

Undeploying Components with the Administration Console

In WebLogic Server, you can deploy a component that's part of an enterprise application, or deploy an independent component that is not within an enterprise application. The Administration Console also enables you to undeploy components that have been deployed either way.

To undeploy a component with the Administration Console, follow these steps:

1. Select the component to be undeployed using the navigation tree in the left panel. The component can be a subnode of the Applications node or the EJB, WebApp, or another node, depending on how it was deployed.

2. Click the Deploy tab in the right panel.

3. In the deployment table, click the Undeploy button for the target you would like to undeploy.

This action undeploys the component from the target server. The console also refreshes to show the new deployment state and displays the status of the undeployment activity in the deployment activity table.

Note

Undeploying a component doesn't remove or delete the component from the server. The application is only deactivated and unprepared on the server it was undeployed from. That means the application classes are unloaded from the server and left in a state from which they can be reloaded again, if needed. Neither are the class files removed from the staging directory of the server.

Deleting Applications and Components with the Administration Console

To delete applications from the WebLogic domain, follow these steps:

1. Click the Applications node in the left panel. In the right panel, you'll see a list of deployed enterprise applications.

2. Click the trash can symbol in the last column to delete an application.

Deleting the application permanently deletes the application from the domain configuration. If the application is active on some servers in the domain, it's first undeployed and then deleted.

To delete a component, go to the node of which the component is a type and follow the same procedure you would to delete an application.

Viewing a List of Components Through the Administration Console

To view a list of components and their deployment status through the Administration Console, follow these steps:

1. Select the application or a component in the left panel.

2. Click the Deploy tab to see the deployment status.

If you click on an application archive within the Application node, you'll see the deployment status for each component within that application.

If you click on a component, you'll see the deployment status for that particular component only.

Using the weblogic.Deployer Utility to Deploy Applications

The weblogic.Deployer tool is a utility that can be used to deploy applications to the WebLogic server and cluster from the command line. This utility has been developed primarily for administrators and developers who prefer to deploy applications from the command line, using shell scripts instead of using the GUI-based console.

To start the weblogic.Deployer tool, follow these steps:

1. Set up your local environment using the setEnv.cmd (Windows) or setEnv.sh (Unix) script depending on your operating system environment. This sets the appropriate environment variables including the JDK home and the system CLASSPATH .

   These scripts can be found in the root of your domain directory.

2. You can invoke the deployer tool using the following syntax from the command line:

     java weblogic.Deployer [options] [-activate-deploy-deactivate-undeploy -remove-unprepare-cancel-list] [files]  

The following commands provide more information on using the weblogic.Deployer utility:

• weblogic.Deployer -help

  This command prints out help on the various parameters and options of this utility.

• weblogic.Deployer -examples

  This command prints out various examples of how the utility can be used.

Table 27.1 lists some of the main actions that can be performed with the weblogic.Deployer utility.

Table 27.1. Main Actions Passed on to weblogic.Deployer

Action	Description
-activate	Activates or reactivates an application specified by <name> from the <source> location to the servers defined in <targets> .
-deactivate	Deactivates the application specified by <name> on the server defined by <targets> . The applications aren't removed from the servers; they're left in a state (loaded) from which they can be reactivated quickly.
-unprepare	Deactivates the applications and unloads the classes for the application specified by <name> on the servers specified in <targets> .
-remove	Deactivates the application specified by <name> on the <target> servers and removes the application files that were staged from the staging directory.
-deploy	An alias for the -activate action.
-undeploy	An alias for the -deactivate option.
-nostage	The application deployed with this option will be deployed directly from the source location. The application files should be present in the location specified by -source on all target servers, when this option is specified. This is the default staging mode on the Administration Server.
-stage	The application files are copied into a staging area on the target servers and are deployed from there. This is the default staging mode for managed servers.
-external_stage	This staging mode indicates that the user or some third-party application will copy the application files to the server's staging area.

Deploying a New Application to the Administration Server

This section and subsequent sections related to the weblogic.Deployer utility will describe how to use the weblogic.Deployer utility to deploy and redeploy a simple application named app1. The app1 application is packaged in an enterprise archive named app1.ear and contains the following archives:

• Two EJBs packaged archives: ejb1.jar and ejb2.jar

• One Web application packaged archive: webApp1.war

In the examples, the weblogic.Deployer utility will be targeting a WebLogic Server domain with the following configuration:

• Domain name: mydomain

• Admin server: AdminServer listening on: EINSTEIN :7001

• Managed server: MS1 listening on: EINSTEIN:7003

• Managed server: MS2 listening on: EINSTEIN:7005

You can substitute your own application, WebLogic domain, and WebLogic Server names where appropriate to follow the weblogic.Deployer examples.

For example, to deploy the app1 application to the AdminServer (Administration Server), you can issue the following command:

 java weblogic.Deployer -adminurl http://einstein:7001 -user wls -password einstein -source app1.ear -name app1 -activate 

This command deploys and activates the application named app1 (specified by -name and located in the current directory) to the Administration Server (specified by - adminurl ).

The output from issuing this command is shown in Figure 27.10.

Figure 27.10. The output from deploying an application (app1) successfully to an Administration Server.

After the app1.ear application has been successfully deployed to the Administration Server, you can verify the deployment of the application and its components through the Administration Console.

Deploying a New Application to Managed Servers

If you need to target your deployment to specific managed servers in your domain, you must use the -targets option to specify those target deployment servers.

For example, the following command activates the application named app1.ear (specified by -name ) on the managed servers MS1 and MS2 (specified by -targets ):

 java weblogic.Deployer -adminurl http://einstein:7001 -user wls -password einstein -source app1.ear -name app -targets MS1,MS2 -verbose activate 

Caution

The -targets option is a comma-separated list of the targeted WebLogic Server. If you place a space between the targeted servers, the application will be deployed to only the fist server in the list.

In the preceding command, the -verbose option was used to provide additional progress messages, which is helpful if you want to understand the tasks that are initiated by the Administration Server to deploy your application. The output from issuing this command is shown in Figure 27.11.

Figure 27.11. The output from successfully deploying an application (app1) to the managed servers MS1 and MS2 using the -verbose option .

Tip

It's good practice to use the -verbose option when deploying an application to multiple WebLogic Servers, especially a WebLogic cluster, because you can validate the prepare and activate phases of your deployment (the two-phase deployment model).

Redeploying an Application to Targeted WebLogic Servers

If you need to redeploy a new version of an existing deployed application, you must use the weblogic.Deployer command with the -source and the -targets options, which specify the location of the modified files and the target servers to redeploy the new application to, respectively. If you don't provide the -source option or a list of updated files, the Administration Server assumes that nothing has been changed in the application and the deployment operation has no effect.

For example, the following command redeploys and activates a new version of the application named app1, located in a directory specified by the -source option, to the MS1 managed server specified by the -targets option:

 java weblogic.Deployer -adminurl http://einstein:7001 -user wls -password einstein -source app1.ear -name app -targets MS1 -verbose -activate 

The output from issuing this command is shown in Figure 27.12.

Figure 27.12. The output from redeploying app1 to the MS1 managed server.

Deploying a New Module to a Deployed EAR Application

You can add a new module to an existing application that's already deployed on WebLogic Server without redeploying the entire application. To add a new module, you must first add the appropriate entry in the application's application.xml deployment descriptor and then repackage the application.

For example, to add a new module webApp2.war without redeploying the existing modules within the application app1.ear in the MS1 managed server, use the following command:

 java weblogic.Deployer -adminurl http://einstein:7001 -user wls -password einstein -name app1 -source app1.ear -targets webApp2.war@MS1 -activate 

Deactivating an Application on Active Targets

To deactivate an application on a deployed WebLogic Server, you must use the weblogic.Deployer utility with the -deactivate option.

For example, the following command deactivates the application named app1 on the managed server MS2:

 java weblogic.Deployer -adminurl http://einstein:7001 -user wls -password einstein -name app1 -targets MS2 -deactivate 

However, the application is not removed from the server MS2, but is left in a state from which it can be reactivated again quickly, if needed. After deactivating an application on a specific WebLogic Server, it isn't accessible to clients on that server.

The output from issuing the deactivate command is shown in Figure 27.13.

Figure 27.13. The output from deactivating app1 on the MS2 managed server.

Deactivating an Application on All Deployed WebLogic Servers

If you need to deactivate an application from all the WebLogic Servers in a domain that the application has been deployed to, you can use the weblogic Deployer utility with the -deactivate option. This time, however, you do so without specifying the -targets option.

For example, the following command deactivates the app1 application on all the WebLogic Servers to which it has been deployed:

 java weblogic.Deployer -adminurl http://einstein:7001 -user wls -password einstein -name app1 -deactivate 

Reactivating a Deactivated Application

To reactivate an application that has been deactivated on a WebLogic Server instance, you can use the weblogic.Deployer utility with the -activate and -targets option.

For example, the following command activates the application app1, which was deployed to the managed server MS2, but was deactivated:

 java weblogic.Deployer -adminurl http://einstein:7001 -user wls -password einstein -name app1 -targets MS2 -activate 

The output from issuing this command is shown in Figure 27.14.

Figure 27.14. The output from reactivating app1 on the MS2 managed server.

It's important to understand that to activate a deactivated application, you don't need to specify the -source option. Because the application was already configured on a WebLogic Server instance, the application files are staged there and the deactivation task doesn't delete the application files.

Removing a Deployed Application

The process of removing an application involves deactivating an application from its target WebLogic Server and removing any resources and files that were staged for that application. To remove an application using the weblogic.Deployer utility from a targeted WebLogic Server, you must use the -remove and -targets options.

For example, the following command deactivates the application app1 as well as removes all the files related to the application from the managed server MS2:

 java weblogic.Deployer -adminurl http://einstein:7001 -user wls -password einstein -name app1 -targets MS2 -remove 

The output from issuing this command is shown in Figure 27.15.

Figure 27.15. The output from removing app1 from the MS2 managed server.

To remove an application from all the WebLogic Servers it has been deployed to, you can use the weblogic.Deployer utility with the -remove option, but without specifying the -targets option. This removes the application files from the staging directory of all the WebLogic Servers to which it was deployed.

For example, the following command removes the app1 application from all of its deployed WebLogic Servers:

 java weblogic.Deployer -adminurl http://einstein:7001 -user wls -password einstein -name app1 -remove 

Refreshing Parts of an Exploded Application

If you've deployed an exploded Web application to WebLogic Server, you can also use the weblogic.Deployer utility to redeploy or refresh parts of the Web application.

For example, the following command refreshes the index.jsp file within a sample Web application deployed in an exploded directory on WebLogic Server:

 java weblogic.Deployer -adminurl http://einstein:7001 -user wls -password einstein -name exampleWebApp -activate .\index.jsp 

The path specified after the -activate option is relative to the root of the application from which it was originally deployed. In addition, you can also refresh static content in an exploded Web application.

Listing All Deployment Tasks

You can summarize your deployment activity using the weblogic.Deployer utility by using the -list option as follows:

 java weblogic.Deployer -adminurl http://einstein:7001 -list 

A sample output from issuing this command is shown in Figure 27.16.

Figure 27.16. A sample output from issuing a weblogic.Deployer command with the -list option.

The output shows a list of deployment tasks that have been recently performed by the Administration Server.

Canceling a Deployment Task

If you ever need to cancel a deployment task that has been started incorrectly or is taking a long time to complete, you can issue a weblogic.Deployer command with the -cancel and -id options. Every time you issue a task for WebLogic Server to execute, that task is assigned a TaskID by the Administration Server. This TaskID is displayed in the output of issuing every weblogic.Deployer command.

For example, to cancel a weblogic.Deployer task with the TaskID 7, you can issue the following command:

 java weblogic.Deployer -adminurl http://einstein:7001 -user wls -password einstein -cancel -id 7 

The cancellation command has to be invoked from another command shell, different from the one that's executing the weblogic.Deployer task you want to cancel.

Using WebLogic Builder to Build and Deploy J2EE Applications

WebLogic Builder is a new GUI-based deployment tool that's provided with the WebLogic Server installation to assist you in deploying your developed J2EE applications to WebLogic Server. The primary deployment tasks you can perform with WebLogic Builder are as follows:

• Generate deployment descriptors for a J2EE application or component

• View and edit the deployment descriptors for a J2EE application or component

• Validate the deployment descriptors

• Connect and deploy an application/module to WebLogic Server

The following sections describe how you can use WebLogic Builder as an application build and deployment tool.

Starting WebLogic Builder

To start the weblogic.Deployer tool, follow these steps:

1. Set up your local environment using the setEnv.cmd (Windows) or setEnv.sh (Unix) script depending on your operating system environment. This sets the appropriate environment variables including the JDK home and the system CLASSPATH.

   These scripts can be found in the root of your domain directory.

2. To start WebLogic Builder, you can run the following scripts:

   • startWLBuilder.cmd (Windows)

   • startWLBuilder.sh (Unix)

   Alternatively, in a Windows environment, you can use the appropriate WebLogic Builder Start menu option from the taskbar.

Opening a J2EE Application Using WebLogic Builder

You can open an archived module or an exploded application in WebLogic Builder by choosing File, Open from the main menu. WebLogic Builder pops up a frame that enables you to navigate through the file system to select the desired application archive, as shown in Figure 27.17.

Figure 27.17. Open an enterprise application archive in WebLogic Builder.

To demonstrate WebLogic Builder, we'll use an existing enterprise application archive named app1.ear , which has all the deployment descriptors already defined.

When you open an enterprise archive, WebLogic Builder examines the EAR file and creates a hierarchical tree of the modules and the deployment descriptors contained in the application in the left pane. You can navigate the tree and click on any node to see the corresponding deployment descriptor fields in the right pane. Figure 27.18 shows WebLogic Builder with app1.ear open.

Figure 27.18. WebLogic Builder with the app1.ear archive opened.

The left pane shows the components within app1.ear , which are webApp1.war, ejb1.jar , and ejb2.jar. webApp1.war has one servlet called CookieCounter. If the CookieCounter node is selected, WebLogic Builder opens up the deployment parameters related to the servlet in the right pane. You can change these parameters and click File, Save in the main menu so that WebLogic Builder saves the changes to the appropriate deployment descriptor file. WebLogic Builder displays errors and messages in the bottom pane, which can be displayed by selecting the Errors and/or Messages options from the View menu.

You can also load an application or a component that does not have any deployment descriptors defined for it using WebLogic Builder. In such a scenario, WebLogic Builder examines the application archive or exploded directory, and intelligently creates the required deployment descriptors using a best-guess principle. For this reason, it's always necessary to verify the integrity of auto-created deployment descriptors using WebLogic Builder.

For an example of an auto-generating deployment descriptor for a Web application, see "Deploying Your First Web Application Using WebLogic Builder," p. 371 .

Editing Web Application Deployment Descriptors with WebLogic Builder

WebLogic Builder provides a very intuitive way of adding elements to deployment descriptor files. In this section, you learn how you can add a new servlet with a URL mapping to the webApp1.war component of the app1.ear enterprise application archive.

To add a new servlet to a deployment descriptor file, follow these steps:

1. Select the Servlets node in the left pane.

2. The right pane shows the servlets that exist in the deployment descriptors. Click the Add button at the bottom of the right pane. This opens an internal frame where you can enter all the information related to a new servlet.

3. Enter the servlet name and the servlet class or JSP you want to add. Add the URL mappings by which you want to access the servlet. In the same frame, you can add other parameters for the servlet such as init parameters, security roles, and display attributes. These are optional and can be added at a later point. An example of adding a new Servlet up to this point is shown in Figure 27.19.

   Figure 27.19. Add a new servlet to existing deployment descriptors using WebLogic Builder.

   

4. Click OK. This adds the new servlet to the navigation tree in the left frame.

5. At this point, the addition of the new servlet hasn't been saved to the deployment descriptor. You must do this explicitly by choosing File, Save. You can open the web.xml file in the WEB-INF directory to verify the additions to the deployment descriptor have been made by WebLogic Builder. You can similarly use WebLogic Builder to add filters, listeners, security roles, security constraints, tag libraries, and so on for Web applications.

Editing EJB Deployment Descriptors with WebLogic Builder

To generate the deployment descriptors automatically for an EJB20 CMP bean using WebLogic Builder, follow these steps:

1. Compile the EJB Java source files (remote interface, home interface, and the bean implementation) to a target directory (for example, build ). The target directory, which contains the EJB classes, will be used for generating the descriptor files for the CMP EJB using WebLogic Builder.

2. Start WebLogic Builder and open the target directory where the EJB classes were compiled. In this case, that directory is build .

3. Because WebLogic Builder doesn't find any deployment descriptors in the directory, it will offer to generate them. Click Yes at the prompt to auto-generate the deployment descriptors.

4. WebLogic Builder introspects the compiled classes and generates the necessary deployment descriptors. Choose File, Save to save the descriptors to their appropriate files. These XML files are saved to a META-INF directory under the root directory; that is, build .

To add a new CMP field to the EJB20 CMP bean, follow these steps:

1. Click the CMP Fields node in the navigational tree in the left pane. The right pane shows the existing CMP fields for the bean.

2. Click the Add button on the bottom of the right pane. This opens an internal frame where you can select the field's name, which corresponds to a getter/setter method in the bean's implementation class.

3. Enter the table name that corresponds to the CMP bean or use the Browse button to select it. If you use the Browse button to get the table name, you should be connected to a WebLogic Server instance.

4. Enter the column name that corresponds to the CMP field. If you're connected to a server, you can use the Browse button to browse the table and select the column name.

5. Enter the column type. Figure 27.20 shows WebLogic Builder after the new field has been added to the CMP bean.

   Figure 27.20. Use WebLogic Builder to add new CMP fields to the existing deployment descriptors of an EJB20 CMP Bean.

   

6. Click OK to add the CMP field to the deployment descriptors. The new CMP field will appear in the navigation tree in the left pane under the CMP fields node.

7. At this point, the addition of the new CMP field has not been saved to the deployment descriptor. You must do so explicitly by choosing File, Save from the WebLogic Builder menu. This adds the new CMP field to the deployment descriptors ejb-jar.xml and weblogic-cmp-rdbms-jar.xml .

You can similarly use WebLogic Builder to add finders as well as relations.

Other Useful Features Provided by WebLogic Builder

WebLogic Builder can validate a component, connect to a running WebLogic Server instance, and deploy a module to a server. The Builder tool can also be used to view the deployment descriptor files. This section looks at each of these actions.

Connecting to WebLogic Server

To deploy an application or module to WebLogic Server, WebLogic Builder must be connected to the target WebLogic Server. To connect to a WebLogic Server instance from WebLogic Builder, follow these steps:

1. Choose Tools, Connect to Server from the Builder menu. This opens an internal frame.

2. Enter the information about the WebLogic Server you want to connect to from the WebLogic Builder. This includes the server name, the listen address and port, and the protocol to be used for connecting as well as the administrator username and password. An example of this connection information is shown in Figure 27.21.

   Figure 27.21. Use WebLogic Builder to connect to WebLogic Server.

   

3. Click Connect.

This connects WebLogic Builder to the specified WebLogic Server instance.

Validating a Component

To validate a component (for example ejb1.jar of the enterprise application archive named app1.ear ), use the following procedures:

1. Open the application archive using WebLogic Builder, and select the ejb1.jar component node from the navigation tree in the left pane.

2. Choose Tools, Validate Descriptors from the WebLogic Builder menu.

WebLogic Builder begins validating the component and produces the appropriate messages in the bottom pane. During validation, the tool checks for the J2EE compliance of the bean and runs ejbc on the bean. As shown in Figure 27.22, WebLogic Builder generates messages in the bottom pane that indicate the various actions WebLogic Builder performs during the validation process and the result (if the validation is successful).

Figure 27.22. Use WebLogic Builder to validate your J2EE components.

Viewing Deployment Descriptor XML Files

WebLogic Builder also enables you to view the XML source of the deployment descriptor files. To do so, follow these steps:

1. Select the component in the navigation tree in the left pane whose deployment descriptors you want to view.

2. Choose View, XML Source from the WebLogic Builder menu.

This opens a frame, as shown in Figure 27.23, which shows the source of all the deployment descriptors present for that component.

Figure 27.23. The WebLogic Builder interface for viewing the deployment descriptor XML files.

Deploying an Application Using WebLogic Builder

To deploy an application using WebLogic Builder, follow these steps:

1. Connect to the server instance by choosing Tools, Connect to Server from the WebLogic Builder menu.

2. Open the application or component you want to deploy in WebLogic Builder.

3. Choose Tools, Deploy Module from the Builder menu. Enter the name of the application in the frame that opens and click the Deploy Module button, as shown in Figure 27.24.

   Figure 27.24. Using WebLogic Builder to deploy an application to a running WebLogic Server instance.

   

The application will be deployed to the WebLogic Server instance to which the WebLogic Builder is connected.

You can also undeploy an application from a WebLogic Server instance by using WebLogic Builder as follows:

1. Connect to the server instance by choosing Tools, Connect to Server from the Builder menu.

2. Open any application or component in WebLogic Builder.

3. Choose Tools, Deploy Module from the Builder menu.

4. Click the Manage Deployments tab in the frame that opens.

5. In the left pane, click the application you want to undeploy. For example, Figure 27.25 shows the app application selected for undeployment.

   Figure 27.25. Use WebLogic Builder to undeploy an application from a running WebLogic Server instance.

   

6. In the right pane, click the Undeploy button. Doing so undeploys the application from the WebLogic Server instance.

Using Auto-Deployment

Auto-deployment is a deployment strategy that enables developers to quickly deploy or redeploy an application to the Administration Server and test it. This feature improves the efficiency of the typical develop-deploy-test harness that's common during the development phase of any J2EE application.

Auto-deployment is a development time convenience feature, and is not recommended for use on production servers. In addition, this feature is meant for a single-server environment and therefore it isn't recommended for the deployment of components on managed or clustered servers.

The Administration Server in any WebLogic domain can be started in one of two modes: development mode or production mode.

Development Mode

This mode enables the auto-deployment feature. By default, a WebLogic Server instance runs in development mode. However, you can explicitly set a WebLogic Server into development mode as follows:

• By setting the -Dweblogic.ProductionModeEnabled property to false when you start the WebLogic Server directly from the command line. For example:

   java <arguments> -Dweblogic.ProductionModeEnabled=false weblogic.Server 

  The -Dweblogic.ProductionModeEnabled property controls the start mode of WebLogic Server.

• If you start WebLogic Server using the startup script ( startWebLogic.cmd ) provided with the WebLogic Server installation, you can set the mode in which the server starts by setting the STARTMODE variable in the script. To start WebLogic Server in development mode, you would set this variable to false in the script, as follows:

   set STARTMODE=false 

In this mode, the Administration Server starts an application poller that continuously polls the \ domainName \applications directory to detect whether any new applications have been deployed or any existing application has been modified or undeployed. On detecting a change, it takes the necessary deployment actions.

Production Mode

This mode disables the auto-deployment feature. The server does not poll the \ domainName \applications directory and therefore any changes in that directory are not detected . Because the auto-deployment feature is disabled in this mode, you must use the weblogic.Deployer tool, WebLogic Builder, or the Administration Console to perform any deployment tasks. Applications should be deployed to WebLogic Server in this mode after you have developed and tested them.

To start WebLogic Server in production mode, you can either set the -Dweblogic.ProductionModeEnabled property to true while starting the server, or you can set the STARTMODE variable in the startup script to true.

Deploying Applications in the Auto-Deployment Mode

To deploy an application when the server is started in development mode, just copy the application to the \applications directory of the Administration Server. This directory is present inside the domain directory; for example, mydomain \applications . You can copy either a bundled archive or an exploded application to the \applications directory. In the case of exploded applications, all components within the application also should be exploded.

As soon as the Administration Server detects that a new application has been copied to the \applications directory, it deploys the application automatically. If the Administration Server isn't running when an application is copied to the \applications directory, the application will be deployed the next time the Administration Server is started.

When the application has been detected and deployed by the Administration Server, the configuration of the application is also persisted to the config.xml file.

Undeploying Applications in Auto-Deployment Mode

Because the Administration Server continuously polls the \applications directory, undeploying an application using the Administration Console or weblogic.Deployer utility will not truly undeploy the application. As far as the Administration Server is concerned , there is still an application in the applications directory. For this reason, to undeploy an application from WebLogic Server in development mode, the best technique is just to delete the application archive or the exploded directory from the \applications directory. The Administration Server will detect this change and automatically undeploy the application.

Redeploying Archived Applications in Auto-Deployment Mode

If an archived application (EAR, JAR, or WAR) is already deployed to the server through the \applications directory, you can dynamically redeploy it just by copying the new version of the archive to the \applications directory. The server updates the application automatically.

During the development cycle, a developer can perform this copying as the last step in his build process. When the new version of the archive is copied to the \applications directory, it's automatically updated and the developer can immediately test itwithout restarting the server.

Redeploying Exploded Applications in Auto-Deployment Mode

When an application or component has been deployed through the \applications directory in an exploded format, the Administration Server periodically checks the timestamp on a file named REDEPLOY in the exploded application. If the timestamp on the file has changed since the previous check, the Administration Server redeploys the application.

To redeploy or update an exploded application, follow these steps:

1. Create an empty file named REDEPLOY in the exploded application. The location for creating this file depends on the type of the exploded application:

   • If the exploded application is an enterprise application (exploded EAR), the REDEPLOY file should be created in the top-level META-INF directory; that is, in the same directory as the application.xml file. If the exploded application is an EJB, the REDEPLOY file should be created in the top-level META-INF directory; that is, in the same directory that contains the ejb-jar.xml .

   • If the exploded application is a Web application, the REDEPLOY file should be created in the top-level WEB-INF directory; that is, the directory that contains the web.xml file.

   • If the exploded application is a connector, the REDEPLOY file should be created in the top-level META-INF directory; that is, the directory that contains the ra.xml file.

2. To update the application, copy the new files over the existing files in that exploded application directory. For example, in the case of an exploded Web application, you should copy the new set of JSPs over the existing set and copy the new servlet classes to the WEB-INF\classes directory.

3. Modify the timestamp of the REDEPLOY file. This can be done by using the touch command on the command prompt; that is, by entering touch REDEPLOY or just by opening the file and saving it.

The application poller in the Administration Server detects the change in timestamp of the REDEPLOY file and updates or redeploys the contents of the exploded application.