Rational WebSphere

Installing Rational Software Architect Standard Edition 7.5.4 on Ubuntu 9.10

2009-11-01T03:18:00.000-08:00

When installing Rational Software Architect Standard Edition 7.5.4 (and RAD 7.5.4) onto Ubuntu 9.10 it is likely that you might experience a few problems. This posting identifies these problems and their solutions.

The first is a missing library:

http://packages.ubuntu.com/jaunty/i386/libstdc++5/download

The second is an SWT error inside your initial workspace's .log file: /home/jsears/IBM/rationalsdp/workspace/.metadata, with: org.eclipse.swt.SWTError: XPCOM error.

sudo apt-get install xulrunner
sudo vi /opt/IBM/SDP/eclipse.ini with -Dorg.eclipse.swt.browser.XULRunnerPath=/usr/lib/xulrunner

The third problem is to do with GTK affecting various buttons such that a mouse click is not enough for the button to be dismissed. The answer to this is to invoke eclipse not by the main menu but via a .sh script (with an icon image of /opt/IBM/SDP/rsa_se/RSA_v7_32.xpm):

export GDK_NATIVE_WINDOWS=true
/opt/IBM/SDP/eclipse -product com.ibm.rational.rsastd.product.v75.ide

Only by carrying out these things was I able to start the IDE and use it as expected:

A quick update - as of 20110414 I read that you can bypass the xulrunner need (handy if you have istalled Firefox 4):

http://www.eclipse.org/swt/faq.php#browserwebkitgtk
./eclipse -vmargs -Dorg.eclipse.swt.browser.UseWebKitGTK=true

Using a WebSphere Scheduler

2009-09-04T07:00:00.001-07:00

This posting demonstrates using a WebSphere Application Server Scheduler (tested in 6.0.2.35, but highly likely to be applicable upto 7.0) in the following way:

Setting up a standard apache Derby database to hold the scheduler tables.
Creating a WAS scheduler that is callable via JNDI (and uses tables in the derby database).
Producing an .ear file containing three components: a servlet and two, minimalist, stateless EJB's that demonstrate the important scheduler API's.
Invoking the API and seeing the expected output.

Code in the doGet of the servlet registers the EJB's with the scheduler. Doing this allows the scheduler to callback relevant methods either at the scheduled time or for when the state of the scheduled task changes...

The optional EJB uses a public void handleEvent(TaskNotificationInfo arg) method that gets invoked by the scheduler so that events related to the management of the scheduled task can be intercepted (if you want) by your business logic - e.g. a TaskNotificationInfo.PURGED notification.
The mandatory EJB implements a public void process(TaskStatus arg) method, that gets invoked by the scheduler and carries out your business logic.

Set up the Derby database

The SQL used for creating the derby tables, required by the scheduler, is shipped in the Scheduler folder - for me that was /home/jsears/IBM/WebSphere/7/AppServer1/Scheduler.

Basically I took the createSchemaMod1Derby.ddl file from my WAS 7 instance, created the database and then pointed my WAS 6.0 scheduler at it. I used this combination because RAD 6.0 and WAS 6.0 are my primary environments.

The .ddl has to be modified with some variable substitution, for example: "CREATE TABLE @TABLE_QUALIFIER@@TABLE_PREFIX@TASK ("TASKID" BIGINT NOT NULL ," became "CREATE TABLE TBLTASK ("TASKID" BIGINT NOT NULL ,". I saved the result in a derby.sql file.

From the command line (after downloading and extracting derby) I exported the following variables:

export DERBY_HOME=/home/jsears/local/tmp3/db-derby-10.5.3.0-bin
export CLASSPATH=$DERBY_INSTALL/lib/derbyclient.jar:$DERBY_INSTALL/lib/derbytools.jar:.

I then started the derby server:

java -jar $DERBY_HOME/lib/derbyrun.jar server start

I then ran the ddl file (via a new terminal with the export's):

java -jar $DERBY_HOME/lib/derbyrun.jar ij
connect 'jdbc:derby://localhost:1527//home/jsears/local/tmp3/MyDbTest;create=true';
run '/home/jsears/local/tmp3/derby.sql';
show tables;

I then set up security:

CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.user.user1', 'password1');
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.connection.requireAuthentication', 'true');
disconnect;
connect 'jdbc:derby://localhost:1527//home/jsears/local/tmp3/MyDbTest;user=user1;password=password1';
exit;

Create The Scheduler
Through the WebSphere Administrative console I created the database stuff first and then the scheduler stuff:

Security > Global security > JAAS Configuration > J2C Authentication data > New ...

Username and Password values as above, from derby setup, for jsears-desktopNode01/MyDerbyUID:

Resources > JDBC providers @ Server level > New ...

Name = Derby JSEARS 01
Class path = /home/jsears/local/tmp3/db-derby-10.5.3.0-bin/lib/derbyclient.jar
Implementation class name = org.apache.derby.jdbc.ClientConnectionPoolDataSource

JDBC providers > Derby JSEARS 01 > Data sources > New ...

Name = Derby Network Server DataSource
JNDI name = jdbc/DerbyNSDS
Component-managed authentication alias = jsears-desktopNode01/MyDerbyUID
When created press the "Test connection" button!

JDBC providers > Derby JSEARS 01 > Data sources > Derby Network Server DataSource > Custom properties

databaseName = /home/jsears/local/tmp3/MyDbTest
serverName = localhost
portNumber = 1527

Resources > Schedulers @ Server Level > New ...

Name = MyScheduler
JNDI name = sched/MyScheduler
Data source JNDI name = jdbc/DerbyNSDS
Data source alias = jsears-desktopNode01/MyDerbyUID
Table prefix = tbl
Work managers = Default Work Manager
When completed press the "Verify tables" button!

Use the API's
The servlet looks like this, in my mind the important bit is how the call backs are registered:

The first EJB is the optional one:

And here is the mandatory EJB:

What is most important is how the deployment descriptor looks (take into account that this was coded in a RAD 6 IDE). In particular how the tag values mean that these interfaces do not have to be coded in java.

NOTE: use the following in RAD as the JDBC Driver class if you want to connect RAD to derby: org.apache.derby.jdbc.ClientDriver

Invoke the API
Figure out what the appropriate BOOTSTRAP_ADDRESS + WC_defaulthost ports are of the servlet:

Servers > Application Servers > server1 > Ports

And then call the servlet:

http://127.0.0.1:9081/SchedWebApp/Main/

Finally, you should end up with something like this:

Updating / Patching WebSphere Application Server

2009-07-10T07:44:00.000-07:00

Figure out which fixpack you want by visiting the IBM Recommended fixes for WebSphere Application Server page.

Next visit the IBM Maintenance Download Wizard for WebSphere Application Server V7.0 site and download the maintenance wizard:

With the Wizard, once you have extracted and installed it, you'll load the fixpack and basically patch your existing WebSphere install. For me, on Ubuntu 9.04, it was a straight forward process for both my 6.0 and 7.0 installs.

JavaMail on WebSphere

2009-07-03T06:49:00.000-07:00

Creating a mail resource - whereby you use JNDI to get a context that you send email through - is surprisingly easy in WebSphere, at least for my minimal requirements :-)

I reused the Built-in Mail Provider @ server level:

...and then created my own mail session:

Mail Providers > Built-in Mail Provider > Mail Sessions

Name = MyMailSession
JNDI name = mail/MyMailSessionMail
transport host = 192.168.192.5
Mail transport user ID = wiki
Mail transport password = wiki
Enable debug mode = ticked

Next I created a very simple servlet, whose doGet method grabs the JNDI context and then uses the JavaMail API to send an email:

I pulled in the JNDI reference straight from the web container, but I could have used an environmental reference from the web.xml file:

Because the SMTP debugging was on I got output that looked like the following and that resulted in an email being sent to me :-)

NOTE: a useful reference is at http://www.ibm.com/developerworks/websphere/library/techarticles/0310_fung_yu/fung_yu.html

Creating & Referencing a JDBC JNDI Data Source

2009-07-03T06:02:00.001-07:00

Here is how to create & reference a MySQL data source in WAS - one that can be retrieved using JNDI and features connection pooling. An example of how to call the data source, from a simple .war application running in the local container is also shown.

NOTE:

The instructions below apply to WebSphere Application Server 6.0.2.35 on Ubuntu 9.04, however I've also tested them successfully on in i5 WAS V6.1.0.11 Express instance - but bear in mind that some of the steps are slightly different (easier) due to the more modern version of WAS (best used via IE6 as the client IMO!)

Create The Data Source
1. Resources > JDBC Providers @ Server level (the default for all of these instructions) > New...

For General properties I used "User-defined"

After clicking Next I provided the following details

Name = MySQL JDBC Provider
Class path = ${USER_INSTALL_ROOT}/mysql/mysql-connector-java-5.1.8-bin.jar - this equated to /home/jsears/IBM/RAD-6.0/runtimes/base_v6/profiles/AppSrv01/mysql
Implementation class name = com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource

2. Security > Global security > JAAS Configuration > J2C Authentication data > New

Alias = MySQLUID - WAS renamed this to jsears-desktopNode01/MySQLUID
User ID = root
Password = mysql

3. Resources > JDBC providers > MySQL JDBC Provider > Data sources > New

Name = MySQL
JNDI name = jdbc/MySQL
Component-managed authentication alias =jsears-desktopNode01/MySQLUID

4. Resources > JDBC providers > MySQL JDBC Provider > Data sources > MySQL > Custom Properties

databaseName = bugs - I referenced a BugZilla install on a separate server
port = 3306
serverName = 192.168.192.110

5. Resources > JDBC providers > MySQL JDBC Provider > Data sources > MySQL > WebSphere Application Server data source properties

Statement cache size = 10
Pretest connections = ticked

6. Resources > JDBC providers > MySQL JDBC Provider > Data sources > MySQL > Test connection

NOTE: first restart WAS!

Reference The Data Source
1. Create a simple Servlet, with a doGet method, and flesh it out - the important thing will be the JNDI reference line:

DataSource ds = (DataSource) ctx.lookup("java:comp/env/MySQLResourceReference");

2. Against the web.xml deployment descriptor, using RAD, I added the Resource Reference to a data source:

Thus, after writing a very simple doGet I ended up with the following container based servlet that called the JNDI reference via indirection in the web.xml deployment descriptor:

I accepted all the defaults when uploading the .war - including the "Map resource references to resources" options, as I had already defined the details previously:

The URL I used, once the application was started, to invoke this servlet was: http://127.0.0.1:9081/ReferenceJNDIdataSource/ReferenceJNDIdataSource

Message Driven Beans in WebSphere Application Server 6+

2009-06-29T13:18:00.001-07:00

Creating a basic Message Driven Bean is quite straightforward, the hard part is setting up the WebSphere Application Server embedded JMS details and making sure your deployment references the correct details.

An MDB is invoked asynchronously when a JMS message is put on a destination. The destination needs to be known before deployment as the soon to be created .EAR, holding our MDB, contains a deployment descriptor - ejb-jar.xml - that references the destination. Part of the deployment process, via the WebSphere Administrative Console, also references a JMS activation specification that can be said to be part of setting up the embedded JMS.

Set up WAS embedded JMS
1. Create a new Service Integration Bus, called "B1":

Service Integration > New > accept all defaults

2. Assign "B1" to the Server, accepting all the defaults:

Service Integration > Buses > B1 > Bus members

3. On "B1" create a destination, "Q1", accepting all defaults:

Service Integration > Buses > B1 > Destinations > New > Queue

4. Create a new JMS queue, accepting all defaults unless shown below:

Resources > JMS Providers > Default messaging provider @ Server level > JMS queue
Name = JMS_Q
JNDI name = jms/JMS_Q1
Bus name = B1
Queue name = Q1
Delivery mode = Persistent

5. Create a new JMS connection factory, accepting all defaults unless shown below:

Resources > JMS Providers > Default messaging provider @ Server level > JMS connection factory
Name = JMS_CF1
JNDI name = jms/JMS_CF1
Bus name = B1

6. Create a new JMS queue connection factory, accepting all defaults unless shown below:

Resources > JMS Providers > Default messaging provider @ Server level > JMS queue connection factory
Name = JMS_QCF1
JNDI name = jms/JMS_QCF1
Bus name = B1

7. The final part is creating an activation specification:

Resources > JMS Providers > Default messaging provider @ Server level > JMS activation specification > New
Name = JMS_AS1
JNDI name = eis/JMS_AS1
Destination Type = Queue
Destination JNDI name = jms/JMS_AS1
Bus name = B1

8. In order for WAS to recognise the JMS details we've just created unfortunately we need to restart WAS.

Use RAD to construct a very simple MDB & deploy it
1. You'll end up with 3 very small projects, the key files are the ejb-jar.xml deployment descriptor...
...and the bean itself (notice the onMessage method I've fleshed out)

2. Deploy the .EAR file and provide the following information for the activation specification of:

JNDI name = eis/JMS_AS1
Destination JNDI Name = jms/JMS_Q1

3. Test the MDB is listening by sending a message with the Universal Test Client:

http://localhost:9081/UTC/initialize?port=2810&wasAdminPort=2810&wasAdminConn=RMI > Utilities > Send JMS Message
Queue JNDI Name = jms/JMS_Q1
Queue CF JNDI Name = jms/JMS_QCF
Message = hello world
if the MDB is not deployed then look in: Buses > B1 > Destinations > Q1 > Queue points > Q1@jsears-desktopNode01.server1-B1 >
else, look in the console window (as we had System.out logging there from the MDB):

log4j and WebSphere

2009-06-29T13:05:00.000-07:00

Porting an application from Tomcat 5+ to WebSphere 6+ raises the question: what about the log4j log file? The following simple application demonstrates porting from one to the other with the minimum of hassle.

The first step is to create a minimal servlet application in the IDE (unless otherwise stated, accepting all the defaults):

I used the rather ancient Rational Software Development Platform as my IDE:

However, the project can just as easily be created / imported in RAD 7.5.n (or a non Rational version of eclipse):

My Servlet looked like this:


package jsears;

import java.io.IOException;
import java.io.PrintWriter;

import javax.servlet.Servlet;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.apache.log4j.Logger;

/**
* Tomcat = http://127.0.0.1:8080/log4j/main
* WebSphere = http://127.0.0.1:9080/log4j/main
*
* @author jsears
*
*/
public class Main extends HttpServlet implements Servlet {
private static final long serialVersionUID = 233300306772977426L;

protected static final Logger logger = Logger.getLogger(Main.class);

private static String sessionId = null;

public static synchronized String getSessionId() {
 return Main.sessionId;
}

protected void doGet(HttpServletRequest arg0, HttpServletResponse arg1)
     throws ServletException, IOException {
 sessionId = arg0.getSession().getId();

 logger.debug(sessionId);

 PrintWriter out = arg1.getWriter();
 out.println(sessionId);
 out.close();
}
}

The only library I added to the project was log4j that I downloaded from http://logging.apache.org/log4j/1.2/index.html.

I also created a second class, inherited from PatternLayout, that allows me to see the sessionId for each client in a single log file. Its not needed for getting lo4j to work, just that its a handy class to keep track of in this blog :-)


package jsears;

import org.apache.log4j.PatternLayout;
import org.apache.log4j.spi.LoggingEvent;

public class HelperLayout extends PatternLayout {
StringBuffer stringBuffer = new StringBuffer(128);

private String getSessionId() {
 return Main.getSessionId() + ": ";
}

public void activateOptions() {
 return;
}

public String format(LoggingEvent event) {
 return getSessionId() + super.format(event);
}

public boolean ignoresThrowable() {
 return true;
}
}

Finally, I added the following two files - so that they were on the classpath and ended up inside WEB-INF/classes:

commons-logging.properties

# Set application classloader mode as PARENT_LAST when deploying in WAS as .ear
priority=1
org.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.LogFactoryImpl

log4j.properties

# HIERARCHY: ALL > DEBUG > INFO > WARN > ERROR > FATAL > OFF

# Everything ###############################################################
#log4j.rootCategory=OFF, file

# application ###############################################################
log4j.logger.jsears=ALL, out, file

# Get rid of various Tomcat "WARN No appenders" complaints
log4j.logger.org.apache.catalina=OFF

# Appender definitions ########################################################
log4j.appender.out=org.apache.log4j.ConsoleAppender
log4j.appender.out.target=System.out

log4j.appender.file=org.apache.log4j.RollingFileAppender
log4j.appender.file.MaxFileSize=5MB
log4j.appender.file.MaxBackupIndex=5

# Tomcat
#log4j.appender.file.File=${catalina.home}/logs/log4j.log

# WAS - e.g. use this line when deploying into WAS
log4j.appender.file.File=${LOG_ROOT}logs/log4j.log

# Appender layouts ##########################################################
log4j.appender.out.layout=jsears.HelperLayout
log4j.appender.out.layout.ConversionPattern=%-5p: %d{dd MMM yyyy HH:mm:ss,SSS}: %C{1},%L: %m%n

log4j.appender.file.layout=jsears.HelperLayout
log4j.appender.file.layout.ConversionPattern=%-5p: %d{dd MMM yyyy HH:mm:ss,SSS}: %C{1},%L: %m%n

Depending on where you are porting the application to - from WebSphere to Tomcat, or vice versa - then you need to comment out the appropriate Tomcat or WAS line in the log4j.properties file.

I did not bundle the servlet into an .ear file - instead I specified the context when I uploaded / installed it into WebSphere:

Specifying a .war context in WebSphere Application Server 6.0.2.33

Specifying a .war context in WebSphere Application Server 7.0.0.0 ND

I exported the .war file from the IDE and have successfully deployed it in WAS 6 through to WAS 7 as well as Tomcat 5.5.27 - all running on Ubuntu 9.04. The only change that I needed to make was in the log4j.properties file - uncommenting / commenting out the appropriate file appender line.

In WebSphere the logfile will appear in your profiles folder - e.g. AppServer1/profiles/AppSrv01/logs. Similarly, in Tomcat it will appear in the logs folder.

NOTE: A useful reference to this is at http://wiki.apache.org/jakarta-commons/Logging/FrequentlyAskedQuestions

How to configure WAS Custom Security

2009-06-29T12:56:00.000-07:00

When configuring Custom Security it is sometimes useful to know how to create / delete a server profile, and this is what I'll first document.

Creating a Profile
It is possible to create a server profile from the Rational Application Developer IDE, or, from the command line. Each profile ends up in its own sub-folder - e.g. AppSrv01 - in the profiles folder in the WAS install folder.

In the IDE, profile creation can be carried out using the Window > Preference dialog:

Or from the - my - command line:

/home/jsears/IBM/RAD-6.0/runtimes/base_v6/bin/ProfileCreator/pctLinux.bin
/home/jsears/IBM/WebSphere/<6.1>/AppServer1/bin/ProfileManagement/pmt.sh

WAS 6.1.0.0 Profile Management Tool

WAS 7.0.0.0 ND Profile Management Tool

It is possible to delete and remove profiles by using "rm -f" from the profile directory and editing a profileRegistry.xml file. For me, using the IDE version of WAS, this was: /home/jsears/IBM/RAD-6.0/runtimes/base_v6/properties/profileRegistry.xml. Alternately, if you used the default installation of WAS then (at least on Ubuntu 9.04) it should be: /opt/IBM/WebSphere/AppServer/properties/profileRegistry.xml

Once you have created a profile you need to register it in the IDE like any other Server:

Once registered you then need to start the server profile, either via the IDE or using the "First steps" front end - .../profiles/AppSrv01/firststeps/firststeps.sh.

Configuring Custom Security
Once you have a clean profile running then this is what I did to create a Standalone custom registry - in this case for WebSphere 7.0.0.0 ND (but the information holds near identically true for previous versions of WebSphere).

Login in to WebSphere, for me this was: http://localhost:9066/ibm/console/unsecureLogon.jsp
Navigate to Security > Global security
Set Available realm definitions (or Active user registry in 6.0.2.35) drop list to "Standalone custom registry" and press the "Configure..." button (or the "Custom user registry" link in 6.0.2.35):

In the file system create a localAuthentication folder in your profile - for me this was: .../profiles/AppSrv01/localAuthentication/

Back on the Global security > Standalone custom registry page, complete the following (and then press the OK button and the Save link):
Primary administrative user name = corey
The Custom name value properties are:

usersFile = ${USER_INSTALL_ROOT}/localAuthentication/users.props

# name:passwd:uid:gids:display name
corey:corey1:2:567:
dave:dave1:2:567:
bob:bob1:3:567:
ethel:ethel1:4:567:

groupsFile = ${USER_INSTALL_ROOT}/localAuthentication/groups.props

# name:gid:user<,>:display name
admins:567:corey,bob:Administrators

NOTE: the format of these two properties files is related to the built-in FileRegistrySample class: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/rsec_frsjf502.html

Press the "Set as current" button against the "Standalone custom registry"
Tick "Enable administrative security" (or "Enable global security" in prior versions) - your single tick will also tick the "Enable application security" & "Java 2 security" tick boxes. Untick the "Java 2 security" tick box. Next, press the "Apply" button.
Then Apply / save the settings.
In the RAD IDE goto the Server > Servers view and double click on the WAS server and complete the Security section with the details of either bob or corey (from the users.props file). Don't forget to save the details page!

Restart WAS :-( and login with: https://localhost:9049/ibm/console/logon.jsp (or whatever port is appropriate to your profile). Your browser might not recognise the SSL certificate, so you might need to add an exception:

Once you have loged with corey/corey1 then you can assign declarative authorization to your applications / resources - i.e. URI's or methods on Servlets or EJB's.

WebSphere Thin Client with various JVM's

2009-06-25T02:32:00.000-07:00

Definitions of a "Thin Client" seem to vary. In the context of this post a Thin Client is an application that calls upon the resources of WebSphere via JNDI but that is initialized outside of WebSphere.

The IBM Thin Client is an optional component of the default WebSphere install, which I downloaded from http://ibm.com/partnerworld/ - using credentials.

I downloaded and installed Application Clients for two Linux WAS versions, 6.0 and 7.0...

WebSphere Application Server Network Deployment V6.0 Application Server, IBM HTTP Server, Web server plug ins, Application Clients for Linux, 32-bit support Multilingual:

-rw-r--r-- 1 jsears jsears 541969911 2009-06-23 20:28 C5882ML.tar.gz

IBM WebSphere Application Server Network Deployment V7.0 for Linux:

-rw-r--r-- 1 jsears jsears 821368441 2008-10-10 16:21 C1G32ML.tar.gz

As with installing the Server (v7.0), ignore the warning!

I installed /home/jsears/IBM/WebSphere/AppClient/6.0/samples/lib/TechnologySamplesThinClient/BasicCalculatorEJB.jar into my, Ubuntu 9.04 based, WAS ND v7, accepting all the defaults.

Perhaps surprisingly ;-) - as we are using a v6.0 ejb in a v7.0 server - it installed and started without any problems:

Next I changed my path to pick up the bin folder of the AppClient install, and then invoked the client:

On windows this would be something like:

set PATH=C:\Program Files\IBM\WebSphere\AppClient\bin;%PATH%
cd C:\Program Files\IBM\WebSphere\AppClient\samples\bin\TechnologySamplesThinClient\BasicCalculator\
basicCalculator.bat

On ubuntu 9.04 it was:

PATH=/home/jsears/IBM/WebSphere/AppClient/6.0/bin:$PATH
export PATH
cd /home/jsears/IBM/WebSphere/AppClient/6.0/samples/bin/TechnologySamplesThinClient/BasicCalculator
./basicCalculator

What might not be so obvious is that the basicCalculator script is using the IBM JVM that ships with the AppClient, not the one installed on you path (OpenJDK in the case of Ubuntu):

In my experiance installing another JVM on a client / production machine, unless for a specific reason, is too much hassle. So, to use the default Ubuntu 9.04 JVM, OpenJDK, I did the following:

Download the IBM Client for JMS on J2SE with IBM WebSphere Application Server from ftp://ftp.software.ibm.com/software/websphere/appserv/support/tools/JMSclient/sibc_install-o0902.06.jar and extract the following jars (via java -jar sibc_install-o0902.06.jar jms_jndi_sun):
sibc.jms.jar
sibc.jndi.jar
sibc.orb.jar

Next create a go.sh file, as below, to successfully invoke the BasicCalculatorClientThinMain class:

#!/bin/sh
# /home/jsears/IBM/WebSphere/AppClient/6.0/samples/bin/TechnologySamplesThinClient/BasicCalculator/go.sh
java \
-classpath sibc.jms.jar:sib.jndi.jar:sibc.orb.jar:/home/jsears/IBM/WebSphere/AppClient/6.0/lib/naming.jar:/home/jsears/IBM/WebSphere/AppClient/6.0/lib/namingclient.jar:/home/jsears/IBM/WebSphere/AppClient/6.0/lib/idl.jar:/home/jsears/IBM/WebSphere/AppClient/6.0/lib/j2ee.jar:../../../lib/TechnologySamplesThinClient/BasicCalculatorClientCommon.jar:../../../lib/TechnologySamplesThinClient/BasicCalculatorThinClient.jar:../../../lib/TechnologySamplesThinClient/BasicCalculatorEJB.jar \
-Djava.naming.provider.url=iiop://127.0.0.1:2809 \
-Djava.naming.factory.initial=com.ibm.websphere.naming.WsnInitialContextFactory \
-Dcom.ibm.CORBA.ConfigURL=file:/home/jsears/IBM/WebSphere/AppClient/6.0/properties/sas.client.props \
-Dcom.ibm.CORBA.ORBInit=com.ibm.ws.sib.client.ORB \
com.ibm.websphere.samples.technologysamples.basiccalcthinclient.BasicCalculatorClientThinMain add 1 2

