Details
P4 Description
Customer problem description:
------------------------------
I have a class that is packaged as a JavaBean-ActiveX component. This class references classes that are normally found via the CLASSPATH environment variable. When this class is instantiated by an ActiveX client, it is unable to reference the classes that are found via the CLASSPATH environment variable. I have been able to work around this problem by manually making the appropriate -classpath entry in the Java Run Time Parameters in the Java Plug-in Control Panel. While this is okay for my development activities, it will not be acceptable when this JavaBean-ActiveX component is deployed in a production environment with hundreds of work stations in offices around the world. Either the component must be able to reference classes via the CLASSPATH environment variable, or I must be able to set the Java Plug-in's Run Time Parameters automatically from a system management tool or installation program.
This problem did not occur until I started using Java 2 and JDK1.3.0_01/02. When I was using JDK 1.1.8, the component could find classes via the CLASSPATH environment variable.
I have attached a testcase which will illustrate this problem in detail:
INSTRUCTIONS:
1. Unzip this file in a working directory, preserving the
directory structure contained it this file.
2. Add the working directory to your CLASSPATH environment
variable.
3. Test your configuration by running class MyBean.MyBean
without any Java command line options:
java MyBean.MyBean
It should display the current java.class.path System Property,
followed by "end of test" on the next line.
4. Package and register class MyBean/MyBean as an ActiveX
component. You do need to do the packaging; the jar, tlb, and
reg files are already in subdirectory MyBean. You can just
modify MyBean.reg so that it refers to directories on your
machine instead of mine, then apply it to your registry. You
must replace all occurrences of three strings:
- d:\\Program Files\\JavaSoft\\JRE\\1.3.0_02\\bin
- E:\\Projects\\VUE\\JavaDev\\SunCall746249
- E:/Projects/VUE/JavaDev/SunCall746249
Replace the first with your jre bin directory's path, and the
second and third with the working directory's path.
Or, you can package and register class MyBean/MyBean yourself.
5. See the problem. Run the client application,
VBClient/Call746249.exe. It should show that the
java.class.path System Property is the current directory. Or,
in other words, it displays a dot (.).
If you click the "Invoke MyBean.direct" button, an information
message box is displayed indicating that method MyBean.direct
was invoked.
Now here's the problem. Click button "Invoke MyBean.indirect."
An error message box is displayed indicating that class
MyClass/MyClass could not be found. Step 3 above tested that
this class, which is on the class path defined by the CLASSPATH
environment variable, can be found when Java is run from the
command line. With JDK 1.1.8, this problem did not occur.
6. Here's my temporary workaround. In the Java Plug-in
Control Panel's Java Run Time Parameters, enter -classpath
followed by the working directory. Now, when you run the client
application the java.class.path System Property is shown as
the working directory, and clicking the "Invoke MyBean.indirect"
button shows an information message box indicating that method
MyBean.indirect was invoked. In other words, now, we can find
class MyClass/MyClass.
This wordaround is okay during my development activities, but is
not when the application is deployed to hundreds of workstations
in offices around the world. The ActiveX component should be
able to reference classes found along the class path defined by
the CLASSPATH environment variable, as it did when using
JDK 1.1.8.
FILE DESCRIPTIONS:
1. MyBean/MyBean.java and MyBean/MyBean.class:
This is the class that is packaged as an ActiveX component. It
has three public methods: direct, indirect, and getClassPath.
Method direct is an empty method that I invoke from an ActiveX
client to test that the simplest thing works.
Method indirect demonstrates the problem. It references class
MyClass/MyClass, which it should find along the class path
defined by the CLASSPATH environment variable, but doesn't when
running in an ActiveX component.
2. MyClass/MyClass.java and MyClass/MyClass.class:
This is the class that class MyBean/MyBean's indirect method
cannot find when running in an ActiveX component, even though
MyClass/MyClass is along the class path defined by the CLASSPATH
environment variable.
3. VBClient/Call746249.vbp, VBClient/main.frm and Call746249.exe:
The vbp and frm files are the Visual Basic 6 files used to build
Call746249.exe, the client application.
4. MyBean/MyBean.jar, MyBean/MyBean.reg and MyBean/MyBean.tlb:
The jar file contains class MyBean/MyBean and is used by the
Packager to create the reg and tlb files.
5. PackageMyBean.ksh:
The Korn Shell script I use to package and register class
MyBean/MyBean as an ActiveX component. I include it here as a
technical curiosity.
------------------------------
I have a class that is packaged as a JavaBean-ActiveX component. This class references classes that are normally found via the CLASSPATH environment variable. When this class is instantiated by an ActiveX client, it is unable to reference the classes that are found via the CLASSPATH environment variable. I have been able to work around this problem by manually making the appropriate -classpath entry in the Java Run Time Parameters in the Java Plug-in Control Panel. While this is okay for my development activities, it will not be acceptable when this JavaBean-ActiveX component is deployed in a production environment with hundreds of work stations in offices around the world. Either the component must be able to reference classes via the CLASSPATH environment variable, or I must be able to set the Java Plug-in's Run Time Parameters automatically from a system management tool or installation program.
This problem did not occur until I started using Java 2 and JDK1.3.0_01/02. When I was using JDK 1.1.8, the component could find classes via the CLASSPATH environment variable.
I have attached a testcase which will illustrate this problem in detail:
INSTRUCTIONS:
1. Unzip this file in a working directory, preserving the
directory structure contained it this file.
2. Add the working directory to your CLASSPATH environment
variable.
3. Test your configuration by running class MyBean.MyBean
without any Java command line options:
java MyBean.MyBean
It should display the current java.class.path System Property,
followed by "end of test" on the next line.
4. Package and register class MyBean/MyBean as an ActiveX
component. You do need to do the packaging; the jar, tlb, and
reg files are already in subdirectory MyBean. You can just
modify MyBean.reg so that it refers to directories on your
machine instead of mine, then apply it to your registry. You
must replace all occurrences of three strings:
- d:\\Program Files\\JavaSoft\\JRE\\1.3.0_02\\bin
- E:\\Projects\\VUE\\JavaDev\\SunCall746249
- E:/Projects/VUE/JavaDev/SunCall746249
Replace the first with your jre bin directory's path, and the
second and third with the working directory's path.
Or, you can package and register class MyBean/MyBean yourself.
5. See the problem. Run the client application,
VBClient/Call746249.exe. It should show that the
java.class.path System Property is the current directory. Or,
in other words, it displays a dot (.).
If you click the "Invoke MyBean.direct" button, an information
message box is displayed indicating that method MyBean.direct
was invoked.
Now here's the problem. Click button "Invoke MyBean.indirect."
An error message box is displayed indicating that class
MyClass/MyClass could not be found. Step 3 above tested that
this class, which is on the class path defined by the CLASSPATH
environment variable, can be found when Java is run from the
command line. With JDK 1.1.8, this problem did not occur.
6. Here's my temporary workaround. In the Java Plug-in
Control Panel's Java Run Time Parameters, enter -classpath
followed by the working directory. Now, when you run the client
application the java.class.path System Property is shown as
the working directory, and clicking the "Invoke MyBean.indirect"
button shows an information message box indicating that method
MyBean.indirect was invoked. In other words, now, we can find
class MyClass/MyClass.
This wordaround is okay during my development activities, but is
not when the application is deployed to hundreds of workstations
in offices around the world. The ActiveX component should be
able to reference classes found along the class path defined by
the CLASSPATH environment variable, as it did when using
JDK 1.1.8.
FILE DESCRIPTIONS:
1. MyBean/MyBean.java and MyBean/MyBean.class:
This is the class that is packaged as an ActiveX component. It
has three public methods: direct, indirect, and getClassPath.
Method direct is an empty method that I invoke from an ActiveX
client to test that the simplest thing works.
Method indirect demonstrates the problem. It references class
MyClass/MyClass, which it should find along the class path
defined by the CLASSPATH environment variable, but doesn't when
running in an ActiveX component.
2. MyClass/MyClass.java and MyClass/MyClass.class:
This is the class that class MyBean/MyBean's indirect method
cannot find when running in an ActiveX component, even though
MyClass/MyClass is along the class path defined by the CLASSPATH
environment variable.
3. VBClient/Call746249.vbp, VBClient/main.frm and Call746249.exe:
The vbp and frm files are the Visual Basic 6 files used to build
Call746249.exe, the client application.
4. MyBean/MyBean.jar, MyBean/MyBean.reg and MyBean/MyBean.tlb:
The jar file contains class MyBean/MyBean and is used by the
Packager to create the reg and tlb files.
5. PackageMyBean.ksh:
The Korn Shell script I use to package and register class
MyBean/MyBean as an ActiveX component. I include it here as a
technical curiosity.