Hi Blaise,

If you deploy the persistence jar under java/application/lib, all the classes will be loaded but not the .xml files. The class loaders used by Audium Call Services currently only load Java classes, however if you put the xml file under data/misc/, you can access it through a method call to getApplicationDirectory() (this method returns the application directory, your xml file can be found in its subdirectory data/misc.) on ComponentAPI class. ComponentAPI is an API class in the package of com.audium.server.session.

For details on how class loaders are structured in Audium Call Services, please refer to an article from Audium Knowledge Base at: http://kb.audiumcentral.com/questions/85/q.

Thanks,

John.

Hello Blaise,

The previously mentioned Audium Knowledge Base article lists various class loaders used by Call Services. Briefly, the possible scenarios are:

â¿¢ If the XML resources are deployed to the Application Serverâ¿¿s lib folder and the class loader for the Application Server is obtained, then the classes and XML resources in the Application Serverâ¿¿s directories are visible to that class loader.
â¿¢ However, if the XML resources are deployed to the global lib folder in the AUDIUM_HOME location, then only the class loader for Call Services will locate the XML resources.
â¿¢ Furthermore, if the XML resources are deployed to the applicationâ¿¿s local path, they will be loaded by the applicationâ¿¿s specific class loader.

Other users have had a similar issue where the XML resources were not visible to the application, and in those cases we recommended that they obtain the desired corresponding class loader by executing this method:

ClassLoader loader = getClass().getClassLoader();

May we ask how you are obtaining the class loader that you are using to access the persistence resources?

Regards,
Tam

Hi Blaise,

You mentioned,
[quote:5b0b5c65af]
In addition actions and decisions tend to come up in different classloaders, hence an api jar is required in the Callservices/common/lib directory to allow spring beans to be passed between the classloaders in the session.
[/quote:5b0b5c65af]

It seems that you deployed the custom JAR file to both the global lib in Call Services and the local lib in the applicationâ¿¿s folder. Is this so? If this is the case, then the Java classes in Call Services will take precedence and the ones in the applicationâ¿¿s folder will not be loaded by the JVM. This is the typical behavior of JVM. See in Chapter 2 in the Audium Programmer Guide. As the class loader for the custom JAR file is not the class loader for the application, the XML resources deployed to the local lib of the applicationâ¿¿s folder will not be visible.

Regards,
Tam

Hi,
his post is like history. But this the only thread we found using Spring framework for Java side of Call Studio. We have tried to implement our applications running over the spring. If anyone doing that kind of thing on their environment we will be pleased to hear from them. The details are described below:

We are trying to use Spring framework in our audium applications developed with Call Studio. The spring related jars are under \CVP\VXMLServer\Tomcat\webapps\CVP\WEB-INF\lib folder. The application specific jars (like jars by exporting our custom elements) are stored under cvp_application/deploy/java/application/lib folder. By the way, we are successfully running our spring application on our local machines as a Java project.

Here spring is using the tomcat's classloader which only looks for classes under \CVP\VXMLServer\Tomcat\webapps\CVP\WEB-INF\lib. With this configuration, our application specific jars are not visible to Spring. To make our application specific jars available to spring, we modified spring's classloader to look under cvp_application/deploy/java/application/lib also. But still we couldn't manage to run spring framework on backend. It does not throw ClassNotFoundErrors but can not successfully load our java beans either.