Hi guys,

We are working on an OD application deployed in WAS 8.5 and we are facing an issue we haven't experience before, and maybe you can help us shed some light as to what could be causing the problem.

We have two OD applications App1 and App2 built using OD 07.01.08.04 that are deployed on the same Websphere 8.5

App2 is a reusable module used by App1 as a subdialog that plays a few audios.
The problem we are facing is that all the session data seems to be lost when App2 is launched. Therefore, we can't access the ANI, DNIS, etc and any of the other values stored in the OD session because when we retrieve them, we only get an empty string.

This is the information of the environment:
Websphere 8.5
Java SDK 1.8
OD Runtime 07.01.08.04

And this is how we are trying to retrive the session variables:

	public void requestBegin(SCESession mySession) {

		super.requestBegin(mySession);

		

		try {				

			ICallData oCallData = new CallDataImpl();

			oCallData.setField(Field.ANI, mySession.getVariableField(IProjectVariables.SESSION, IProjectVariables.SESSION_FIELD_ANI).getStringValue());

			oCallData.setField(Field.DNIS, mySession.getVariableField(IProjectVariables.SESSION, IProjectVariables.SESSION_FIELD_DNIS).getStringValue());

                 ...

                 

		} catch (ServiceException e) {

			if(mySession.isDDTraceEnabled()){

				mySession.getTraceOutput().writeln(ITraceInfo.TRACE_LEVEL_ERROR, "# There was a service exception: " + e );

			}

		}

	}

	

We have followed the steps provided in the documentation for creating the shared libraries that is shared by both OD and also the OD Axis2 library that is assigned to Java.

I'm also attaching the trace of both applications.

Any help would be greatly appreciated.

Regards,
Cintia

From the way the logs look, the two apps are using two separate SCESession objects. They are supposed to share one. The obvious symptom is having 2 separate log files. When it works properly, there should be only one log file in the main app. The key question is where the scertcommon<version>.jar library file is deployed. The classes in this library file needs to be loaded in the same classloader to be accessible by both applications. Our recommended default is the lib/ext directory. However, this may not fit your deployment strategy. You can have a separate loader for it but the OD apps need to share the same classloader. If you don't quite understand this, you would need some help from IBM or an administrator that understand this more.

Hi Wilson,

We have the runtime deployed under a shared library that is configured for both applications.
And both applications are configured to use for "Single class loader for application" under "WAR class loader policy"

This is how it was configured when the customer had WAS 6 and DD 5, so we thought that maybe there is something else we might be missing.

There was no shared library requirement for WAS 6 and DD5. The problem we are trying to solve with the shared library is the Axis2 conflict. In our documentation, we do not include the scertcommon library in the shared library, only the Axis2 related files.

Right, the documentation states that we have to create a shared library only with the jar files related to Axis2 and associate it to the Class Loader listed under "Java and Process Management in Server Infrastructure section". (i.e ODAxis2Runtime)

We did that, and we also have another shared library called "RuntimeSL" that contains all the jar files provided by the runtime and it is configured as a shared library for each application we have in the WAS.
This shared library "RuntimeSL" has the scertcommon<version>.jar.

Then you have to make sure that RuntimeSL library classloader is shared by both applications. You may need help with that. I am not the expert of WAS administration.

We were able to fix the problem.

On WAS 8.5, the session variables only can be shared between applications under the same EAR file.
http://www.ibm.com/support/knowledgecenter/en/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/tprs_sharing_data.html

Therefore, when exporting the Main module, we left all the wars inside.
And then in the WAS, we configured the Application with the following options:

[Application] – General Properties Tab

Class loading and update detection

Make sure the following options are selected

• Classes loaded with local class loader first (parent last)

• Class loader for each WAR file in application

Shared libraries

Make sure to associate the shared library that contains the runtime to the EAR.

Also, make sure all the modules have the Shared Library with the runtime associated to them.

Manage Modules

Make sure each module (War file) is configured with the following option: “Classes loaded with parent class loader first”

That's definitely one way to do it. Thanks for sharing!

Wilson,
What would be another way to do it?

What I do is extract all the files from the runtime support package into the app server lib/ext directory and setup the shared library according to our documentation. We don't have to package all the application in one EAR because all the apps will share the scertcommon library in the lib/ext (which is a higher level classloader).