Problem: While running an application that uses shared-memory communications, you get a ClassNotFoundException or a NoClassDefFoundError. The class is definitely in the classpath specified in the JNBridgePro configuration. The application works fine when configured to use tcp/binary communications.

This is typically an indication that one or more of the class or jar files in the classpath cannot be read. When a class or jar file cannot be read, the Java Runtime Environment (JRE) cannot see the class, and a ClassNotFoundException or NoClassDefFoundError will be thrown. To address the problem, make sure that the user running the program has "Read & Execute," "List Folder Contents," and "Read" permissions to folder containing the jar or class files. If you set these permissions by right-clicking on the folder, selecting "Properties," clicking on the "Security" tab, and then setting the permissions, the premissions will be inherited by the classes in the folder, including the jar and class files. Make sure that all members of the classpath, plus jnbcore.jar and bcel-5.1-jnbridge.jar all have the required permissions.

This problem will often be seen when creating ASP.NET Web applications that use shared-memory communications. When using tcp/binary communications, the Java side is typically started up in a separate window, and is running under the user's account, and the user who starts up the Java side is likely to have permissions to access the jar files. When the Web application is converted to shared-memory, however, the Java-side will run under the same account as the ASP.NET .NET side, typically the ASPNET account. It is therefore necessary to make sure that ASPNET has the proper access rights to the Java-side classes, as described above. After assigning these permissions, restart ASP.NET by running the command "iisreset" from a command-line window.