Determining the API of the target application

Section not yet written.

The Jacob DLL

Jacob.jar relies on a DLL file that it loads off of the library path or classpath. The code is written so that the jacob.dll is only loaded one time per classloader. This works fine in the standard application but can cause problems if jacob.jar is loaded from more than one class loader. This can happen in the situation where multiple jacob dependent web applications run in the same container like a web server or JWS runtime.

In the case of a web server, Jacob is normally put in the application specific WEB-INF/lib directory. This is the "right" way to do it and works in most situations. But, if Jacob is put in the WEB-INF/lib directory of each application's war file for more than one application then a problem occurs. In this situation, the web server uses a different classloader for each applicaiton. This means that each application will attempt to load the jacob.dll and errors are generated. The only way around this at this time (1.11) is to put the jacob.jar in the common/lib because that classloader is inherited by all of the applicaitons so the DLLs will only get loaded once. This problem is described in SF 1645463 and should be fixed in some future release, fix method and time not yet determined.

Microsoft Visual C++ library dependencies.

http://www.microsoft.com/downloads/details.aspx?familyid=32bc1bee-a3f9-4c13-9c99-220b62a191ee&displaylang=en
http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647&displaylang=en

Jacob Command Line Settings

java.library.path

Example: -Djava.library.path=d:/jacob/release/x86

com.jacob.autogc

There are real reasons for managing the lifetime of JacobObjects on a per thread basis. Jacob normally manages the the com/Java object lifetime as described in the JacobComLifetime.html document. Some users have run into situations where they wish to try and let the Java GC lifetime manage the lifetime of objects. This seems to usually be tied to long running threads or to objects created as part of event callbacks. Code was added to let users try and let the JVM manage the object life cycles even though the JacobComLifetime.html document says this is a bad idea.

This value is cached at startup and cannot be changed on-the-fly via System.setProperty();

The default value is false

Example: -Dcom.jacob.autogc=false

<class_name>.PutInROT

This option may cause VM crashes in certain situations where windows memory is freed outside of the thread it was created in but emperical evidence shows there are situations where this great reduces the long running memory footprint of applications that process a lot of events. This function is still experimental. The functionality of this overlaps the experimental com.jacob.autogc introduced in 1.9. See the ROT.java test program for an example of the effects of this option.

This value is checked every time and can be changed on-the-fly via System.setProperty();

Example: System.setProperty("com.jacob.com.VariantViaVariant.PutInROT","false");
Example: -Dcom.jacob.com.VariantViaVariant.PutInROT=false

com.jacob.debug

This value is cached at startup and cannot be changed on-the-fly via System.setProperty();

The default value is false

Example: -Dcom.jacob.debug=false

-XCheck:jni

The default is "no additional checking" Example: -XCheck:jni

Finding the DLL version using windows command line

Last Modified 2/2007