Running this shell script means we have a non IBM JVM invoking an EJB inside WebSphere 6.0 or WebSphere 7.0 on Ubuntu.

As an aside, I also successfully tested go.sh against a iSeries WebSphere Express 6.1.0.11 hosting the BasicCalculatorEJB.jar & changing the naming.provier url above to the new host and iiop bootstrap port:

NOTES:

This shell script was successfully tested, on Ubuntu 9.04, using the following non IBM JVM's:

java version "1.6.0_0"
OpenJDK Runtime Environment (IcedTea6 1.4.1) (6b14-1.4.1-0ubuntu7)
OpenJDK Client VM (build 14.0-b08, mixed mode, sharing)

java version "1.6.0_13"
Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode, sharing)

The IBM provided BasicCalculatorClient source code is the same for v6.0 and v7.0 of WebSphere installs!
This has not, successfully, been tested with JAAS.

WebSphere EJB Thin Client JAAS example on Ubuntu 9.04

2009-06-23T10:26:00.000-07:00

This posting shows you how to invoke an EJB using JAAS from a thin client (a junit test case) via SSL. This is all on Ubuntu 9.04.

The code was first developed in RAD 6.0.1 (20050725_1800) and then imported into RAD 7.5.3. The example session EJB runs unchanged, bar IDE compiler compliance level, in WAS 6.0.2.35 and WAS 7.0.0.0. ND.

The example keeps coding to the minimum but still demonstrates declarative and programmatic custom security.

The important precondition to getting this to work is making sure that security is enabled in WAS - I enabled custom security for this. Apart from what is written below, everything is default generated using the RAD wizards.

Project Creation
The example is broken down into four projects (wizard driven in their creation):

EJB1 - holds the stateless session bean as well as the important ejb-jar.xml deployment descriptor and its equally important ibm-ejb-jar-bnd.xmi companion.
EJB1Client - holds the home and remote interfaces for the EJB1 project.
EJB1EAR - used to export the .ear file, but also holds the important application.xml and the ibm-application-bnd.xmi files.
EJB1Test - holds the junit test case; eclipse runtimes (with the correct classpath & JRE references); and WAS configuration / localisation details.

The importance of all of the .xml deployment descriptors and their companion .xmi files can not be understated. As its these that define the declarative security constraints:

EJB1
Apart from the security constraints implied on it by the deployment descriptors, the SessionBean1Bean demonstrates some useful programmatic security API's in a very simple business logic method:


   System.out.println("subject=" + WSSubject.getCallerSubject());
   System.out.println("user=" + getSessionContext().getCallerPrincipal().getName());
   System.out.println("RoleA=" + getSessionContext().isCallerInRole("RoleA"));
   System.out.println("RoleB=" + getSessionContext().isCallerInRole("RoleB"));

The declarative security is defined in the deployment descriptors:

ejb-jar.xml

<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar id="ejb-jar_ID" version="2.1"
 xmlns="http://java.sun.com/xml/ns/j2ee"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd">
 <display-name>EJB1</display-name>
 <enterprise-beans>
  <session id="SessionBean1">
   <ejb-name>SessionBean1</ejb-name>
   <home>jsears.SessionBean1Home</home>
   <remote>jsears.SessionBean1</remote>
   <ejb-class>jsears.SessionBean1Bean</ejb-class>
   <session-type>Stateless</session-type>
   <transaction-type>Container</transaction-type>
   <security-role-ref>
    <description></description>
    <role-name>RoleA</role-name>
    <role-link>RoleA</role-link>
   </security-role-ref>
   <security-role-ref>
    <description></description>
    <role-name>RoleB</role-name>
    <role-link>RoleB</role-link>
   </security-role-ref>
  </session>
 </enterprise-beans>
 <assembly-descriptor id="AssemblyDescriptor_1247566653738">
  <security-role>
   <role-name>RoleA</role-name>
  </security-role>
  <security-role>
   <role-name>RoleB</role-name>
  </security-role>
  <method-permission>
   <role-name>RoleA</role-name>
   <role-name>RoleB</role-name>
   <method>
    <ejb-name>SessionBean1</ejb-name>
    <method-name>*</method-name>
   </method>
  </method-permission>
 </assembly-descriptor>
 <ejb-client-jar>EJB1Client.jar</ejb-client-jar>
</ejb-jar>

ibm-ejb-jar-bnd.xmi


<?xml version="1.0" encoding="UTF-8"?>
<ejbbnd:EJBJarBinding xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:ejb="ejb.xmi" xmlns:ejbbnd="ejbbnd.xmi" xmi:id="EJBJarBinding_1249651772497">
<ejbJar href="META-INF/ejb-jar.xml#ejb-jar_ID"/>
<ejbBindings xmi:id="EnterpriseBeanBinding_1249651772497" jndiName="ejb/jsears/SessionBean1Home">
<enterpriseBean xmi:type="ejb:Session" href="META-INF/ejb-jar.xml#SessionBean1"/>
</ejbBindings>
</ejbbnd:EJBJarBinding>

EJB1Client
Not much is worth mentioning about the Home and Remote interfaces - they are bog standard, and there's no deployment descriptors to worry about:

EJB1EAR
The only thing the EJB1EAR project contains are a couple of, important, deployment descriptors:

application.xml


<?xml version="1.0" encoding="UTF-8"?>
<application id="Application_ID" version="1.4"
 xmlns="http://java.sun.com/xml/ns/j2ee"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/application_1_4.xsd">
 <display-name>EJB1EAR</display-name>
 <module id="EjbModule_1247566458176">
  <ejb>EJB1.jar</ejb>
 </module>
 <security-role id="SecurityRole_1247569173615">
  <role-name>RoleA</role-name>
 </security-role>
 <security-role id="SecurityRole_1247569173624">
  <role-name>RoleB</role-name>
 </security-role>
</application>

ibm-application-bnd.xmi


