Created by: Mert Guray on 15-01-2009 12:29:33 PM Hi, We need help about a development issue which is very crucial for setting up our CVP application development platform and framework.
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.
Subject: Re: Spring framework for Call Studio Replied by: Elam Birnbaum on 16-01-2009 09:09:33 PM Hello,
I have several ideas on what can be done, though I am not 100% sure I understand what exactly is being done here. Overall, classloader issues can be tricky to debug. Typically the solution will involve putting JAR files in different places to see if that resolves the issue. Its an issue of classes from one library having access to other classes. This is basically how the classloaders work when using VXML Server and Tomcat:
JVM -> Tomcat -> web application (CVP) -> VXML Server common -> VXML Server application Java folder
The sequence above goes from higher level classloader to lower level classloader. Classes in a higher level classloader cannot see classes in lower level classloaders, but the opposite is true, a class in the lowest level can see any of the other classes loaded by the classloaders above it. It is for this reason that reusable libraries are typically put in the Tomcat's common/lib folder since any web application can then use them. It seems in this case the Spring library actually needs to load application-specific classes and it would not work if Spring was placed in a higher level classloader.
I have a few suggestions:
Put the application-specific JARs as high in the classpath as possible. This could be Tomcat common/lib. The problem with this is that if any of the classes in these JARs reference VXML Server API classes this will not work since those only exist in the web application.
Place the spring jar files in the application's java folder (i.e. cvp_application/deploy/java/application/lib) alongside the application's jars. Since they are on the same level they should be able to see eachother. Another advantage to this is that you don't have to worry about if you have multiple CVP applications that would then conflict with eachother attempting to get the same spring load their JARs. We actually have customers that deploy their applications this way because they are able to control the versions of the libraries they deploy for each application separately. So for example if they have 2 applications A and B, they would put the spring JAR in both applications and if an updated spring JAR was needed by application B but not A, they could put it in B alone, leaving A with exactly the same JAR file it was tested with and not risking the introduction of an incompatibility bug with a new version of Spring. The disadvantage of this configuration is that you would have multiple Spring JAR files, one for each CVP application and this will cause more memory to be used up by VXML Server when it loads all the applications. This extra memory usage is slight, though.
On a side note, as a best practice we strongly discourage placing custom JAR files in the CVP web application's WEB-INF/lib folder. While this may be helpful from a classloader standpoint, there are other issues that are introduced by this including those JAR files being wiped out by a CVP upgrade and the added maintenance required in order to ensure that each new CVP release that introduces a new web application is also updated with the new JARs. As an alternative, simply place these JARs in the Tomcat common/lib folder which will just put these libraries one level higher up in the classpath and achieve almost the same result.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:
