Some Java, JEE and WebSphere stuffs | Something about JEE and WebSphere. Java, JEE and WebSphere tips and tutorials

One of our project was developed and supported by an external vendor and due to some reasons (of course not known to me) our company decided to do all the future enhancements and support by our self. The project uses WebSphere Process Server as the middle ware and WebSphere portal server as the front end. All the communications between the portal and process server was using web service export. During the knowledge transfer session I noticed that for setting the endpoint url for different environments in their proxy client, they were editing the ServieLocator class. So I just want to post a small note on how to set the endpoint URL without changing the generated proxy classes.

To change the endpoint url for a web service we have a setEndpoint method in our proxy class. By default I guess the endpoint url will be pointing to localhost. By passing the new endpoint url to the setEndpoint method we can change it to a new host. For eg: in our hello world web service client, to change the end point url, change the code as shown below.

	HelloWorldProxy proxy = new HelloWorldProxy();
	proxy.setEndpoint(endPointurl);

That’s it. We are done with changing the endpoint url. We can store this endpoint url as part of our properties file and read it from there. This will ensure that, we get different endpoint urls for different environments

Receive choice activity or pick activity in WebSphere Process Server

A receive choice activity or pick activity is used for receiving different messages (or operations). This activity is extremely useful if you have an interface with more than one operation and you want this interface as the Interface partner for a business process. If you pass an interface with more than one operation to a normal receive activity it would throw you an error message saying “The process does not implement the operation ‘xxx’ of the port type ‘xxx’”. In this case the only option for us to use the interface is to use receive choice activity. To use a receive activity, follow the below steps.

1. Delete the existing receive activity
2. Drag and drop receive choice activity to your business process. A receive choice activity will be created with one choice in it.

3. Add a new receive by right click on receive choice activity and select ‘Add Receive’.

4. Select the first receive and go to Details tab in your properties window. Select your interface partner, operation and the input parameters. (Change the display name of receive if you want.).

5. Add a reply activity.

6. Repeat these steps for all the operation you have in your interface.

In my case I had two operations in my interface and after configuring receive choice activity my business process look like the one shown below.

If you are getting an error message saying, “The process is not startable. No receive choice or receive activity was found that creates a new process instance and does not have incoming links or preceding basic activities.”, make sure that you have checked the “Create a new process instance if one does not already exist” checkbox in the details tab of Receive choice properties window.

javax.net.ssl.SSLHandshakeException: certificate expired

javax.net.ssl.SSLHandshakeException: certificate expired. We get this exception when we try to invoke a web service from WebSphere Application Server 5.1. (In fact you will get this exception if your java version is 1.4.2_02 and earlier.) The complete stack trace of the exception is

WebServicesFault
 faultCode: Server.generalException
 faultString: javax.net.ssl.SSLHandshakeException: certificate expired
 faultActor: null
 faultDetail:
 
javax.net.ssl.SSLHandshakeException: certificate expired
        at com.ibm.ws.webservices.engine.WebServicesFault.makeFault(WebServicesFault.java:158)
        at com.ibm.ws.webservices.engine.transport.http.HTTP11Sender.invoke(HTTP11Sender.java:330)
        at com.ibm.ws.webservices.engine.transport.http.HTTPSender.invoke(HTTPSender.java:87)
        at com.ibm.ws.webservices.engine.PivotHandlerWrapper.invoke(PivotHandlerWrapper.java:212)

We get this exception because our trust store contains an expired Class 2 and Class 3 certificates. The Class 3 root certificate is used for authenticating web sites, signed code, SSL, OFX, and Administrator certificates. Class 2 root certificates are used for authenticating users and individuals.

The solution to this problem is to update the Class 2 and Class 3 certificates in our trust store. To do this either download the latest certificates from http://www.verisign.com/support/roots.html or extract the Class 2 and Class 3 certificates from a newer version of Java.

To import the latest certificates follow the below steps. The default password for sun cacerts is changeit

1. Delete the existing certificates by issing the following commands.
%JAVA_HOME%/bin/keytool -delete -alias verisignclass2ca -keystore %JAVA_HOME%/jre/lib/security/cacerts
%JAVA_HOME%/bin/keytool -delete -alias verisignclass3ca -keystore %JAVA_HOME%/jre/lib/security/cacerts

2. Import the new certificates by issuing the following command
%JAVA_HOME%/bin/keytool -import -v -keystore %JAVA_HOME%/jre/lib/security/cacerts -alias verisignclass2ca -file /home/Albin/certs/verisignclass2ca.arm

%JAVA_HOME%/bin/keytool -import -v -keystore %JAVA_HOME%/jre/lib/security/cacerts -alias verisignclass3ca -file /home/Albin/certs/verisignclass3ca.arm

Here verisignclass2ca.arm and verisignclass3ca.arm are the two new Class 2 and Class 3 certificates we imported. The above commands assume that your trust store is pointing to %JAVA_HOME%/jre/lib/security/cacerts, if it points to a different file, change the location.

For those who are facing difficulties in extracting the new certificates, download it from here. verisignclass2ca and verisignclass3ca. This is the certificates I have used when I encountered this issue.

Configuring a web service client for basic authentication

How do we pass the username and password to a web service which is protected by basic authentication? The generated proxy client has no methods for setting the username and password.

The solution is to set the username and password inside the generated proxy client. To do this edits your proxy java file and set the username and password properties. The properties are javax.xml.rpc.Stub.USERNAME_PROPERTY and javax.xml.rpc.Stub.PASSWORD_PROPERTY. I did it inside my _initXXX method of proxy client. For eg: my code looked like the following

if (test_Request != null) {
	((javax.xml.rpc.Stub)test_Request)._setProperty(Stub.USERNAME_PROPERTY, "username");	
	((javax.xml.rpc.Stub)test_Request)._setProperty(Stub.PASSWORD_PROPERTY,"password");	
}

If you set any other property name you will get an exception

Exception in thread "main" javax.xml.rpc.JAXRPCException: WSWS3212E: Error: Property name javax.xml.rpc.Stub.XXX not supported.
	at com.ibm.ws.webservices.engine.client.Stub._setProperty(Stub.java:541)

CNTR0031W: Error starting CMP bean wcfull#WebSphereCommerceServerExtensionsData.jar#XXXX: 
 javax.naming.NameNotFoundException: Context: localhost/nodes/localhost/servers/server1, name: jdbc/Default: First component in name Default not found.  Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0
	at com.ibm.ws.naming.ipcos.WsnOptimizedNamingImpl.do_resolve_complete_info(WsnOptimizedNamingImpl.java:968)
	at com.ibm.ws.naming.cosbase.WsnOptimizedNamingImplBase.resolve_complete_info(WsnOptimizedNamingImplBase.java:1431)
	at com.ibm.WsnOptimizedNaming._NamingContextStub.resolve_complete_info(Unknown Source)
	at com.ibm.ws.naming.jndicos.CNContextImpl.cosResolve(CNContextImpl.java:3493)
	at com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1521)
	..............................
 
JDBCPersister W CNTR0032W: Error creating CMP persister using datasource: jdbc/Default
BeanMetaData  E CNTR0035E: EJB container caught com.ibm.ejs.container.ContainerException: ; nested exception is: 
	com.ibm.websphere.cpi.CPIException: Persister creation failed.The bean's J2EEName is wcfull#WebSphereCommerceServerExtensionsData.jar#XXXX. The data source name is jdbc/Default.; nested exception is: 
	javax.naming.NameNotFoundException: Context: localhost/nodes/localhost/servers/server1, name: jdbc/Default: First component in name Default not found. [Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]
	at com.ibm.ejs.container.BeanMetaData.completeInitialization(BeanMetaData.java:1299)
	at com.ibm.ws.runtime.component.EJBContainerImpl.createBeanMetaData(EJBContainerImpl.java:1039)
	at com.ibm.ws.runtime.component.EJBContainerImpl.createModuleMetaData(EJBContainerImpl.java:830)
	at com.ibm.ws.runtime.component.EJBContainerImpl.createMetaData(EJBContainerImpl.java:1575)
	at com.ibm.ws.runtime.component.MetaDataMgrImpl.createFactoryMetaData(MetaDataMgrImpl.java:115)
	......................

This was the exception I got when I tried to start my WebSphere Commerce Full Test environment after creating a new EJB. Even though the solution was very simple, for me it took some time to figure it out what exactly went wrong. If any of you facing the same problem, then here is the fix.

Open your ibm-ejb-jar-bnd.xmi file. Search for jdbc/Default. Here jdbc/Default is the name of the data source that was not found by the server. You will be able to see an entry like

	<defaultDatasource xmi:id="ResourceRefBinding_1242722240919" jndiName="jdbc/Default"/>

Just to remove the above line and your server will again start properly.