<?xml version="1.0" encoding="UTF-8"?>
<applicationbnd:ApplicationBinding xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:applicationbnd="applicationbnd.xmi" xmi:id="ApplicationBinding_1247569173614">
<authorizationTable xmi:id="AuthorizationTable_1247569173615">
<authorizations xmi:id="RoleAssignment_1249995536059">
<users xmi:id="User_1249995536059" name="corey"/>
<role href="META-INF/application.xml#SecurityRole_1247569173615"/>
</authorizations>
<authorizations xmi:id="RoleAssignment_1249995536136">
<users xmi:id="User_1249995536136" name="bob"/>
<role href="META-INF/application.xml#SecurityRole_1247569173624"/>
</authorizations>
</authorizationTable>
<application href="META-INF/application.xml#Application_ID"/>
</applicationbnd:ApplicationBinding>

EJB1Test
The EJB1Test project is the most complicated of all the projects. This isn't because of the Java code but instead because the project needs to support being run against WAS 6.0.2.35 and WAS 7.0.0.0. What this means is different support files:

classpaths for each environment.
SSL properties for each WAS profile.
eclipse runtime profiles - was.6.0.SessionBean1Test.profile; was.7.0.SessionBean1Test.profile. A lot of the complexity is hidden in the eclipse runtime profiles (that are detailed below).
client JRE's - WAS 6 required the IBM JRE shipped with WAS; WAS 7 was accessible through SUN's jdk1.6.0_12.

Support files were sourced from the following folders:

*.jar files from .../lib; .../runtimes/
*.jks from .../profiles/AppSrv01/etc/
*.conf; *.props from .../profiles/AppSrv01/properties/

The outline of the EJB1Test project might explain things a little better:

The junit class looked like this:

package jsears;

import java.math.BigDecimal;
import java.util.Hashtable;

import javax.naming.Context;
import javax.naming.InitialContext;
import javax.rmi.PortableRemoteObject;
import javax.security.auth.Subject;
import javax.security.auth.login.LoginContext;

import com.ibm.websphere.security.auth.WSSubject;
import com.ibm.websphere.security.auth.callback.WSCallbackHandlerImpl;

import jsears.SessionBean1;
import jsears.SessionBean1Home;
import junit.framework.TestCase;

public class SessionBean1Test extends TestCase {
 public void testSessionBean1() {
  try {   
   Hashtable env = new Hashtable();
   env.put(Context.INITIAL_CONTEXT_FACTORY, System.getProperty("java.naming.factory.initial"));
   env.put(Context.PROVIDER_URL, System.getProperty("java.naming.provider.url"));
   final Context initialContext = new InitialContext(env);
   initialContext.lookup("");

   LoginContext lc = new LoginContext("WSLogin", new WSCallbackHandlerImpl("bob", "bob1"));
   lc.login();

   final Subject subject = lc.getSubject();
   System.out.println("subject=" + subject.toString());

   WSSubject.doAs(lc.getSubject(),
     new java.security.PrivilegedAction() {
    public Object run() {

     try {
      Object objref = initialContext
      .lookup("ejb/jsears/SessionBean1Home");

      SessionBean1Home home = (SessionBean1Home) PortableRemoteObject
      .narrow(objref, SessionBean1Home.class);

      SessionBean1 currencyConverter = home.create();

      BigDecimal param = new BigDecimal("100.00");
      BigDecimal amount = currencyConverter.dollarToYen(param);
      System.out.println(amount);

      amount = currencyConverter.yenToEuro(param);
      System.out.println(amount);

     } catch (Exception e) {
      e.printStackTrace();
      fail(e.getClass() + ":" + e.getMessage());
     }

     return null;
    }
   });

  } catch (Exception e) {
   e.printStackTrace();
   fail(e.getClass() + ":" + e.getMessage());
  }
 }
}

The WAS 6.0.2.35 eclipse runtime profile looks like this:

NOTE: the BOOTSTRAP_ADDRESS port - specified as part of the eclipse runtime profile might differ for your WAS profile.

was.6.0.SessionBean1Test.launch

-Djava.naming.provider.url=iiop://127.0.0.1:2810
-Djava.naming.factory.initial=com.ibm.websphere.naming.WsnInitialContextFactory
-Djava.security.auth.login.config=file:conf.was.6/wsjaas_client.conf
-Dcom.ibm.CORBA.ORBInit=com.ibm.ws.sib.client.ORB
-Dcom.ibm.CORBA.ConfigURL=file:conf.was.6/sas.client.props
-Djavax.net.ssl.trustStore=conf.was.6/etc/DummyClientKeyFile.jks
-Djavax.net.ssl.keyStore=conf.was.6/etc/DummyClientTrustFile.jks

The WAS 7.0.0.0 eclipse runtime profile looks like this:

was.7.0.SessionBean1Test.launch

-Djava.naming.provider.url=iiop://127.0.0.1:2816
-Djava.naming.factory.initial=com.ibm.websphere.naming.WsnInitialContextFactory
-Djava.security.auth.login.config=file:conf.was.7/wsjaas_client.conf
-Dcom.ibm.SSL.ConfigURL=file:conf.was.7/sun.ssl.client.props
-Dcom.ibm.CORBA.ORBInit=com.ibm.ws.sib.client.ORB
-Dcom.ibm.CORBA.ConfigURL=file:conf.was.7/sas.client.props

sun.ssl.client.props


...
user.root=/home/jsears/local/tmp3/EJB1Test/conf.was.7
...
# KeyStore information
com.ibm.ssl.keyStoreName=ClientDefaultKeyStore
com.ibm.ssl.keyStore=${user.root}/etc/DummyClientKeyFile.jks
com.ibm.ssl.keyStorePassword={xor}CDo9Hgw=
com.ibm.ssl.keyStoreType=JKS
com.ibm.ssl.keyStoreProvider=SUN
com.ibm.ssl.keyStoreFileBased=true

# TrustStore information
com.ibm.ssl.trustStoreName=ClientDefaultTrustStore
com.ibm.ssl.trustStore=${user.root}/etc/DummyClientTrustFile.jks
com.ibm.ssl.trustStorePassword={xor}CDo9Hgw=
com.ibm.ssl.trustStoreType=JKS
com.ibm.ssl.trustStoreProvider=SUN
com.ibm.ssl.trustStoreFileBased=true
com.ibm.ssl.trustStoreReadOnly=false
...

Running it from RAD 6.0.1 + WAS 6.0.2.35
The examples in the previous section were all generated in RAD 6.0.1 and featured WAS 6.0.2.35.

This is the output from running the testSessionBean1 method:

What's far more interesting is what you see from the declarative security methods called in the dollarToYen method inside the SessionBean1Bean. Basically the code demonstrates if the user, specified in the testSessionBean1 method is in a particular role.

This is what you see when you use bob/bob1 as the login credentials:

