Hide Forgot
Description of problem: up to (and including) 1:1.6.0.0-44.1.9.1.fc14 I could use the Virtual KVM of my HP ProLiant MicroServer Remote Access Card just fine. Updating to 1:1.6.0.0-52.1.9.7.fc14 makes it fail with "Connection Failed" (reported by the KVM java application) Version-Release number of selected component (if applicable): java-1.6.0-openjdk-1.6.0.0-52.1.9.7.fc14.src.rpm How reproducible: always Steps to Reproduce: 1. go to HP ProLiant MicroServer Remote Access Card web interface (this is a cheap BMC that HP sells for the MicroServer) 2. click 'Launch KVM Viewer' under 'vKVM & vMedia' 3. jnlp is downloaded 4. 'Connecting to KVM' dialog is displayed Actual results: 'Connection Failed' dialog is displayed Expected results: Successfult connect and see video output of HP ProLiant MicroServer Additional info: - the machine model in question can be seen at http://h10010.www1.hp.com/wwpc/uk/en/sm/WF06a/15351-15351-4237916-4237917-4237917-4248009.html - if I look at the jnlp, I see a section as follows (replaced my local domain name with EXAMPLE) <resources> <j2se version="1.6 1.5 1.4+"/> <jar href="http://hp-bmc.EXAMPLE.com:80/software/avctKVM.jar" download="eager" main="true" /> </resources> <resources os="Windows"> <nativelib href="http://hp-bmc.EXAMPLE.com:80/software/avctKVMIOWin32.jar" download="eager"/> </resources> <resources os="Linux"> <nativelib href="http://hp-bmc.EXAMPLE.com:80/software/avctKVMIOLinux.jar" download="eager"/> </resources> not sure if that is the problem - the package linked at https://bugzilla.redhat.com/show_bug.cgi?id=675271#c4 does not solve the problem
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