WAS 6.1 Profile Creation

>> Monday, November 2, 2009

This article is very technical and describes how to create a Websphere Application Server (WAS) 6.x profile that can be reused on different developer workstations. After searching the net for the recipe and not finding a complete one, we had to devise our own. The following has worked for us but may need adaptation depending on your own needs and situation.

In the following procedure, it is assumed that WAS 6.1. is installed on the workstation. The name WAS_HOME refers to the path where WAS is installed (ex: C:\IBM\WAS6.1\AppServer).

We also assume that the following folders were created:

1) Launch the profile management tool from

2) In the Profile Management Tool wizard:
  • Select the Advanced profile creationoption
  • Select Deploy the administrative console & Deploy the default application
  • Set the profile name and directory to WASDev[0n] and C:\WAS6.1\profiles\WASDev[0n] where [0n] is the profile number
  • Select Create the server using the development template
  • Unselect Make this profile the default
  • Specify the following Node name: localhostDevNode[0n]
  • Specify the following Host name: localhost
  • DO NOT enable administrative security
  • Specify Default Port Values
  • Uncheck Run the application server process as a Windows service
  • DO NOT Create a web server definition
  • Wait until the Profile Management Tool wizard has completed
  • Do not run the First Steps Console

3) Verify the content of C:\WAS6.1\profiles\WASDev[0n]\logs\AboutThisProfile.txt. It should contain something similar to this:

Application server environment to create: Application server
Location: C:\WAS6.1\profiles\WASDev02
Disk space required: 200 MB
Profile name: WASDev02
Make this profile the default: False
Node name: localhostDevNode02
Host name: localhost
Enable administrative security (recommended): False
Administrative console port: 9060
Administrative console secure port: 9043
HTTP transport port: 9080
HTTPS transport port: 9443
Bootstrap port: 2809
SOAP connector port: 8880
Run application server as a service: False
Create a Web server definition: False

4) Edit the file C:\ibm\was6.1\profiles\profiles\WASDev[0n]\config\cells\[host]Node[0n]Cell\nodes\localhostWASNode\variables.xml and substitute the following:
<entries xmi:id="VariableSubstitutionEntry_9" symbolicName="JAVA_HOME" 
  value="C:/PATH_TO_WAS_INSTALLATION/java" />
<entries xmi:id="VariableSubstitutionEntry_9" symbolicName="JAVA_HOME" 
  value="${WAS_INSTALL_ROOT}/java" />

In the same file, set the value of ORACLE_JDBC_DRIVER_PATH and other JDBC drivers paths if necessary to C:\WAS6.1\jdbcDrivers

5) Add the following files from an existing development profile to the root directory of the new profile:

WAS 6.1 Console

6) Edit the content of the file bin\setupCmdLine.bat to replace absolute references to WAS_HOME with the %WAS_HOME% expression. Alternatively, copy the bin\setupCmdLine.bat files from an existing development profile. As a reference, the bin\setupCmdLine.bat should contain something close to the following:

SET WAS_USER_SCRIPT=C:\WAS6.1\profiles\TDADev02\bin\setupCmdLine.bat
SET WAS_CELL=qcdev584Node05Cell
SET WAS_NODE=localhostDevNode02

REM Set the default OSGI -X and -D java ARGS.
SET OSGI_INSTALL=-Dosgi.install.area="%WAS_HOME%"
SET OSGI_CFG=-Dosgi.configuration.area="%USER_INSTALL_ROOT%"\configuration

REM SET ITP_LOC=%WAS_HOME%\deploytool\itp
SET CLIENTSAS=-Dcom.ibm.CORBA.ConfigURL=file:%USER_INSTALL_ROOT%/properties/sas.client.props
SET CLIENTSOAP=-Dcom.ibm.SOAP.ConfigURL=file:%USER_INSTALL_ROOT%/properties/soap.client.props
SET CLIENTSSL=-Dcom.ibm.SSL.ConfigURL=file:%USER_INSTALL_ROOT%/properties/ssl.client.props
SET JAASSOAP=-Djava.security.auth.login.config=%USER_INSTALL_ROOT%/properties/wsjaas_client.conf
SET WAS_EXT_DIRS=%JAVA_HOME%\lib;%WAS_HOME%\classes;%WAS_HOME%\lib;%WAS_HOME%\installedChannels;%WAS_HOME%\lib\ext;%WAS_HOME%\web\help;%ITP_LOC%\plugins\com.ibm.etools.ejbdeploy\runtime

SET WAS_CLASSPATH=%WAS_HOME%\properties;%WAS_HOME%\lib\startup.jar;%WAS_HOME%\lib\bootstrap.jar;%WAS_HOME%/lib/j2ee.jar;%WAS_HOME%/lib/lmproxy.jar;%WAS_HOME%/lib/urlprotocols.jar;%JAVA_HOME%\lib\tools.jar

SET WAS_LOGGING=-Djava.util.logging.manager=com.ibm.ws.bootstrap.WsLogManager -Djava.util.logging.configureByServer=true


7) Replace all occurrences of absolute paths to WAS_HOME appearing in C:\WAS6.1\*.bat files by the following variable %WAS_HOME%. For example, the file startServer.bat should contain the following:

@echo off
set WAS_USER_SCRIPT=C:\WAS6.1\profiles\TDADev02\bin\setupCmdLine.bat
call "%WAS_HOME%\bin\startServer.bat" %*

Alternatively, copy the bin\*.bat files from an existing development profile.

8) Make sure the profile is functional by going through the following steps:
  • Start the WAS server by launching startWAS61.bat
  • Open the WAS console by launching "WAS 6.1 Console"

9) Copy the required JDBC drivers (jar files) to C:\WAS6.1\jdbcDrivers

10) OPTIONAL: Configure the profile by defining the required resources (Data Sources, Mail Session, Message Queues, JAAS J2C Authentication aliases etc). Alternatively, it is possible to copy a resources.xml file from an existing WAS profile to the following folder:


For Data sources, it is important to perform a "Test connection" on each defined data source.

11) OPTIONAL: Configure (define) shared libraries for apps that point to a subfolder of C:\WAS6.1\sharedLibs (ex: C:\WAS6.1\sharedLibs\mysharedlib)

12) Test your configuration by deploying the desired target applications.


13) If the above tests are conclusive, uninstall the applications and delete the files from C:\WAS6.1\profiles\WASDev02\logs

14) Create a ZIP file using the following procedure:
- Make sure the WAS instance is stopped
- Zip the contents of the C:\WAS6.1\profiles\TDADev[0n] folder

Have fun,



Commercial or Open Source: Which One is More Agile?

>> Sunday, November 1, 2009

Is there a link between open source software and an organization's agility?

To me, that's a good question. At first, one would be tempted to say no, the type of license under which a given software artifact or system is distributed has no impact on the degree of agility of the organization that uses it. But anybody who has worked in an organization where one or the other (or both) types of licenses are used will tell you, or I expect them to tell you, that commercial software licenses tend to limit your options, your flexibility, your adaptability. Now, the lack of such qualities, in my book, tend to reduce agility, certainly not to increase it. To make my point, I tried to list the most important "rigidifying" (sic) effects of the use of commercial software licenses in an organization. Note that licensed software, for the purpose of this discussion, is any piece of software whether it is a productivity or management tool, a runtime engine, a coding or building tool, a data management system, a library or a framework incorporated in a greater ensemble.

  1. The decision making and bureaucratic process leading to the adoption of any significant piece of software is usually time consuming and arduous. When, on top of the technical and political (I was tempted by the word "religious") issues there are important budgetary and legal issues then it becomes an odyssey. In an agile organization, the decision making process should be swift and focused on the needs of the business. When it can be done without the intervention of accountants, attorneys and other peripheral stakeholders, it fits in more readily with the agile philosophy.
  2. Commercial licenses usually come with constraints. Constraints on the number of users,on the number of CPUs, they may have an expiration date, a service contract for updates and support etc. This leads sometimes to absurd (but very real) situations where a piece of software acquired for a high price is not used by all who need it because there are not enough "seats" and acquiring additional ones was not budgeted and/or approved. I was actually exposed to a situation where a bug tracking system was used by the testers but not by the developers because the number of available licenses was insufficient. Talk about something really useful and agile. In such a situation, the relative quality and feature set of a piece of software becomes irrelevant.
  3. With commercial licenses, it is often the case that the installation and distribution of copies of the software must be "managed". The number of copies installed must be monitored and the software must often be unlocked. I find that not only is commercial software more costly to acquire, it is also usually much more costly to use post-acquisition. This all adds complexity and overhead without real business value. Things that are at odds with the precepts of agility.
  4. Inertia. An agile organization should minimize inertia. However, did you ever have to convince a manager who obtained approval for a large investment in a piece of software that the software is useless or obsolete? Not an easy assignment. Often, the best decision, from a business and technical standpoint, is simply to abandon a piece of software. If there was no initial, up-front, financial commitment, the decision is often easier. Strange enough, tell a manager that he should drop a costly piece of software and use a free one instead because the free one is better, more powerful and more cost effective and you often get lot of resistance. Not a very rational stance but I guess that is human nature. There still is a strong belief that if you pay for something you will obtain more value, more service, more support. This is often true but not always. In software, strangely enough, this is not always the case and it is less and less the case. But that is possibly the subject for another article.
So long,



  © Blogger template Webnolia by Ourblogtemplates.com 2009

Back to TOP