| Summary: | 1:1.6.0.0-52.1.9.7.fc14 breaks HP ProLiant MicroServer Remote Access Card KVM Viewer | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Patrick C. F. Ernzer <pcfe> |
| Component: | java-1.6.0-openjdk | Assignee: | Omair Majid <omajid> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 14 | CC: | ahughes, bloch, dbhole, jvanek, langel, lkundrak, mjw, mmatejov, omajid |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-08-16 14:56:24 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Patrick C. F. Ernzer
2011-03-13 05:36:29 UTC
Can you please run it from the command line and attach the output? $ javaws jnlp_file_name The output from verbose mode will be very useful too: $ javaws -verbose jnlp_file_name diffing the javaws -verbose output from 1:1.6.0.0-44.1.9.1.fc14 and 1:1.6.0.0-52.1.9.7.fc14 I notice < Requesting permission: (java.security.SecurityPermission putProviderProperty.SunJCE) < Requesting permission: (java.lang.RuntimePermission getProtectionDomain) < Denying permission: (java.lang.RuntimePermission getProtectionDomain) < Denying permission: (java.security.SecurityPermission putProviderProperty.SunJCE) < Requesting permission: (java.security.SecurityPermission putProviderProperty.SunJCE) < Requesting permission: (java.lang.RuntimePermission getProtectionDomain) < Denying permission: (java.lang.RuntimePermission getProtectionDomain) < Denying permission: (java.security.SecurityPermission putProviderProperty.SunJCE) < Requesting permission: (java.security.SecurityPermission putProviderProperty.SunJCE) < Requesting permission: (java.lang.RuntimePermission getProtectionDomain) < Denying permission: (java.lang.RuntimePermission getProtectionDomain) < Denying permission: (java.security.SecurityPermission putProviderProperty.SunJCE) < 03/14/2011 11:46:54:366: Connection failed. Ah, that looks a little familiar. Can you please try building icedtea-web from source and check if that fixes the problem? $ hg clone http://icedtea.classpath.org/hg/icedtea-web $ cd icedtea-web $ ./autogen.sh $ ./configure --prefix=/home/$USER/icedtea-web-image --disable-plugin $ make $ make install $ cd ~/icedtea-web-image $ bin/javaws jnlp_file (In reply to comment #7) > Can you please try building icedtea-web from > source and check if that fixes the problem? done, but it does not help Oh, I see why icedtea-web isnt working: the JVM is using its (older) version of net.sourceforge.jnlp.* packages from rt.jar rather than using the newer code from icedtea-web :( Would it be possible for you to remove the net.sourceforge.jnlp.* classes from rt.jar for testing if icedtea-web works? If not, you will probably want to build icedtea6 HEAD and use that when building icedtea-web (use ./configure --with-jdk-home=/path/to/your/icedtea6/openjdk.build/j2sdk-image/) Actually, 1.9.7 keeps netx/plugin files in netx.jar and plugin.jar. You just need to move /usr/lib/jvm/java-1.6.0-openjdk*/jre/lib/netx.jar out of the way. (In reply to comment #13) > Actually, 1.9.7 keeps netx/plugin files in netx.jar and plugin.jar. You just > need to move /usr/lib/jvm/java-1.6.0-openjdk*/jre/lib/netx.jar out of the way. Ah, yes. Thanks for that clarification Deepak. I am still on F13 which adds everything to rt.jar. Perhaps even easier would be to just edit bin/javaws, and change -Xbootclasspath/a to -Xbootclasspath/p (which would load classes from icedtea-web before classes from rt.jar, netx.jar and plugin.jar) (In reply to comment #13) > Actually, 1.9.7 keeps netx/plugin files in netx.jar and plugin.jar. You just > need to move /usr/lib/jvm/java-1.6.0-openjdk*/jre/lib/netx.jar out of the way. OK, brutally rm'ed it as I can just retore from the RPM. No longer get the error message, but also fo not get video output, mind you that could be another error. s/retore/restore/ s/fo/do/ should proofread my comments before submitting, sorry. (In reply to comment #15) > (In reply to comment #13) > > Actually, 1.9.7 keeps netx/plugin files in netx.jar and plugin.jar. You just > > need to move /usr/lib/jvm/java-1.6.0-openjdk*/jre/lib/netx.jar out of the way. > > OK, brutally rm'ed it as I can just retore from the RPM. > > No longer get the error message, but also fo not get video output, mind you > that could be another error. Ok, good to know that the permission issues are fixed. Thanks. Any output/error messages for the video output? (In reply to comment #17) > Any output/error messages for the video output? I'll have to bend my browser to use the javaws in ~/tmp/ first so I can exclude any badness introduced by me re-using a jnlp file that has what looks like 'use once' login/pass entries. Could take a day ot three. Setting NEEDINFO on me until I provided that. maybe this? SM: app: Virtual KVM Client is adding a window: com.avocent.a.a.e.o[dialog0,0,0,0x0,invalid,null,defaultCloseOperation=DO_NOTHING_ON_CLOSE,rootPane=,rootPaneCheckingEnabled=false] with appContext sun.awt.AppContext[threadGroup=Virtual KVM Client] java.lang.IllegalArgumentException: port out of range:-2147483648 full output attached as private attachment. also did the change bin/javaws as per comment #14 so that is I reinstall the java rpm I still will be using the self-built one (In reply to comment #20) > maybe this? > > SM: app: Virtual KVM Client is adding a window: > com.avocent.a.a.e.o[dialog0,0,0,0x0,invalid,null,defaultCloseOperation=DO_NOTHING_ON_CLOSE,rootPane=,rootPaneCheckingEnabled=false] > with appContext sun.awt.AppContext[threadGroup=Virtual KVM Client] > java.lang.IllegalArgumentException: port out of range:-2147483648 > Hmm.. where is this exception being thrown from? Is there any more to the stack trace? > full output attached as private attachment. > I don't see the exception in the full output. The last two lines I see are VideoQuality.initFromProperties() Selecting proxy for: socket://localhost:8192 (In reply to comment #21) > I don't see the exception in the full output. The last two lines I see are > VideoQuality.initFromProperties() > Selecting proxy for: socket://localhost:8192 I'm not quite sure where it picked that proxy up (I have a local privoxy, that runs on 8118 and is only configured in the browser. gnome network proxy settings points at a proxy.pac on this network, but no 8192 in there either). BUT cleaning out ~/.netx/cache/http/* made it work. We now have video again. To be sure, I have also verified that the problem still remains if the browser uses javaws from 1:1.6.0.0-52.1.9.7.fc14, so the fix that I got from http://icedtea.classpath.org/hg/icedtea-web is indeed needed. This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping |