Originally posted by: SanderDN

We're having the following problem:                                    
                                                                       
We want to run cplex from the opl java interface without setting cplex on the PATH variable. The java webapplication is ran using a Tomcat server. In the tomcat service properties, the following parameters are added to the service startup parameters:                                
                                                                       
-Djava.library.path=C:\Program Files\IBM\ILOG\CPLEX_Studio1261\opl\bin\x64_win64\;C:\Program Files\IBM\ILOG\CPLEX_Studio1261\opl\oplide\;C:\Program Files\IBM\ILOG\CPLEX_Studio1261\cpoptimizer\bin\x64_win64\;C:\Program Files\IBM\ILOG\CPLEX_Studio1261\cplex\bin\x64_win64\

I also copied the correct oplall.jar to the tomcat lib folder. The error we're getting is the following:

                                                                       
Caused by: java.lang.RuntimeException: Native code library failed to    
load: ensure the appropriate library (opl1261.dll/.so) is in your path.
Exceptions:                                                            
C:\Program Files\IBM\ILOG\CPLEX_Studio1261\opl\bin\x64_win64\opl1261.  
dll: Can't find dependent libraries                                    
no opl_lang_wrap_cpp in java.library.path                              
no opl_core_wrap_cpp_java1261 in java.library.path                      
no opl_core_wrap_cpp in java.library.path                              
C:\Program                                                              
Files\IBM\ILOG\CPLEX_Studio1261\cpoptimizer\bin\x64_win64\cp_wrap_cpp_ja
va1261.dll: Can't find dependent libraries                              
no cp_wrap_cpp in java.library.path                                    
no concert_wrap_cpp_java1261 in java.library.path                      
no concert_wrap_cpp in java.library.path                                
It might also be related to missing Microsoft Visual C++                
Redistributable Package.                                                
at ilog.concert.IloJNILoader.loadJNI(IloJNILoader.java:85)            
at ilog.concert.cppimpl.concert_wrapJNI.<clinit>(concert_wrapJNI.java:
15)                                                                    
... 55 more                                                            
                                                                       
Some things we have tried:                                              
                                                                       
- we have validated that adding "C:\Program                            
Files\IBM\ILOG\CPLEX_Studio1261\opl\bin\x64_win64\;C:\Program          
Files\IBM\ILOG\CPLEX_Studio1261\opl\oplide\;C:\Program                  
Files\IBM\ILOG\CPLEX_Studio1261\cpoptimizer\bin\x64_win64\;C:\Program  
Files\IBM\ILOG\CPLEX_Studio1261\cplex\bin\x64_win64\" to the windows    
PATH variable makes it work. Yet this is the thing we don't want to do.
- installed the Microsoft Visual C++ Redistributable Package (tried    
2010 version, tried 2013 version), we also tried restarting the server,
no help        
- we have validated that it isn't a classpath issue        

- we have validated that cplex.jar isn't on the classpath                

                                                                       
                                                                       
To conclude: It seems like the dll's opl1261.dll and                    
cp_wrap_cpp_java1261.dll don't see the java -Djava.library.path        
variable, and try to search in the windows PATH variable for their      
dependencies.                                                          
                                                                       
Note: the reason we don't want to put cplex on the PATH is that we want
to run multiple cplex versions in parallel on the same server.

Originally posted by: Ph.Gregoire

Hello,

Unfortunately, this will not be possible.

The windows process which is executing the native code from the opl/cplex* DLLs can hold only one version of a given DLL, so your Tomcat process will be able to use only one version at a time.

The reason why the DLL loading does not work is that only one 'top/head' DLL is explicitly loaded by the OPL runtime (through Java/JNI bindings), say opl1261.dll, the other DLLs are referenced from that top/head one through DLL-level dependencies resolved by the windows OS.

java.library.path is used by Java to locate this DLL, but then the windows OS tries to resolve the dependencies using OS mechanisms which are based on PATH env variable.

Now, since the DLLs have mostly different names for each version, you could add all of the COS version to the PATH, and the correct top DLL would be picked up by version number, except for the db*.dll which are not named after the version.
You may even be able to load all of them simultaneously in the same process (with classloader isolation for the Java part), except for db*.dll which are not named after the version, and may be incompatible across versions.

A tool like depends on windows will show the dependencies.

Philippe

Originally posted by: SanderDN

Hi,

Thanks for your response. I haven't expressed myself 100% right in my last post.

When I said we want to run multiple cplex versions in parallel on the same server, I meant on the same physical server.

On this server there is a legacy Access application which uses Cplex 12.4. We want to run our tomcat server on the same physical server, but with a different Cplex version.

Do you think this is a possibility?

Originally posted by: Ph.Gregoire

Hello,

Yes, the usecase you describe is possible, since you can set the PATH individually for Tomcat so that it refers to the appropriate CPLEX bin\ directory.

In general, I tend to remove the application-specific PATHs from global environment in windows (because in support, I have about 7 or 8 different versions of the product installed), and set it on a per-use basis, either manually on the command line with a SET PATH=%PATH%;...., or through a cmd shell script before launching a specific application.
The only thing to mind is that this has to be done prior to launching the executable because system-level environment cannot be altered from within the process. For Tomcat, I assume there is a [set of] .bat files that launch the server, so you could alter the PATH from inside this .bat script. Somehow, java.library.path sysprop also has to be set, as Java does not pick it up from the environment (maybe because this is platform-dependent)

For our CES or ODME Optimization servers, this is how we proceed, we set the PATH (or LIBPATH on linux, or LD_LIBRARY_PATH on AIX) before launching the solve subprocess.

Regards,

Philippe Gregoire (ODM Enterprise/IDOC L3 support)