|
|
The term application deployment refers to the process of making an application or module available for processing client requests in a WebLogic Server domain. This chapter discusses recommended procedures and best practices for deploying WebLogic Portal applications and shared libraries to the server.
| Note: | WebLogic Portal does not currently support the WebLogic Server feature called production redeployment, also called side-by-side versioning. For information on this WebLogic Server feature, see “Overview of Redeployment Strategies.” |
This chapter includes the following topics:
| Tip: | Before continuing, we recommend that you review the following WebLogic Server document, “Understanding WebLogic Server Deployment.” |
Before you deploy a WebLogic Portal application, you need to configure the destination domain. For detailed information on domain configuration, see Creating Your Clustered Domain.
In WebLogic Portal 8.1 and prior versions, an application configuration file named META-INF/application-config.xml was used to configure WebLogic Portal components such as cache, campaigns, behavior tracking, content management, and others.
As of WebLogic Portal 9.2, this configuration file has been removed and its contents moved to a collection of new, schema-compliant, descriptors. These new descriptors are each focused on a single service or group of related services. To view the complete set of descriptor files used by an application in WebLogic Workshop, select the Merged Projects view.
These files are processed using the same infrastructure that WebLogic Server uses to process all the J2EE descriptors (like application.xml or web.xml). These descriptors support merging from J2EE Shared Libraries and also support deployment plans. (For more information on merging, see Descriptor Merging.) The WebLogic Portal descriptors are installed with default settings that you can override by copying them into your application and editing them. A significant benefit of this configuration is that the contents of your project’s EAR file is focused on your project, and not on the WebLogic Portal product code.
This section includes these topics:
When the server processes the deployment descriptors, it merges them. All descriptors from the application and from the shared libraries that the application references are merged. For each separate deployment descriptor, a merged “virtual” descriptor is created, which can be used by the server to deploy the application. The rules that govern descriptor merging are explained in Shared Library Rules of Precedence. Remember that the referencing application and its deployment plan always override settings imported from a referenced library.
If you want to see merge results without deploying an application, you can use the WebLogic Server utility called weblogic.appmerge. This utility takes an application that references shared libraries and creates a J2EE application including the merged contents and merged descriptors. This utility is useful for debugging purposes. For details, see the WebLogic Server document,
“Using weblogic.appmerge to Merge Libraries.”
Workshop for WebLogic provides information about shared libraries (also called library modules). You can use Workshop for WebLogic to copy files from shared libraries to your application. When you do this, you can then modify the copied file. From then on, the local copy takes precedence over the library module copy. Using the Package Explorer view, you can view and browse the contents of shared libraries.
Another utility, called ddbrowser, is included with the WebLogic Portal installation. This utility inspects your application and shows you all the “mergeable” descriptors. For each descriptor in the application, you can see the contributions from each library as well as the resulting merged descriptor.
To use ddbrowser, set the WL_HOME environment variable to point to the weblogic92 directory of your installation. Then run the following command:
java -jar $WL_HOME/common/p13n/lib/ddbrowser.jar.
A Portal Web Application includes several deployment descriptors. By default, these descriptors are located in the WebContent/WEB-INF directory of the web project. The deployment descriptors are listed in Table 4-1.
| Tip: | For a complete listing and detailed description of deployment descriptors associated with WebLogic Server based applications, see the WebLogic Server document “Overview of WebLogic Server Application Development.” |
The J2EE specifications define standard, portable deployment descriptors for J2EE modules and applications. BEA defines additional WebLogic-specific deployment descriptors for deploying a module or application in the WebLogic Server environment. A WebLogic Portal enterprise application, also called an EAR Project, includes the deployment descriptors listed in Table 4-2. By default, these files are located in the EarContent/META-INF directory of the EAR project.
| Tip: | For a complete listing and detailed description of deployment descriptors associated with WebLogic Server based applications, see the WebLogic Server document “Overview of WebLogic Server Application Development.” |
This WebLogic descriptor specifies the J2EE Shared Libraries used by the enterprise application. It also specifies web applications, such as the Propagation Servlet, that are deployed to the EAR. See also the WebLogic Server document
“Creating Shared J2EE Libraries and Optional Packages.”
|
|
This WebLogic descriptor specifies the cache settings for all caches used by WebLogic Portal. For more information on cache settings, see the WebLogic Portal Development Guide.
|
|
Table 4-3 lists Web application configuration files. These files are not descriptor files (they cannot be used in deployment plans and they are not merged).
This file allows WSRP consumer applications to configure registered producer applications. For example, you can enable local proxy support by setting
<enable-local-proxy> to true in WEB-INF/wsrp-producer-registry.xml in the consumer web application. For more information on WSRP applications, see the Federated Portals Guide.
|
|
This descriptor specifies netui-specific tags and handler classes. For detailed information on the elements of this descriptor, refer to the
Apache Beehive Project reference documentation.
|
Deployment plans let you easily tune an application’s deployment descriptors on a deployment-by-deployment basis without actually modifying the descriptors themselves in the application EAR file. For instance, you might use a deployment plan to adjust descriptors for a staging environment and another plan to make adjustments for your production environment. Typically, developers set initial baseline descriptor values.
| Tip: | See also Application Tuning Tips. |
A deployment descriptor is an XML document used to define the J2EE behavior or WebLogic Server configuration of an application or module at deployment time. A deployment plan is an XML document that resides outside of an application's archive file, and can apply changes to deployment properties stored in the application's existing WebLogic Server deployment descriptors.
For detailed information on deployment plans, see the WebLogic Server document “Configuring Applications for Production Deployment.” This document describes deployment plans in detail, discusses the XML schema for deployment plans, and explains how to create, edit, and use them.
| Note: | The WebLogic Portal Administration Console uses deployment plans to save runtime changes to deployment descriptor values. |
With application-scoped JDBC, it is possible to use more than one database in a WebLogic Portal domain, allowing each application deployed in the domain to access its own database. WebLogic Server enables this by providing the ability for you to scope JDBC pools to the application level.
| Note: | By default, JDBC pools are scoped to the domain level. If you want to scope JDBC pools to the application level, some configuration is required. |
When you package your enterprise application, you can include JDBC resources in the application by packaging JDBC modules in the EAR and adding references to the JDBC modules in all applicable descriptor files. When you deploy the application, the JDBC resources are deployed, too. Depending on how you configure the JDBC modules, the JDBC data sources deployed with the application will either be restricted for use only by the containing application (application-scoped modules) or will be available to all applications and clients (globally-scoped modules).
For detailed information on configuring application-scoped JDBC, see the WebLogic Server document “Configuring JDBC Application Modules for Deployment.”
This section explains how to build a portal application and create an EAR file using Workshop for WebLogic or from the command line. This section discusses creating both EAR files and exploded EARs.
To deploy a portal application to a production environment, you must first build the application in Workshop for WebLogic to compile necessary classes in the portal application and create a deployable EAR file. The EAR can either be compressed (an EAR file) or uncompressed (an exploded EAR directory).
For detailed information on building an application in Workshop for WebLogic, see the Workshop for WebLogic document “Understanding the Build Process.”
To create an exploded EAR directory, first build an EAR file, and then use the Java jar xf command to uncompress the file.
| Tip: | After you create an exploded EAR, you might want to rename the application directory so that it has a .ear extension. For example, if the application directory is called myPortalApp, rename the directory to myPortalApp.ear. Adding the .ear makes the configuration common for compressed and exploded deployments, but it is not required. |
You can export an Ant build file for your project using Workshop for WebLogic. For more information, see the WebLogic Workshop document “Creating Custom Ant Build Files for an Application.”
This section provides instructions for the deployment of your portal application.
| Note: | Although it was required before WebLogic Portal version 9.2, deploying a WebLogic Portal application to the Administration Server is no longer necessary and is not specifically discussed here. |
| Tip: | WebLogic Server documentation explains the deployment process and multiple deployment scenarios in detail. We recommend you review the WebLogic Server document “Deploying Applications to WebLogic Server” before continuing. For information on automating deployment tasks with WLST see the WebLogic Server document “WebLogic Scripting Tool.” |
This section includes the following topics:
In a typical development environment, developers use Workshop for WebLogic to develop portal components. They typically deploy and run against a local server domain that is configured in Development mode. No Managed Servers are used. The best practice is to use Workshop for WebLogic to deploy (publish) and test your application.
In a domain with an Administration Server and one Managed Server or multiple Managed Servers in a cluster, it is strongly recommended that you deploy the portal EAR file to the Managed Server or cluster. Do not deploy to the Administration Server; this reserves the Administration Server for administration functions, allows the Administration Server to operate with a smaller heap, and allows specific fire-walling of administration functions on this server.
The best practice is to configure your staging and production servers in Production mode rather than Development mode.
The WebLogic Server feature that allows applications to be deployed directly to a Managed Server is called Managed Server Independent (MSI) mode. See “Understanding Managed Server Independent Mode” in the WebLogic Server documentation for information on MSI and several limitations of MSI. One of the most important limitations is that security provider data cannot be modified if the Administration Server is down. Another limitation is that any WebLogic Portal configuration that must write to a deployment plan for persistence will not work if the Administration Server is down.
Redeploying means deploying a new version of an existing/running/deployed application. If you redeploy a portal application to a staging or production environment, follow the same procedure as deploying described in the previous section. However, on redeployment, you must propagate datasync and other WebLogic Portal assets to the target database as a separate operation using the propagation tools. See General Propagation Scenarios for more information on redeploying.
WebLogic Portal product code is included in your application by referencing several J2EE Shared Libraries. These libraries are part of the WebLogic Portal installation. You can also develop your own shared libraries containing your application code. J2EE Shared Libraries allow you to decouple the development life cycles of various portions of your application. These libraries can be versioned and deployed independently, allowing each library to be developed and distributed independently (rather than as a single large EAR file).
| Tip: | For detailed information on J2EE Shared Libraries, see the WebLogic Server document “Creating Shared J2EE Libraries and Optional Packages.” See also Using J2EE Shared Libraries in a Team Environment and the WebLogic Portal Development Guide. |
This section discusses several aspects of shared libraries:
Listing 4-1 shows a sample enterprise application, myApp.ear. Note that the descriptor weblogic-application.xml includes a reference (shown in bold) to a library called p13n-app-lib. Note, too, that no other information, other than the name p13n-app-lib, is given to describe the library.
The enterprise application locates the library because the <library-ref> element causes the server at runtime to look for a deployed library with the same name. Since the <library-ref> element does not specify any version information, the server looks for the latest, or highest, version number available to it. The name and version number of a shared library is contained in the library itself, in the META-INF/MANIFEST.MF file. For example:
META-INF/MANIFEST.MF
Extension-Name: p13n-app-lib
Specification-Version: 9.2.0
Implementation-Version: 9.2.0
For more information, see Library Versions. Note that the same pattern applies to the WEB-INF/weblogic.xml file for portal web applications.
To be located by the server, a shared library must be deployed as a library. This deployment differs from the deployment of a runnable application. When a library is deployed as a library, the library file is registered with the server, and is therefore available to referencing applications.
To deploy a library, use the WebLogic Server Console, the weblogic.Deployer command, the wldeploy Ant task, or with a WLST script. For information these methods, see the WebLogic Server documents “
The WebLogic Server Administration Console,” “
weblogic.Deployer Command Line Reference,” “
wldeploy Ant Task Reference,” and “
WLST Command and Variable Reference.”
For example, you can use the WebLogic Server Console to deploy a shared library in exactly the same way you deploy an application, except that a checkbox is available that distinguishes the shared library from a runnable application.
Listing 4-2 shows an entry in the server domain’s config/config.xml file for the shared library referenced by the application in Listing 4-1.
<library>
<name>p13n-app-lib#9.2.0@9.2.0</name>
<target>myServer</target>
<module-type>ear</module-type>
<source-path>/bea/weblogic92/deployable-libraries/p13n-app-lib.ear
</source-path>
<security-dd-model>DDOnly</security-dd-model>
</library>
You can deploy several libraries with the same name and different version numbers. The version number that an application uses is specified in the application’s configuration file META-INF/weblogic-application.xml or weblogic.xml for Web applications. If no version number is specified, as in Listing 4-3, the server selects the highest-versioned available deployed library named p13n-app-lib.
<library-ref>
<library-name>p13n-app-lib</library-name>
</library-ref>
If, on the other hand, you know that version 9.2.0 of p13n-app-lib is inadequate, and your application needs to use version 9.2.1 or higher, you can reference the library as shown in Listing 4-4.
<library-ref>
<library-name>p13n-app-lib</library-name>
<specification-version>9.2.1</specification-version>
</library-ref>
If you want to use a specific version, and no other version, then you can specify the <exact-match> element, as shown in Listing 4-5.
<library-ref>
<library-name>p13n-app-lib</library-name>
<specification-version>9.2.0</specification-version>
<exact-match>true</exact-match>
</library-ref>
If you are using a content repository, you need to create that repository or repositories on the destination server. To do this, use the WebLogic Portal Administration Console as explained in the Content Management Guide. This means creating only the root repositories, not the content items and types. To move items and types between environments, use the WebLogic Portal propagation tools. For more information on propagation tools, see Developing a Propagation Strategy.
You can also specify the default content repository for an enterprise application in the configuration file META-INF/content-config.xml. See Enterprise Application Deployment Descriptors for more information.
You can create and run multiple enterprise applications in a single-cluster domain. As shown in Figure 4-1, a single domain can host multiple enterprise applications (EARs). Each EAR deployment can host multiple web applications, and any number of desktops can be created based on the web applications. The web applications and desktops associated with one enterprise application (EAR) are not dependent on those in another enterprise application (they are decoupled).
The following restrictions apply to this configuration of multiple enterprise applications in a single domain:
context-root names and their associated CookieName names. For each enterprise application, the WebLogic Portal Administration Console shows all of the portal web applications that are contained in that application.| Note: | Each enterprise application must be managed through its respective WebLogic Portal Administration Console. Some domain-level resources, such as users and groups, can be viewed and managed across enterprise applications from a single WebLogic Portal Administration Console; however, be aware that data in one application may be cached, and updates to the same data made from another application’s WebLogic Portal Administration Console may not be immediately visible. |
| Note: | Content for each enterprise application is managed through its respective WebLogic Portal Administration Console and Virtual Content Repository. Virtual Content Repositories (as well as the WebLogic Portal Administration Console) are unique to each application cannot be shared. |
The best practice is to use deployment plans to modify descriptor values before deploying an application. See Using Deployment Plans. See also the WebLogic Server document “WebLogic Server Performance and Tuning.”
WebLogic Portal provides a utility for automatically deploying JSR-168 portlets that are packaged in JSR-168 WAR files. This utility lets you import JSR-168 WAR files containing JSR-168 portlets, and expose the portlets in WSRP producers.
This section explains how to use the import utility and includes these topics:
To start the utility, do the following:
http://servername:port/earProjectNameAdmin
where servername is the IP name of Administration Server, port is the port number, and earProject is the name of the portal Enterprise application that is deployed on the server. For example:
http://localhost:7001/myEarProjectAdmin
http://servername:port/earProjectAdmin/jsr168/jsr168import.jsp
where servername is the IP name of Administration Server, port is the port number, and earProject is the name of the portal Enterprise application that is deployed on the server. For example:
http://localhost:7001/myEarProjectAdmin/jsr168/jsr168import.jsp
The utility is shown in Figure 4-1.
This section explains how to use the import utility to import JSR-168 WAR files into an enterprise application.
| Tip: | You can either locate the WAR file using the Browse button or by entering the path directly in the Add JSR-168 compliant .war text field. If you enter the path in the text field, press the Tab key to accept the path. |
startWebLogic.cmd or startWebLogic.sh was run.) For a single server environment, the server start directory is the domain directory. For a managed server, the server start directory is the managed server directory. After the new EAR file is deployed, you can add the portlets contained in the imported WAR file(s) to your application. To do this, you need to add the web application(s) as WSRP producers. After a web application is added as a producer, you can incorporate the application’s portlets as you would with any WSRP producer using the WebLogic Portal Administration Console. See the Federated Portals Guide for details.
|