![]() |
In general, the best way to access Java components is to use the Java language. Because of this, you are recommended to do as much programming as possible in Java and to use a small simple interface between your COM Automation container (for example, Visual Basic) and Java. This avoids any overhead and performance problems that can occur when moving across the interface between ActiveX and Java.
Visual Basic guidelines
The following guidelines are intended to help optimize use of the ActiveX to EJB bridge with Visual Basic:
If you want to run your Visual Basic application through the Visual Basic debugger, you must be running the Visual Basic IDE (Integrated Development Environment) within the ActiveX to EJB bridge environment. After your Visual Basic project is created, you can simply launch it from a command-line; for example, launchClientXJB MyAppliation.vbp. Alternatively, you can launch Visual Basic alone in the ActiveX to EJB environment by changing the Visual Basic shortcut on the Windows Start menu so that launchClientXJB.bat precedes the call to VB6.EXE.
Because the JVM attaches to the running process, you must exit out of the Visual Basic editor before debugging your program. If you run then exit your program within the Visual Basic IDE, the JVM continues to run and you reattach the same JVM when XJBInit() is called by the debugger. This causes problems if you are trying to update XJBInit() arguments (for example, classpath), because the changes are not be applied until you restart Visual Basic.
Because the JVM cannot be unloaded or reinitialized, you should cache the resulting XJB.JClassFactory object as a global variable. The overhead of treating it as a global variable or passing a single reference around is much less than recreating a new XJB.JClassFactory object and calling XJBInit() more than once.
CScript and Windows Scripting Host (WSH)
The following guidelines are intended to help optimize use of the ActiveX to EJB bridge with CScript and Windows Scripting Host (WSH):
To run VBScript files in .VBS files, you launch them in the ActiveX to EJB bridge environment. There are two common ways to launch your script:
Active Server Pages guidelines
The following guidelines are intended to help optimize use of the ActiveX to EJB bridge with Active Server Pages:
Because Active Server Pages typically uses VBScript, we have included some helper functions that you can use in any VBScript environment with minor changes. For more information about these helper functions, see Helper functions for data type conversion. To be able to run outside of the ASP environment, the only change you need to make is to remove or change all references to the Server, Request, Response, Application and Session objects; for example, change Server.CreateObject to CreateObject.
The XJB.JClassFactory must be able to find the Java runtime DLLs when initializing. In Internet Information Server you cannot specify a path for its processes independently; you must set the process paths in the system PATH variable. This means that you can only have a single JVM version available on a machine using ASP. Also, remember that after you change the System PATH variable you must reboot the Internet Information Server machine so that Internet Information Server can see the change.
If the system TEMP environment variable is not set, Internet Information Server stores all temporary files in the WINNT directory. This is usually not a desired behavior.
When using the ActiveX to Java bridge with Active Server Pages, you are recommended to create your Web application in its own process. This is because you can only load one JVM in a single process and if you want to have more than one application running with different JVM environment options (for example, different classpaths), then you need to have separate processes.
When debugging your application, use the Unload button when viewing your ASP Application properties in the Internet Information Server administration console to unload the process from memory (and thereby unload the JVM).
In your ASP environment, only use one ASP application per J2EE Application or JVM environment. If you need separate classpaths or JVM settings you need to have separate ASP Applications (Virtual Directories with High Isolation or Isolated Process).
Because of the one-to-one relationship required between a JVM and a process, and because the JVM can never be detached or shutdown from a process independently, you should cache the XJB.JClassFactory object at Application scope and call XJBInit() once only.
Because the ActiveX to EJB bridge employs a free-threaded marshaler, you should be able to take advantage of the multi-threaded nature of Internet Information Server and ASP. If you choose to reinitialize the XJB.JClassFactory object at Page scope (local variables), then the XJBInit() method can only initialize your local XJB.JClassFactory variable. Therefore, it is more efficient to do the XJBInit() once instead of many times.
Because VBScript only supports variant
data types, you must use the CStr(), CByte(), CBool(), CCur(), CInt(), Clng(),
CSng() and CDbl() functions to tell the activeX to EJB bridge what data type
you really mean to use; for example oMyObject.Foo(CDbl(1.234))
.
J2EE guidelines
The following guidelines are intended to help optimize use of the ActiveX to EJB bridge with J2EE:
Because you can only have one JVM per process, and a single J2EE client container (com.ibm.websphere.client.applicationclient.launchClient) per JVM, you should initialize your J2EE client container once only and to reuse it. For ASP, store the J2EE client container in an Application level variable and initialize it once only (either on the Application_OnStart() event in global.asa or by checking to see if it IsEmpty()).
A side effect to storing the client container object globally is that you are unable to change the client container parameters without destroying the object and creating a new one. These parameters include the EAR file, BootstrapHost, classpath, and so on. If you are running a Visual Basic application and wish to change the client container parameters, you must end the application and restart it. If you are running an Active Server Pages application, you must first unload the application from Internet Information Server (see "Use the Application Unload Button" under Active Server Pages guidelines). Then load the Active Server Pages application with the different client container parameters. The first time the Active Server Pages application is loaded, the parameters will be set. Since the client container is stored on the Internet Information Server, the parameters are shared by all browser clients using the Active Server Pages application. This is normal Active Server Pages behavior, but it may be confusing when you try to run to different WebSphere Application Servers using the same Active Server Pages application. You cannot do that.
By default, the client container is launched and extracts the application's EAR file to your temp directory and then sets up the thread's ClassLoader to use the extracted EAR file directory and JAR files included in the client Jar's manifest. This process is time consuming and because of some limitations with JVM Shutdown via JNI and file locking, these files are never cleaned up.
Specifically, each time the client container's launch() method is called, it extracts the EAR file to a random directory name in your temporary directory on your hard drive. The current Java thread's class Loader is then changed to point to this extracted directory which in turn locks the files within. In a normal J2EE Java client, these files will be automatically cleaned up after the application exits. This occurs when the client container's shutdown hook is called (which never happens in the ActiveX to EJB bridge) which leaves the temporary directory there.
To avoid these problems, you can specify a directory to extract the EAR file into by setting the com.ibm.websphere.client.applicationclient.archivedir Java system property before calling the client container's launch() method. If the directory does not exist or is empty, the EAR file is extracted like normal. If the EAR file was previously extracted, the directly is reused. This feature is particularly important for server processes (for example, ASP), which can stop and restart, potentially calling launchClient() several times.
If you need to update your EAR file, you must delete the temporary directory first. Then the next time the client container object is created, it extracts the new EAR file to the temporary directory. If you do not delete the temporary directory or change the system property value to point to a different temporary directory, the client container reuses the currently extracted EAR file, and your changed EAR file is not used.
If you choose not to use this system property, you need to regularly go to your Windows temp directory and delete the WSTMP* subdirectories. Over a relatively short period of time, these subdirectories can waste a very significant amount of space on the hard drive.