And this is what you see when you use corey/corey1 as the login credentials:

Effectively, these screens prove that declarative and programmatic security are working.

Running it from RAD 7.5.3 + WAS 7.0.0.0 ND
In order to use the projects inside RAD 7.5.3 and against WAS 7.0.0.0 ND I first had to set up with custom security - via the Security > Global security >

Next I had to import the four projects into the IDE, RAD required that they were "migrated" - I did not change any files manually:

With WAS 7 I simply published the project to the server and called the junit test case - via the appropriate eclipse runtime debug configuration (the one with com.ibm.ws.ejb.thinclient_7.0.0.jar in it). The result of running the junit test case was the same as before (except the was.7.0.SessionBean1Test.launch generates no stderr):

Finally, changing the LoginContext to use an unrecognised password results in WSLoginFailedException:

LoginContext lc = new LoginContext("WSLogin", new WSCallbackHandlerImpl("corey", "corey2"))

Configuring embedded JMS in Websphere Application Server

2009-06-23T10:25:00.000-07:00

In WebSphere ND 7.0 (though this applies in a near identical way for previous v6.0+ versions) I did the following:

Create a new Service Integration Bus, called "B1":

Service Integration > New >

Assign "B1" to the Server, accepting all the defaults:

Service Integration > Buses > B1 > Bus members

On "B1" create a destination, "Q1", accepting all defaults:

Service Integration > Buses > B1 > Destinations > New > Queue

Give "Q1" a JMS provider, with the following (elsewhere use defaults):

Name = JMS_Q1
JNDI name = jms/JMS_Q1
Bus name = B1
Queue name = Q1
Del;ivery mode = Persistent

Resources > JMS > JMS Providers > Default messaging provider @ Server level > New

Create a JMS Connection Factory, with the following (elsewhere use defaults):

Name = JMS_CF1
JNDI name = jms/JMS_CF1
Bus name = B1

Resources > JMS > Connection factories > Default messaging provider @ Server level > New

Create a JMS Queue Connection Factory, with the following (elsewhere use defaults):

Name = JMS_QCF1
JNDI name = jms/JMS_QCF1
Bus name = B1

Resources > JMS > Queue connection factories > Default messaging provider @ Server level > Queues

Restart WAS!
Send a message with the Universal Test Client:

Queue JNDI Name = jms/JMS_Q1
Queue CF JNDI Name = jms/JMS_QCF1
Message = hello world

Check message is in Q1; here I used WAS's own console (for alternaitves see my post Useful WebSphere JMS Utilities):

Useful WebSphere JMS JNDI Utilities

2009-06-23T06:40:00.000-07:00

The following tools allow you to invoke WAS's embedded JMS server.

NOTE: These tools were tested against WAS 6. In particular, the instance they pointed at was the one that ships with RAD 6 - e.g. .../IBM/RAD-6.0/runtimes/base_v6

The first couple use WAS's own JVM, but execute outside of any container, and require a SWT distro (I used swt-3.4-gtk-linux-x86):

IBM Client Application For JMS

Service Integration Bus Explorer

The Universal Test Client application (IBMUTC.ear) is a bit different as it runs inside the web container of WAS:

Finally, there is HermesJMS - which, perhaps thankfully, can run on a "standard" JVM (e.g. a non IBM JVM) but is still able to connect to the embedded WAS JMS server! Unfortunately it does not run "out of the box" - some configuration is required:

after you have installed HermesJMS (java -jar hermes-installer-1.13.jar) the last line in bin/hermes.sh needs to be force fed the correct ORB implementation - e.g. add -Dcom.ibm.CORBA.ORBInit=com.ibm.ws.sib.client.ORB
next you need some SIB client jar's (IBM Client for JMS on J2SE with IBM WebSphere Application Server) so that you can configure a ClasspathGroups entry in HermesJMS and point it at the correct connection factory (via the BOOTSTRAP_ADDRESS port)
NOTE: you will need to have a SIB defined in WAS with the requisite connection factories and destination(s) - e.g. jms/CF in the example below.

Useful Web Sites / RSS feeds

2009-06-23T03:25:00.000-07:00

These are useful to me:

IBM : Rational Software - New courses - http://www-304.ibm.com/jct03001c/services/learning/ites.wss/us/en?pageType=rss_feed&subChapter=374&subChapterInd=C&subChapterName=Rational+Software&chapter=374&chapterName=Rational+Software&courseIndicator=N

JavaRanch: "Websphere" - http://www.coderanch.com/forums/rss/forumTopics/46/Websphere

IBM Redbooks | Rational - http://www.redbooks.ibm.com/rss/rational.xml

IBM Redbooks | WebSphere - http://www.redbooks.ibm.com/rss/websphere.xml

DeveloperWorks Tools (RAD, RSA, RDA, RSM, RWD) - http://www.ibm.com/developerworks/forums/rss/rssmessages.jspa?forumID=430

DeveloperWorks WAS - http://www.ibm.com/developerworks/forums/rss/rssmessages.jspa?forumID=266

WebSphere Community Blog - http://webspherecommunity.blogspot.com/feeds/posts/default

Installing RAD 6.0.1.2 & WAS 6.0.2.33 onto Ubuntu 9.04 Desktop

2009-06-23T01:36:00.000-07:00

This post explains how I installed RAD 6.0.1.2 and WebSphere Application Server 6.0.2.33 onto Ubuntu 9.04.

Firstly, its worth remembering the it is possible for RAD 6.0 & RAD 75 to co-exist on the same PC. The difference is that RAD 6 is run from the command line as neither its installer nor updater integrates into Ubuntu's menu's:

I installed RAD 6 after I installed RAD 75 - so its likely that you might have to do the following if you were to just install RAD 6:

sudo unlink /bin/sh
sudo ln -s /bin/bash /bin/sh

I downloaded the core files from http://ibm.com/partnerworld/ - using credentials; the patches are publicly accessible from ibm.com.

IBM has a useful support page the lists the mandatory and optional files - Files that must be downloaded to install Rational Application Developer from electronic image - but what is not so obvious is the order the patches need to be installed.

I've listed all the files I used for my install, their size, and also the order I installed them in:

-rwxrwxr-x 1 jsears jsears 55531442 2009-04-02 07:59 Linux.0-C81CXML.bin - Extractor
-rw-rw-r-- 1 jsears jsears 1500947095 2009-04-02 08:04 Linux.2-C81CYML.bin - Core
-rw-rw-r-- 1 jsears jsears 388285200 2009-04-02 08:10 Linux.3-C81CZML.bin - WAS6
-rw-rw-r-- 1 jsears jsears 313340148 2009-04-08 13:16 Linux.7-C81D2ML.bin - Agent controller

