8298 - Java doesn't work for 4.x style signed java.

Status: VERIFIED WONTFIX

(Core Graveyard :: Java: OJI, defect, P3)

Description

[Stephen P. Morse]

dp wanted to know why we are not eating dogfood and encouraged us to spend an
hour using it to do such things as look up AOL stock price.  OK, I tried it and
went to http://people.netscape.com/morse/stocks/jchart.htm to see the AOL price.
Nothing happened!  All I got was a blank screen.

Comment 1

[Alex Musil]

You need to run the latest JRE/OJI installer.

Comment 2

[edburns]

I tried to load this applet into nav4.5, and get this error.
Applet JEChart2 class JEChart2 got a security violation.  Could not resolve IP
for host people.netscape.com. See the trustProxy property.

Is it possible for me to view this applet in a site that only uses a NS proxy
server for the firewall?

Also, is Proxy support working in the current mozilla build?

Comment 3

[Stephen P. Morse]

I don't know the answer to either of your questions.  But I do know that it
works for me under 4.x both inside and outside the netscape firewall.

Comment 4

[edburns]

Well, the applet loads and displays the UI with the "Chart", "Top", "Go!"
buttons.  I can modify the setting in the combo box.  However, nothing displays
in the main UI area.  I think it may have something to do with this:

Document: Done (119.031 secs)
created stream for http://people.netscape.com/morse/stocks/JEChart9.jar
killing stream for http://people.netscape.com/morse/stocks/JEChart9.jar
Live!Charts 990203.1a (204.71.198.40)
(c) 1998,1999 Quote.com
by Eric Scott Hunsader ([e-mail])
java.security.AccessControlException: access denied (java.net.SocketPermission 2
04.71.198.40 resolve)
failed to set the page title.
Reload(http://cvs-mirror.mozilla.org/webtools/tinderbox/SeaMonkey/flash.rdf, 300
)

Perhaps I have to modify the security settings.

Can we call this fixed or do you still think it doesn't work?

Comment 5

[Stephen P. Morse]

If nothing displays in the main area, I wouldn't call this working.  Try it
under 4.x and you'll see what it is supposed to be doing.  If it's not doing
that, then it's not working.

Comment 6

[edburns]

I tried specifying the SOCKS server using the JDK 1.3 Java Control Panel, and
now I get this:load: class JEChart2.class not found.
java.lang.ClassNotFoundException: java.net.SocketException: SOCKS server cannot
conect to identd
        at sun.plugin.protocol.http.SocksSocket.connect(Unknown Source)
        at sun.plugin.protocol.http.SocksSocket.<init>(Unknown Source)
        at sun.plugin.protocol.http.SocksSocket.<init>(Unknown Source)
        at sun.plugin.protocol.jdk12.http.HttpClient.doConnect(Unknown Source)
        at sun.net.www.http.HttpClient.openServer(Unknown Source)
        at sun.net.www.http.HttpClient$2.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.net.www.http.HttpClient.privilegedOpenServer(Unknown Source)
        at sun.net.www.http.HttpClient.openServer(Unknown Source)
        at sun.net.www.http.HttpClient.<init>(Unknown Source)
        at sun.net.www.http.HttpClient.<init>(Unknown Source)
        at sun.plugin.protocol.jdk12.http.HttpClient.<init>(Unknown Source)
        at sun.plugin.protocol.jdk12.http.HttpClient.New(Unknown Source)
        at sun.plugin.protocol.jdk12.http.HttpURLConnection.privBlock(Unknown So
urce)
        at sun.plugin.protocol.jdk12.http.HttpURLConnection$PrivilegedBlockActio
n.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.plugin.protocol.jdk12.http.HttpURLConnection.connect(Unknown Sour
ce)
        at sun.plugin.protocol.jdk12.http.HttpURLConnection.getInputStream(Unkno
wn Source)
        at java.net.HttpURLConnection.getResponseCode(Unknown Source)
        at sun.applet.AppletClassLoader.getBytes(Unknown Source)
        at sun.applet.AppletClassLoader.access$100(Unknown Source)
        at sun.applet.AppletClassLoader$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.applet.AppletClassLoader.findClass(Unknown Source)
        at sun.plugin.security.PluginClassLoader.findClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at sun.applet.AppletClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at sun.applet.AppletClassLoader.loadCode(Unknown Source)
        at sun.applet.AppletPanel.createApplet(Unknown Source)
        at sun.plugin.AppletViewer.createApplet(Unknown Source)
        at sun.applet.AppletPanel.runLoader(Unknown Source)
        at sun.applet.AppletPanel.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)

I'm going to see if this is a JDK problem.

Ed

Comment 7

[daver]

