Please login or register to access secure site features.

Note: By continuing to use DevConnect Program Services you agree to our latest Registered Member Terms.

Sign in using DevConnect ID

Forgot password?

Trouble logging in?

Submit a ticket for Registration Support.

I have an SSO ID

?
sign in

Don't have a DevConnect or SSO ID ?

Create a DevConnect account or join the program.

register now
^
Forum Index » Avaya Orchestration Designer » Logging to an external database in modules   XML
 
Author Message
IvanFontalvo



Joined: 22/03/2012 08:51:43
Messages: 61
Offline

Ross,

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

Any idea?


Regards,
RossYakulis



Joined: 06/11/2013 08:46:50
Messages: 2652
Offline

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."
RossYakulis



Joined: 06/11/2013 08:46:50
Messages: 2652
Offline

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



Joined: 06/11/2013 08:46:50
Messages: 2652
Offline

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.
RossYakulis



Joined: 06/11/2013 08:46:50
Messages: 2652
Offline

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



Joined: 06/11/2013 08:46:50
Messages: 2652
Offline

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.
IvanFontalvo



Joined: 22/03/2012 08:51:43
Messages: 61
Offline

Ross,

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


Regards
RossYakulis



Joined: 06/11/2013 08:46:50
Messages: 2652
Offline

oops wrong file.
 Filename trace.log [Disk] Download
 Description No description given
 Filesize 23 Kbytes
 Downloaded:  442 time(s)

IvanFontalvo



Joined: 22/03/2012 08:51:43
Messages: 61
Offline

:( 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.
[Thumb - image.png]
 Filename image.png [Disk] Download
 Description No description given
 Filesize 20 Kbytes
 Downloaded:  569 time(s)

WilsonYu



Joined: 06/11/2013 14:29:24
Messages: 3858
Offline

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).
WilsonYu



Joined: 06/11/2013 14:29:24
Messages: 3858
Offline

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.
JuanMorales2



Joined: 16/12/2013 10:02:42
Messages: 44
Offline

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...?)
WilsonYu



Joined: 06/11/2013 14:29:24
Messages: 3858
Offline

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.
JuanMorales2



Joined: 16/12/2013 10:02:42
Messages: 44
Offline

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?
WilsonYu



Joined: 06/11/2013 14:29:24
Messages: 3858
Offline

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.
 
 
Go to: