Thursday, 3 December 2009

WebSphere Portlet Factory 6.1.5 - My First Failure .... and success

Having recently installed WebSphere Portal Express 6.1.5, I went one step further on Wednesday and installed WebSphere Portlet Factory Designer 6.1.5 onto the same Red Hat Enterprise Linux VMware image.

Hmmmmm, things did not go quite as smoothly as I'd expected.

I downloaded/installed in this order: -

a) Sun JRE 1.6.0_17-bo4 - jre-6u17-linux-i586-rpm.bin - from here http://javadl.sun.com/webapps/download/AutoDL?BundleId=35674
b) Eclipse Galileo - eclipse-jee-galileo-SR1-linux-gtk.tar - from here http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/galileo/SR1/eclipse-jee-galileo-SR1-macosx-cocoa.tar.gz
c) WebSphere Portlet Factory Designer 6.1.5 - CZ7RYML.zip

In case it's relevant, I "merely" installed Eclipse by expanding the TAR file into /opt/eclipse.

So far so good.

Whilst creating a WPF project, I'm prompted to create a new Server Configuration for the deployment of the project to WebSphere Application Server / WebSphere Portal.

Since 6.1 was released, WPFD can connect to WAS via SOAP as well as the more traditional HTTP method. I think I'm right in saying that this allows for remote deployment of WARs ( where WPFD is on one machine and WAS/WP is on another ) so it's a good feature to have.

Having taken the defaults for the WAS/WP 6.1 configuration: -




















I clicked the "Test Connection" button ..... and saw .....









Check your Host and SOAP Connector port inputs. To verify your SOAP Connector port, go to the WebSphere Admin Console, select Application Servers > YOUR_SERVER > Ports and use the SOAP_CONNECTOR_ADDRESS

I followed the advice in the dialogue box and checked that the WebSphere_Portal instance of WAS was running, and the SOAP_CONNECTOR_ADDRESS was indeed 10033. I even proved it using the WSAdmin script as follows: -

/opt/IBM/WebSphere/PortalExpress/AppServer/bin/wsadmin.sh -port 10033 -user wpsadmin -password passw0rd -lang jython

By this time I was getting very desperate, and was using netstat -aon | grep 10033 to prove that the port was available, and even checked that the firewall - IPTables - was NOT running.

I then tried starting WPF in debug mode ( by running /opt/eclipse/eclipse -debug ) and then saw the following exceptions when I clicked the "Test Connection" button: -

INFO: ssl.disable.url.hostname.verification.CWPKI0027I com.ibm.websphere.management.exception.ConnectorException: ADMC0053E: The system cannot create a SOAP connector to connect to host localhost at port 10033 with SOAP connector security enabled.
Caused by: [SOAPException: faultCode=SOAP-ENV:Client; msg=Error opening socket: java.net.SocketException: java.lang.ClassNotFoundException: com.ibm.websphere.ssl.protocol.SSLSocketFactory; targetException=java.lang.IllegalArgumentException: Error opening socket: java.net.SocketException: java.lang.ClassNotFoundException: com.ibm.websphere.ssl.protocol.SSLSocketFactory]
com.bowstreet.designer.deploy.DeploymentException: An error occured trying to create the admin client. Check your Server Configuration inputs, and make sure your server is running.

At this point, I decided to call in the heavy mob - thanks to two of the smart people in the US, Jonathan B and Kevin T, I was able to crack it.

The ClassNotFound exception against com.ibm.websphere.ssl.protocol.SSLSocketFactory helped indicate the problem - Kevin advised me to check that the class did exist in the right place: -

/opt/IBM/WebSphere/PortletFactory/Designer/eclipse/plugins/com.bowstreet.designer.JMXConnection_6.1.5/WAS6.1/com.ibm.ws.security.crypto_6.1.0.jar

and then suggested that the problem MIGHT be a JRE issue; apparently the com.ibm.websphere.ssl.protocol.SSLSocketFactory class has a dependancy on the IBM Java Runtime Environment.

I proved this by changing my environment to use the IBM JRE that's packaged with WebSphere Application Server instead of the Sun JRE, by use of the setupCmdLine.sh, as follows: -

Before changing the environment

$ java -version

java -version
java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Client VM (build 14.3-b01, mixed mode, sharing)

Change the environment

. /opt/IBM/WebSphere/PortalExpress/AppServer/profiles/wp_profile/bin/setupCmdLine.sh

( noting the leading DOT SPACE )

After changing the environment

$ java -version

java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build pxi32devifx-20090811 (SR10 +IZ56666+IZ56751))
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32 j9vmxi3223-20090707 (JIT enabled)
J9VM - 20090706_38445_lHdSMr
JIT - 20090623_1334_r8
GC - 200906_09)
JCL - 20090811


Having done this, I was able to restart Designer, and deploy my project using SOAP.

In short, if you see similar exceptions re SSLSocketFactory, check that you're not running the Sun JRE.


Comments:
Thanks for posting this! I had the same problem after I moved to 6.1.5 and Linux and was running PF with a Sun, excuse me, Oracle, VM.

Isn't IBM the greatest!

Another way to go if you don't want to mess with setting environments, is to set the vm in the launcher. To do this, create (or modify) a Portlet Factory launcher and after eclipse, put -vm /path/to/IBM/java/bin (has to be pointed to the bin directory of the JRE). The -vm parameter will work for Windows folks, too.

I've ended up on your blog for one thing or another the past few of months. Keep the info flowing!
 
Thanks for the kind comments - much appreciated. Will definitely check out the -vm parameter
 
hi dave

"then tried starting WPF in debug mode ( by running /opt/eclipse/eclipse -debug ) and then saw the following exceptions when I clicked the "Test Connection" button: -"

where did you see this? .metadata/.log?

peter
 
Peter, the message that clued me into the solution appeared in the terminal session from which I'd run the eclipse -debug command, Dave
 
Post a Comment





<< Home

This page is powered by Blogger. Isn't yours?

Subscribe to Posts [Atom]