Build "F" of 1.2FCS JRE in Plug-in crashes Internet Explorer when running even the most trivial of IDL applets. The applets run in Hotjava, Netscape, and appletviewer.
Ordinarily the IE VM will run the applets but for a recent incompatibility introduced with the new 1.2 security model: the IDL classes try to find the (new in 1.2) security classes and cause an NoClassDefFound exception. If all the new classes are put in the codebase, it is very possible that I.E. will run the IDL applet. However, when the Plug-in is installed, the loading of such an applet will crash the browser immediately.
Example code demonstrating this is in the Comments section. The way to investigate this bug:
0) take the simple test case from the files attached to this report:
Makefile
index.html
Hello.idl
HelloApplet.java
HelloServer.java
HelloClient.java
1) start the web server on the host machine. (Ideally this will be a Solaris
machine for Make to work in the later "running" steps)
2) start the naming service on the host machine:
tnameserv -ORBInitialPort 9099
we start on port 9099 because it does not require root priviledges to do
so. The default port for the naming service is port 900.
3) use "idltojava" to generate code from our idl file "Hello.idl"
idltojava Hello.idl
this will generate a bunch of files in a created directory HelloApp
4) including these files in your classpath, compile "HelloClient.java",
"HelloApplet.java" and "HelloServer.java" with javac
5) make sure all class files are in the deployed applet's codebase
6) deploy HTML file "index.html" in the codebase; modify to fit your machine
(my machine is named "wrath")
7) similarly modify Makefile
8) start the server side of the application. The Makefile specifies the proper
port and host machine name for the naming service, make sure it is
accurate.
make server
9) start the client applet. Start up Internet Explorer and browse the HTML
file. Under current conditions, the applet will illegally access a
memory location and be shut down by Windows.
9a) alternately, start the applet in appletviewer. It should run.
The Makefile must be altered to correctly specify your version of
appletviewer and the page location. Make sure the server side of the
application is running before attempting to run appletviewer. The HTML
file passes in the host and port information via <PARAM> tags
make applet
9b) alternately, start the client class with the make command. Again, the
Makefile specifies the proper port and host machine name for the naming
service, make sure it is accurate. It does essentially the same thing
as the applet, but not in an applet context. Make sure the server side
of the application is running before attempting to run the client.
make client
10) fix the bug and have a wild party
brian.preston@eng 1998-09-03
Ordinarily the IE VM will run the applets but for a recent incompatibility introduced with the new 1.2 security model: the IDL classes try to find the (new in 1.2) security classes and cause an NoClassDefFound exception. If all the new classes are put in the codebase, it is very possible that I.E. will run the IDL applet. However, when the Plug-in is installed, the loading of such an applet will crash the browser immediately.
Example code demonstrating this is in the Comments section. The way to investigate this bug:
0) take the simple test case from the files attached to this report:
Makefile
index.html
Hello.idl
HelloApplet.java
HelloServer.java
HelloClient.java
1) start the web server on the host machine. (Ideally this will be a Solaris
machine for Make to work in the later "running" steps)
2) start the naming service on the host machine:
tnameserv -ORBInitialPort 9099
we start on port 9099 because it does not require root priviledges to do
so. The default port for the naming service is port 900.
3) use "idltojava" to generate code from our idl file "Hello.idl"
idltojava Hello.idl
this will generate a bunch of files in a created directory HelloApp
4) including these files in your classpath, compile "HelloClient.java",
"HelloApplet.java" and "HelloServer.java" with javac
5) make sure all class files are in the deployed applet's codebase
6) deploy HTML file "index.html" in the codebase; modify to fit your machine
(my machine is named "wrath")
7) similarly modify Makefile
8) start the server side of the application. The Makefile specifies the proper
port and host machine name for the naming service, make sure it is
accurate.
make server
9) start the client applet. Start up Internet Explorer and browse the HTML
file. Under current conditions, the applet will illegally access a
memory location and be shut down by Windows.
9a) alternately, start the applet in appletviewer. It should run.
The Makefile must be altered to correctly specify your version of
appletviewer and the page location. Make sure the server side of the
application is running before attempting to run appletviewer. The HTML
file passes in the host and port information via <PARAM> tags
make applet
9b) alternately, start the client class with the make command. Again, the
Makefile specifies the proper port and host machine name for the naming
service, make sure it is accurate. It does essentially the same thing
as the applet, but not in an applet context. Make sure the server side
of the application is running before attempting to run the client.
make client
10) fix the bug and have a wild party
brian.preston@eng 1998-09-03
- relates to
-
JDK-4173634 IE Plugin should give informative message about HTML error
- Resolved
-
JDK-4209531 Callbacks to a Java Applet ( CORBA ) I.E. 4.0 sp1a
- Closed
-
JDK-4173635 README for OCX should mention sensitivity to bad HTML
- Closed