Creating WebLogic Domains in Silent Mode -The benefits of scripted domain configurations

An enterprise development project deploying to the WebLogic platform needs to maintain several different domain configurations during the project's development, test, and deployment phases.

Version control and continuous rollout of ever-changing domain configurations to the different environments can be a challenging task. The Domain Configuration Wizard can help alleviate these challenges, because there is more to this Wizard than immediately meets the eye.

The WebLogic domain has grown from a non-existent concept in WebLogic 5.1 to become the foundation of all enterprise applications running on the latest version of the WebLogic Platform. A domain defines vital parts of an application's runtime environment, such as deciding on whether or not the application will run in a cluster, and which physical databases the application will use through the connection pool definitions.

The domain concept appeared in WebLogic Server 6.0. There wasn't much help from the platform itself when it came to creating new domains. The suggested way of doing it was to make a copy of the default domain that came with the installation, start the server in the copied domain, and use the Administration Console to add changes to it. The first version of the Domain Configuration Wizard was introduced in WebLogic Server 7.0. This version of the wizard did not have support for either WebLogic Integration or WebLogic Portal domains. In the latest version of WebLogic there are numerous ways of creating a domain using various tools in the WebLogic installation: you can use the Domain Configuration Wizard, the WebLogic.Server command, or Ant scripts with the wlserver and wlconfig Ant tasks. This shows that BEA has taken the message from the developers seriously: help us make it easier to create WebLogic domains! In this article we will take a closer look at the Domain Configuration Wizard, focusing on how to use the least documented (until now) of its three running modes, the Silent mode. (In addition, as you probably know, it can be run in GUI mode and Console mode.)

The Domain Configuration Wizard has matured, and now covers the complete range of domains by default. The GUI mode is relatively easy to use, even if you have to be prepared to go through a lot of screens to configure, say, a clustered portal domain with a couple of connection pools and some JMS destinations. We feel that the main challenge with this approach in an enterprise project is maintaining several changing domain configurations for parallel environments like development, test, and production. On top of this, developers normally have their own local servers with local database settings and local JMS destinations. For all but the very smallest projects, we cannot base these domain configurations on manual creation through the Domain Configuration Wizard. We need to be able to repeatedly create our domains from scratch in a consistent way on various deployment targets. We also want to be able to put our various domain configurations under source control. Domain Configuration Wizard's Silent Mode gives us the opportunity to do just that through domain configuration scripting.

The Domain Configuration Wizard is located below WL_HOME/common/bin, where WL_HOME is BEA_HOME/weblogic81. Start it by running the config.cmd. To run it in Silent Mode, you set the mode parameter to silent, and tell it where to find your silent configuration script.

On Windows:

config.cmd ?mode=silent ?silent_script=<silent script file>

On Unix/Linux:

./config.sh ?mode=silent ?silent_script=<silent script file>

It all happens inside the silent script file. This script file contains the complete domain configuration. The language used in this file is fairly simple to understand, even if it is proprietary. It is well documented in BEA edocs.

The default installation comes with an example silent script located in WL_HOME/common/templates/domains/silent_scripts". We'll now go through this example step by step.

A WebLogic domain can be one of five different domain types, accessible through domain templates. The first thing to do is to decide on the type of domain by choosing what domain template file we want to use. The domain template files are located in the "WL_HOME/common/templates/domains/" directory. The different domain templates are:

• Workshop domain (wlw.jar)

• Integration domain (wli.jar)

• Portal domain (wlp.jar)

• Server domain (wls.jar)

• WebLogic Platform domain (platform.jar).

The domain template files are included in the installation of BEA WebLogic Platform 8.1. For this example we chose a WebLogic Server domain; hence wls.jar is the template file. We now read in all the data that is included in the default server domain.

//Read in a domain template.
read template from "WL_HOME/weblogic81/common/templates/domains/wls.jar";

The default server domain has configured an admin server called "myserver". We now set the address, the port, and SSL.

//Find and configure the Admin Server.
find Server "myserver" as s1;
set s1.ListenAddress "localhost";
set s1.ListenPort "7001";
set s1.SSL.Enabled "true";
set s1.SSL.ListenPort "7002";

