Ross,

On tomcat is running fine the apps for us too. but is not working on webSphere 8.5.

Any idea?


Regards,

Oh that is new information. You (or this thread) previously said "I have checked the same with a different IVR using Tomcat 6 + OD6SP1 and it seems the same thing happens."

Here is a question: Are the main application and the Module on the SAME application server?

The reason I ask is that the behavior you are experiencing indicates this. The other explanation is that the scertcommon-xx.xx.xx.jar is being loaded by different classloaders for the main and the module. Therefore, the module cannot see the session created by the main application. I do not use websphere much so, possibly there is a setting that results in the scertcommon being loaded by separate class loaders.

On other issue, I notice for OD 6.0 we don’t officially support WAS 8.5.

Another node, that main app and modules need to be deployed on the same server instance (sharing the same system classloader that loads scertcommon.jar).

We tested out your apps on 8.0 and it worked. 8.5 should be no different.

Ross,

Could you send us the log ?, when you ran the app in websphere.


Regards

oops wrong file.

:( yeah is working !!

Another question, when you deployed the app on webshere 8 , what option (On the class loader do you checked?).

Attachemend you find the image of our check options.

For modules to work, there is no need mess with the class loader. In our environment with single server instance, we deployment the runtimeSupport library files (including the scertcommon jar) in the appserver/lib/ext directory. These files are being loaded by the system classloader and shared by all the apps (main and modules).

That classloader option you check should be fine as longer as the scertcommon jar is not in the application's classloader, which means the file should not be in the app's lib directory.

We have a multicluster classloader, and that means that the runtimeSupport files are not on the global lib/ext, but on a shared library in a different directory, that is included as a shared library on all the modules we deploy. If this was the issue, would there be a way to write the current classpath of the app and the module, to check if it is OK? (A system property, Classloader.getSomething...?)

It should be absolutely fine to have a shared classloader as longer as it is shared by the main app and modules to share the same classes in scertcommon jar. That means something is not configured correctly. Usually, according to my experience, if you have a shared class loader, you should has each of the apps refer to the classloader in the configuration using ibm console.

We have the classloader in every app, if we didn't it wouldn't even validate, because it would have no scertcommon.

How can we check if the system really is using the same classloader?

You logs show that already. The way the app doesn't work - the module has separate logs, which it shouldn't be the case.
By default, each app/module has its own classloader but all the apps need to share another classloader which loads scertcomment.jar and other supporting libraries. You probably need some help from someone that is more familiar with Websphere there.