Editing out this comment from the bug title:  "(or: Why I'm not eating dogfood
yet") since the 5.0 project mananagement team searches titles for the word
dogfood.  It's fine to mention your need to have this for mozilla dogfood but
please try to keep in the description portion of the bug.  Thanks.

Comment 8

[edburns]

I'm still getting the SOCKS can't connect to identd error

Comment 9

[Robert H. Yang]

The SOCKS error is because Ed's SOCKS server doesn't permit HTTP traffic.

Comment 10

[edburns]

I now get this error:

Live!Charts 990203.1a (204.71.198.40)
(c) 1998,1999 Quote.com
by Eric Scott Hunsader ([e-mail])
java.security.AccessControlException: access denied (java.net.SocketPermission 2
04.71.198.40 resolve)

Comment 11

[Robert H. Yang]

My understanding is that this exception is a result of Java 2 security when
accessing an applet from behind a firewall in which local DNS cannot resolve
the requested hostname.

In order to prevent IP spoofing outside the firewall, the JRE first attempts to
resolve the requested hostname to an IP address using local DNS.  If that
fails, a security exception of the kind you've noted is thrown.

There are two ways to get around this, as follows :

(1) Put the requested hostname into the local machine's hosts file.
    This will be under \winnt\system32\drivers\etc on NT4, and \windows
    under Win'95/98.

(2) Use a .java.policy file to give the local machine necessary permissions.

The suggested solution is item (1) above.

Comment 12

[edburns]

Believe me Robert, I tried adding 204.71.198.40 to the HOSTS file, but got the
same result.

Comment 13

[Robert H. Yang]

I should have mentioned that the line you should add to your hosts file
should look as follows :

    <ip address>   <hostname>

For example :

    131.252.220.22	www.cs.pdx.edu

Then after you've saved the file, ping the host and make sure that the system
can resolve the hostname - this is the critical part.  Success in pinging
probably won't work, since you're behind the firewall, but that doesn't matter.

Here's one you can try with the above line :

    http://www.cs.pdx.edu/~ryang/JarTestApplet.html

I apologize for the confusion.

Comment 14

[edburns]

morse: is this a signed applet?

Comment 15

[Stephen P. Morse]

Yes, it is definitely a signed applet.  Is that why it doesn't work yet --
becausing signing is not yet implemented in 5.0?

Comment 16

[leger]

Java is not needed for dogfood. Putting on the PDT- radar.

Comment 17

[Stephen P. Morse]

Java should be required for dogfood.  There are plenty of sites out there that
use java.  Now the problem here might be more restrictive it that it has to do
with signed java.  In which case there are fewer sites affected.

But this particular applet is one of my favorite and one that I use frequently.
It's the best stock-charting applet around.  If this applet can't run on M12,
then I'll be forced to remain with 4.7 a little while longer.

Comment 18

[chris hofmann]

puttin' on the beta1 radar..  removing the pdt- for the dogfood designation

Comment 19

[leger]

Putting on PDT- radar for beta1.  Java need to work, but not a critical beta 
stopper to signed java.

Comment 20

[leger]

Putting dogfood in the keyword field.

Comment 21

[edburns]

Dear morse:

Signed applets are top on our list, after getting java working again AT ALL.  
We have been depending on the stability of daily builds in order to work on OJI 
features, but this approach doesn't work.  From now on, the OJI team at Sun 
will work only with milestone builds.  When a new milestone comes out, we'll 
take the hit and upgrade to it.

We STRONGLY believe that this is the only way we can make any progress 
implementing features like signed applets.

Comment 22

[edburns]

We still believe that we won't be able to implement this until the OJI team 
just depends on milestone builds.

Comment 23

[edburns]

We won't be doing this for beta 1.  Can the PDT team please revise this 
accordingly?  Thanks,

Ed

Comment 24

[edburns]

Assigning to jeff.dyer

Comment 25

[edburns]

Adding 27664 poster, kdean, to CC list.

Comment 26

[drapeau]

Jeff Dyer is working on it.  We expect to have this for Beta 2, and I'm
nominating this as a key feature to be put in.

Comment 27

[ekrock's old account (dead)]

Clearing [PDT-] to trigger re-evaluation by PDT for nsbeta2. Java 
broken-->nsbeta2. Java on b2 list. 

Comment 28

[Jim Roskind]

We are not going to be backvwards compatible and support Java API defined by 
Netscape in 4.x.  Each JVM will have *some* security model, and it will be up 
to JavaSoft to defined that *java* api and usage.  Unless their is a sudden 
change, the precise *java* api will be distinct from Netscape's 4.x calls.
Signed Java/JS will be supported... just not backwards compatible with 4.x.

If the test case shown above is removed, then the summary could be changed to 
"get some signed Java support," and *that* would be a significant mozilla bug.

Comment 29

[John Unruh]

Verified wontfix.