We want to create a JMSQueue in the domain. Fist we create a JMSServer, then we create the JMSQueue and set the properties for this queue. Finally, we target the JMSServer to the "myserver" that is the default server in the "wls.jar" template file.

//Create a JMSQueue.
//A JMSServer has to be created first.
create JMSServer "myJMSServer" as jmsserver;
create JMSQueue "myJMSQueue" as myq;
//required attribute
set myq.JNDIName "jms/myjmsqueue";
//required attribute
set myq.JMSServer "myJMSServer";
//optional attribute
//set myq.StoreEnabled "false";
//target "myJMSServer" to server "myserver"
assign JMSServer "myJMSServer" to target "myserver";

We want to create a connection pool in the WebLogic Server domain. In the example we use the PointBase database thet follows the BEA Weblogic Platform 8.1 installation. The connection pool is created and targeted to "myserver".

//Create a JDBCConnectionPool.
create JDBCConnectionPool "demoPool" as mypool;
//required attribute
set mypool.DriverName "com.pointbase.jdbc.jdbcUniversalDriver";
//required attribute
set mypool.URL "jdbc:pointbase:server://localhost:9092/demo";
//required attribute
set mypool.Password "PBPUBLIC";
//optional attribute (but it's recommended you set the db user...)
set mypool.Properties "user=PBPUBLIC";
//target all JDBC connection pools to server "myserver"
assign JDBCConnectionPool "*" to target "myserver";

It is possible to target applications to the server during configuration of the domain. The "wls.jar" template does not contain any application and hence this code is commented out:

//target existing applications.
//target applications only when they exist in current domain template
//assign application "*" to target "myserver";

We now want to change the password for the webloic user. We find the user and then sets the password.
//Create the admin user and password.
find User "weblogic" as u1;
set u1.password "weblogic";

Now we'll write the domain to disk. The domain is written to the specified path. The last folder in the path is the name of the domain. The domain name is wls.

//Write out the domain.
set OverwriteDomain "true";

Write the domain to "C:\bea/user_projects/domains/wls";

At last we close the template file.

//Close domain template to indicate completion of work.
close template;

In Listing 3 we have added a more complex example. Here we create a cluster with an admin server and two managed servers in a WebLogic Platform domain. The database used is an Oracle 9i database.

To be able to easily handle different domain configurations, we have replaced the script file's values with tokens. We use an Ant script to build the domain and replace the tokens with actual properties. Extracting the domain configuration file's values into property files makes it simple to handle different domain configurations, and they can easily be put under source control. The property file for the Ant script is referenced in the top of the Ant build file; in this example the name of the property file is "domain.properties". The property file must be modified to fit the chosen environment with properties for domain name, domains folder, portal database attributes such as URL, username, pass, etc., and all server attributes such as server URL, port, SSL-port etc.

The domain is now easily created by running the "build.domain" target in the Ant build file. Because of dependencies in the Ant build file, the following targets are called in sequence:

• "init" target: Creates the temporary build folder

• "copy" target: Copies the original silent script file into the temporary build folder

• "replace.silentfile" target: Replaces all the tokens in the silent script file with the value given in the "domain.properties" file

• "build.domain" target: Calls the Configuration Wizard Program (config.cmd) with the newly created silent script file as parameter

• "clean" target: Removes all the temporary files and folders

The domain is now created in the path and the name specified in the "domain.properties" file and ready to use. The Ant script and an example property file are shown in Listings 2 and 4.

Conclusion

The domain concept has become a vital part of the BEA WebLogic Platform, defining the applications' runtime environment. In projects with repeated deployments to various targets, it is important to be able to create and recreate the WebLogic domains in an effective and consistent way. It is also important to have these domain configurations under source control. Domain Configuration Wizard's Silent Mode achieves this by providing support for scripting of the domain configuration. This article described the benefits of using scripted domain configurations, and how to use the Silent Mode through an explanation of a scripted domain configuration. It also showed how to extract the Silent Mode script's values into a property file and how to use an Ant script to control the domain creation. We used Silent Mode on several projects and believe this is a good way to effectively and consistently create WebLogic domains.

Source : http://www.sys-con.com/