I also downloaded the matching Windows files as well ;-)

-rw-rw-r-- 1 jsears jsears 28991847 2009-04-02 08:04 Win.0-C81CIML.exe - Extractor
-rw-rw-r-- 1 jsears jsears 1465089897 2009-04-02 08:08 Win.2-C81CJML.bin - Core
-rw-rw-r-- 1 jsears jsears 384736660 2009-04-02 08:11 Win.3-C81CKML.bin - WAS6
-rw-rw-r-- 1 jsears jsears 313340148 2009-04-08 13:14 Win.7-C81CPML.bin - Agent Controller

What is important is that for the core files you must rename them to their original names - e.g. "Linux.2-C81CYML.bin - Core" would become "C81CYML.bin". This is so that the extractor / installer can find them in the same folder as the extractor.

The patches (common to both Windows and Linux installs) were applied in the following order:

-rw-rw-r-- 1 jsears jsears 953031 2009-04-02 11:51 1-rpu_602.zip
-rw-rw-r-- 1 jsears jsears 1675778833 2009-04-02 18:21 2-rad60_6011.zip
-rw-rw-r-- 1 jsears jsears 1095904839 2009-04-02 14:56 3-radpre60_6012.zip
-rw-rw-r-- 1 jsears jsears 296336679 2009-04-02 10:57 4-rad60_6012.zip
-rw-rw-r-- 1 jsears jsears 85941358 2009-04-02 12:02 5-rad6012_JRE_Update.zip
-rw-rw-r-- 1 jsears jsears 288694625 2009-04-02 12:26 6-rad6012_interim_fix001.zip
-rw-rw-r-- 1 jsears jsears 129895083 2009-04-02 12:09 7-rad6012_interim_fix002.zip
-rw-rw-r-- 1 jsears jsears 1299626269 2009-04-03 13:20 8-rad60_WAS6025.zip
-rw-rw-r-- 1 jsears jsears 233480881 2009-04-03 11:52 9-rad60_WAS6025_SDK_update.zip
-rw-rw-r-- 1 jsears jsears 271152159 2009-04-22 14:24 6.0.2-WS-WAS-LinuxX32-FP00000033.pak
-rw-rw-r-- 1 jsears jsears 271300738 2009-04-22 14:24 6.0.2-WS-WAS-WinX32-FP00000033.pak

I installed the *.pak files with the "IBM Support Assistant 4.0.2 Workbench" tool:

-rw-rw-r-- 1 jsears jsears 143320204 2009-04-02 12:32 ibmsa-v402-wb-linux.zip
-rw-rw-r-- 1 jsears jsears 126165772 2009-04-02 12:29 ibmsa-v402-wb-win32.zip

The patches get applied via the IDE: Help > Software Updates > IBM Rational Product Updater menu. With the above patches you should end up with it looking like this:

And when you've applied the *.pak files then, when running from within the IDE, you should end up with this:

As a side note, I also installed a Tomcat 5.0.30 instance into my IDE - I took this from http://archive.apache.org/dist/tomcat/tomcat-5/v5.0.30/bin/. The install is simply an extract of the .zip file and integration into the IDE via the Window > Preferences > Server > Installed Runtimes menu.

Useful Redbooks

2009-06-23T01:04:00.000-07:00

I have found the following IBM Redbooks useful when it comes to training for "Test 256: Application Development with IBM Rational Application Developer for WebSphere Software V6.0" and "Test 257: Enterprise Application Development with IBM Rational Application Developer for WebSphere Software V6.0":

The following Redbooks might be useful as well:

WebSphere Application Server V6 System Management and Configuration Handbook
WebSphere Application Server V6: Default Messaging Provider Problem Determination
WebSphere Application Server V6 Scalability and Performance Handbook
WebSphere Application Server V6.1: JMS Problem Determination
Experience J2EE! Using WebSphere Application Server V6.1
Experience Java EE! Using WebSphere Application Server Community Edition 2.1

Installing RAD 75, RAD 751 & WAS 7 onto Ubuntu 9.04 Desktop

2009-06-18T06:51:00.000-07:00

RAD V7.5 + WAS V7.0 (Network Deployment) was downloaded from http://ibm.com/partnerworld/ using credentials.

Update V7.5.1 downloaded from standard IBM site - e.g. did not require /partnerworld/ credentials.

NOTE: V7.5.4 can be downloaded from:

Rational Application Developer for WebSphere Software, Version 7.5.4

Ubuntu 9.04 (standard build) needs to have libstdc++.so.5 installed, to support the IBM Installation Manager, meaning: sudo apt-get install libstdc++5

Install directory layout looked like this:

PEK <- license key
RAD <- RAD75_1.zip ... RAD75_6.zip extracted in that order
RAD_SETUP <- sudo launchpad.sh
751/RAD <- rad751_1.zip ... rad751_3 extracted in that order; patch applied using IBM Installation Manager (see below).
WAS7 <- aka C1G32ML, sudo launchpad.sh

Install defaults were accepted throughout (unless mentioned).

sudo RAD_SETUP/launchpad.sh

Once installed then modify Applications > IBM Instillation Manager menu with gksudo:

Launcher permission

Update to 751 via Ibm Instillation Manager > File > Preferences > Add repository .../751/RAD/disk1 then Update > Next > etc...

Updating to 7.5.1 (using the local repository)

NOTE: 7.5.2 iFix001 can be downloaded via:
http://download.boulder.ibm.com/ibmdl/pub/software/rationalsdp/v75/rad/updates/

Prepare for WAS7 install, else installer gets stuck!

sudo unlink /bin/sh
sudo ln -s /bin/bash /bin/sh

Next, install WAS7 - using WAS7/sudo lauchpad.sh - disregarding the unsupported operating system warning!

Unsupported OS warning

I installed an Application Server:

Network Deployment version of WAS

Verify the install with First steps:

First steps confirmation

Make sure RAD / my uid can invoke the profile: sudo chown -R jsears:jsears /opt/IBM/WebSphere/AppServer/

Now hook the server into RAD the usual way...

Add /opt/IBM/WebSphere/AppServer into the Server Runtime Environments dialog:

Create a New Server (accepting all the defaults):

Start the server:

And, finally, connect to the server - http://127.0.0.1:9060/ibm/console/unsecureLogon.jsp