Bug 1089130 - Initialization Error when trying to run javaws file
Summary: Initialization Error when trying to run javaws file
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: icedtea-web
Version: 21
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: jiri vanek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-04-18 04:50 UTC by Sitsofe Wheeler
Modified: 2015-12-02 16:08 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2015-12-02 03:10:36 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
IcedTea Console Output (7.51 KB, text/plain)
2014-04-18 04:50 UTC, Sitsofe Wheeler
no flags Details
srpm with (tmp!) fix (1.54 MB, application/x-rpm)
2014-04-29 13:03 UTC, jiri vanek
no flags Details
64b build for f20. (1.30 MB, application/x-rpm)
2014-04-29 13:04 UTC, jiri vanek
no flags Details
IcedTea Console Output (7.47 KB, text/plain)
2014-05-17 10:05 UTC, Sitsofe Wheeler
no flags Details

Description Sitsofe Wheeler 2014-04-18 04:50:03 UTC
Description of problem:
When trying to run a javaws file from a network KVM icedtea returns an error message saying
Initialization Error: Could not initialize application. The application has not been initialized, for more information execute javaws from the command line.

Version-Release number of selected component (if applicable):
icedtea-web-1.5-2.fc20.x86_64
java-1.7.0-openjdk-devel-1.7.0.60-2.4.5.1.fc20.x86_64
java-1.7.0-openjdk-1.7.0.60-2.4.5.1.fc20.x86_64
java-1.7.0-openjdk-headless-1.7.0.60-2.4.5.1.fc20.x86_64

How reproducible:
Reproducible every time.

Steps to Reproduce:
1. Log into network KVM.
2. Select a host.
3. Click Connect.
4. When firefox opens a dialog asking what to do with the Inquery file select Open with IcedTea Web Start and click OK.

Actual results:
Dialog with an error message saying
Initialization Error: Could not initialize application. The application has not been initialized, for more information execute javaws from the command line.

Expected results:
Java app to start.

Additional info:
Attaching console log output.

Comment 1 Sitsofe Wheeler 2014-04-18 04:50:51 UTC
Created attachment 887423 [details]
IcedTea Console Output

Comment 2 jiri vanek 2014-04-18 09:35:01 UTC
Is the jar:
https://kvm.test.exsequi.com:443/JavaClient.jar
accessible via bowser?
Via wget?
or via curl?
what about https://kvm.test.exsequi.com:443/JavaClient.class ?

Is application running when only unsecure http is used?

Can I run (and so debug) this application somehow?

thank you for bug rpeort!

Comment 3 Sitsofe Wheeler 2014-04-19 06:37:42 UTC
So now I've looked closer it turns out that when I clicking around the KVM web interface on Windows it wasn't using Java Web Start but was actually running a native exe via some sort of ActiveX plugin... At any rate, here are the results of the commands you are asking for:

curl -O https://kvm/JavaClient.jar
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0curl: (60) Peer's certificate issuer has been marked as not trusted by the user.
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

wget https://kvm/JavaClient.jar
--2014-04-19 06:21:14--  https://kvm/JavaClient.jar
Resolving kvm (kvm)... x.x.x.x
Connecting to kvm (kvm)|x.x.x.x|:443... connected.
ERROR: cannot verify kvm's certificate, issued by ‘/C=US/ST=RI 02892/L=W. Kingston/O=American Power Conversion Corp./OU=APC/CN=American Power Conversion Corp./emailAddress=http://www.apc.com/support’:
  Self-signed certificate encountered.
    ERROR: certificate common name ‘American Power Conversion Corp.’ doesn't match requested host name ‘kvm’.
To connect to kvm insecurely, use `--no-check-certificate'.

Firefox:
This Connection is Untrusted

You have asked Firefox to connect securely to kvm, but we can't confirm that your connection is secure.

Normally, when you try to connect securely, sites will present trusted identification to prove that you are going to the right place. However, this site's identity can't be verified.
What Should I Do?

If you usually connect to this site without problems, this error could mean that someone is trying to impersonate the site, and you shouldn't continue.

In Internet Explorer 11 on Windows what happens is rather complicated:
1. After double clicking a button a small Java dialog appears.
2. After it disappears a Security Warning dialog appears saying:
Do you want to Continue?
The connection to this website is untrusted.
Website https://kvm:443/
Note: The certificate is not valid and cannot be used to verify the identity of this website.
More information
3. Clicking Continue opens an "Unable to launch the application." dialog with the following in it:
Name: JavaClient
Publisher: American Power Conversion Corp.
Location: https://kvm:443
Clicking the Details button showed that there had been a Socket error.

Going round again from step gets me to step 3.
3. Clicking Continue opens an "Application Blocked" dialog with the following in it:
Name: com.main.Main
Location: https://kvm:443
Your security settings have blocked an application signed with an expired or not-yet-valid certificate from running

Going to the Configure Java program, selecting the Security tab, clicking the Edit Site List... button and then adding https://kvm:443 and then starting the steps again gets me to this

3. Clicking Continue opens a "Security Warning" dialog with the following in it:
Do you want to run this application?
Name: com.main.Main
Publisher: ATEN INTERNATIONAL CO., LTD.
Locations: https://kvm:443
           Launched from downloaded JNLP file
Running this application may be a security risk
Risk: This application will run with unrestricted access which may put your computer and personal information at risk. The information provided is unreliable or unknown so it is is recommended not to run this application unless you are familiar with its source

      The certificate used to identify this application has expired
      More Information

Select the box below, then click Run to start the application
  [] I accept the risk and want to run this application

Ticking the box then clicking Run does indeed start the application.

So it seems there are many problems with how things are being served:
1. https site is using a self signed cert.
2. Class is signed with a cert that expired on Mar 08 2014.

In reality I suspect most people will get fed up long before they have waded through the above and download the jar directly (there's a web interface link for doing so) and then run
java -jar JavaClient.jar
which seems to work regardless of platform. Nonetheless what do you think Jiri?

Comment 4 jiri vanek 2014-04-23 14:59:18 UTC
Hmm.. I have already encountered issues with secure http with ITW, and I'm working on more general fix. We will see how successful it will be.

Just for record - this was working with IcedTea-Web 1.4 (previous itw) ?
If you do not know, do you mind to try? (downgrade should work just fine, or https://koji.fedoraproject.org/koji/buildinfo?buildID=496249 is your friend)

I will (I hope soon) prepare the general fix for secure connections. In that case I will update the bug.

Comment 5 jiri vanek 2014-04-29 12:44:19 UTC
Do you mid to try the patch in http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-April/027417.html  ?

Comment 6 jiri vanek 2014-04-29 12:56:57 UTC
There is scratch build with it, please not, it will endure just for week:
http://koji.fedoraproject.org/koji/taskinfo?taskID=6794256

Comment 7 jiri vanek 2014-04-29 13:03:31 UTC
Created attachment 890787 [details]
srpm with (tmp!) fix

Comment 8 jiri vanek 2014-04-29 13:04:30 UTC
Created attachment 890788 [details]
64b build for f20.

Comment 9 Sitsofe Wheeler 2014-04-29 15:03:52 UTC
With the build from comment #8 a Java dialog with the title of Error appears. Here's the output from the Java console:

System logger called with result of 0
System logger called with result of 0
System logger called with result of 0
System logger called with result of 0
System logger called with result of 0
System logger called with result of 0
System logger called with result of 0
System logger called with result of 0
System logger called with result of 0
System logger called with result of 0
System logger called with result of 0
System logger called with result of 0
System logger called with result of 0
System logger called with result of 0
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize application. The application has not been initialized, for more information execute javaws from the command line.     at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:789)     at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:529)     at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:911) Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Unknown Main-Class. Could not determine the main class for this application.     at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:684)     at net.sourceforge.jnlp.runtime.JNLPClassLoader. (JNLPClassLoader.java:277)     at net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(JNLPClassLoader.java:351)     at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:418)     at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:394)     at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:781)     ... 2 more 
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize application. The application has not been initialized, for more information execute javaws from the command line.     at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:789)     at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:529)     at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:911) Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Unknown Main-Class. Could not determine the main class for this application.     at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:684)     at net.sourceforge.jnlp.runtime.JNLPClassLoader. (JNLPClassLoader.java:277)     at net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(JNLPClassLoader.java:351)     at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:418)     at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:394)     at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:781)     ... 2 more 
netx: Initialization Error: Could not initialize application. (Fatal: Initialization Error: Unknown Main-Class. Could not determine the main class for this application.)
Activate native: https://kvm:443/JavaClient.jar
Activate jar: file:/home/swheeler/.cache/icedtea-web/cache/11/https/kvm/JavaClient.jar
Jars not ready to provide attribute Application-Name
App already has trusted publisher: true
OU=Class 3 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US found in cacerts (/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.0.fc20.x86_64/jre/lib/security/cacerts)
Jar found at /home/swheeler/.cache/icedtea-web/cache/11/https/kvm/JavaClient.jarhas been verified as SIGNED_NOT_OK
@ /JavaClient.jar
-(DOWNLOADING)
+(DOWNLOADED)
Status: CONNECTED DOWNLOADED STARTED
Downloadinghttps://kvm:443/JavaClient.jar using net.sourceforge.jnlp.cache.CURL@3e06dc14 (encoding : null)
Selected proxies: [DIRECT]
Browser selected proxies: [DIRECT]
Browser proxy option "4" (Automatic) not supported yet.
Selecting proxy for: socket://kvm:443
Selected proxies: [DIRECT]
Browser selected proxies: [DIRECT]
Browser proxy option "4" (Automatic) not supported yet.
Selecting proxy for: https://kvm:443/JavaClient.jar
@ /JavaClient.jar
-(DOWNLOAD)
+(DOWNLOADING)
Status: CONNECTED DOWNLOADING STARTED
@ /JavaClient.jar
-(CONNECTING)
+(CONNECTED)
Status: CONNECTED DOWNLOAD STARTED
isCurrent: https://kvm:443/JavaClient.jar = false
Selected proxies: [DIRECT]
Browser selected proxies: [DIRECT]
Browser proxy option "4" (Automatic) not supported yet.
Selecting proxy for: socket://kvm:443
Selected proxies: [DIRECT]
Browser selected proxies: [DIRECT]
Browser proxy option "4" (Automatic) not supported yet.
Selecting proxy for: https://kvm:443/JavaClient.jar
best url for location=https://kvm:443/JavaClient.jar state=CONNECTING DOWNLOAD STARTED is https://kvm:443/JavaClient.jar by HEAD
Key : Server ,Value : [HTTP Server(V1.0)]
Key : Content-Type ,Value : [application/x-java-archive]
Key : Accept-Ranges ,Value : [bytes]
Key : Connection ,Value : [close]
Key : Last-Modified ,Value : [Wesnesday, June 22 2011 11:00:00 GMT]
Key : Content-Length ,Value : [537077]
Key : null ,Value : [HTTP/1.0 200 OK]
Selected proxies: [DIRECT]
Browser selected proxies: [DIRECT]
Browser proxy option "4" (Automatic) not supported yet.
Selecting proxy for: socket://kvm:443
Selected proxies: [DIRECT]
Browser selected proxies: [DIRECT]
Browser proxy option "4" (Automatic) not supported yet.
Selecting proxy for: https://kvm:443/JavaClient.jar
All possible urls for location=https://kvm:443/JavaClient.jar state=CONNECTING DOWNLOAD STARTED : [https://kvm:443/JavaClient.jar, https://kvm:443/JavaClient.jar]
@ /JavaClient.jar
-(CONNECT)
+(CONNECTING)
Status: CONNECTING DOWNLOAD STARTED
@ /JavaClient.jar
+(DOWNLOAD)
Status: CONNECT DOWNLOAD STARTED
@ /JavaClient.jar
+(CONNECT)
Status: CONNECT STARTED
@ /JavaClient.jar
+(STARTED)
Status: STARTED
Jars not ready to provide attribute Application-Name
New classloader: file:/var/tmp/Inquery
        result: null
Jars not ready to provide attribute Application-Name
Jars not ready to provide attribute Application-Name
Acquired shared lock on /tmp/swheeler/netx/locks/netx_running to indicate javaws is running
UNIQUEKEY=1398783689468-2026337110-file:/var/tmp/Inquery
Acceptable vendor tag found, contains: American Power Conversion Corp.
Acceptable title tag found, contains: JavaClient
Jars not ready to provide attribute Application-Name
Description: JavaClient
Homepage: http://www.apc.com/
Using MalformedXMLParser
UNIQUEKEY=1398783689449-89552599-file:/var/tmp/Inquery
Acceptable vendor tag found, contains: American Power Conversion Corp.
Acceptable title tag found, contains: JavaClient
Jars not ready to provide attribute Application-Name
Description: JavaClient
Homepage: http://www.apc.com/
Using MalformedXMLParser
@ /var/tmp/Inquery
+(CONNECTED DOWNLOADED STARTED)
Status: CONNECTED DOWNLOADED STARTED
JNLP file location: /var/tmp/Inquery
Read 180 entries from Firefox's preferences
Found preferences file: /home/swheeler/.mozilla/firefox/1wzuvxg5.default/prefs.js
Using firefox's profiles file: /home/swheeler/.mozilla/firefox/profiles.ini
Starting security dialog thread
WARNING: key deployment.system.cachedir has no value, setting to default value
Loading User level properties from: /home/swheeler/.config/icedtea-web/deployment.properties
cache: /home/swheeler/.cache/icedtea-web file exists:true
config: /home/swheeler/.config/icedtea-web file exists: true
System is already following XDG .cache and .config specifications

Comment 10 jiri vanek 2014-04-30 08:20:35 UTC
Uff.. It seams that CURL communication was not even started. Do you mind to clear cache? (basically remove ~ /home/swheeler/.cache/icedtea-web/cache)

Anyway  -this patch will not go to production. But the pure-java impl is a bit more complex :(

Comment 11 Sitsofe Wheeler 2014-05-17 10:05:58 UTC
Created attachment 896544 [details]
IcedTea Console Output

Similar result with icedtea-web-1.5-3.fc19.x86_64 after doing rm -rf ~/.cache/icedtea-web/ :

net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not
initialize application. The application has not been initialized, for more
information execute javaws from the command line.     at
net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:789)     at
net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:529)     at
net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:911) Caused by:
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Unknown
Main-Class. Could not determine the main class for this application.     at
net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:684)
    at net.sourceforge.jnlp.runtime.JNLPClassLoader.

Full output added as attachment.

Comment 12 Sitsofe Wheeler 2014-05-17 15:51:20 UTC
In reply to comment #4:
For the record, trying to use Java Webstart with this also fails with icedtea-web-1.4.1-0.fc20.x86_64 .

Comment 13 jiri vanek 2014-07-31 11:14:01 UTC
Just update. the https issues lead to rewrite of connection engines in 1.6

Comment 14 jiri vanek 2014-08-08 10:50:24 UTC
See inital patch. http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-August/028911.html

Well, Sitsofe, I'm afraid I will need some help with testing of this patch.Are you able to creat patched rpms or at least test provided test ones?

Comment 15 Sitsofe Wheeler 2014-08-09 10:12:39 UTC
Thanks for the update jiri. I can create patched RPMs (although it may take me longer as I need to download the source and then all the tools to build the RPM etc) and I can always test provided ones a bit quicker. If you want me to do the patching which SRPM should I be trying to start with?

Comment 16 jiri vanek 2014-08-12 10:18:34 UTC
Well probably the most simple way (then patched rpm) is 
 - remove itw package (a must)
 - download http://icedtea.classpath.org/hg/icedtea-web/archive/b4363c984e1b.tar.gz (or clone http://icedtea.classpath.org/hg/icedtea-web/)
 - apply patch from c#14
 - build, you will need
  java-1.{7,8}.0-openjdk-devel
  gecko-devel
  glib2-devel
  autoconf
  automake
  xulrunner-devel
 - then ./autogen ; ./configure --disable-docs --prefix=/home/somebody/icedtea-web-image/ ; make; make install
 - generally http://icedtea.classpath.org/wiki/IcedTea-Web#Building_IcedTea-Web
 - then run /home/somebody/icedtea-web-image/bin/javaws xxx://url/your.jnlp

If it fails for you on default, then please try to elaborate with  the deployment properties swithches as described in email from c#14


I know this is quite a lot of work, but I don't have any other "broken" https reproducer handy :(

Comment 17 gitne 2014-08-12 20:22:25 UTC
(In reply to Sitsofe Wheeler from comment #3)
> wget https://kvm/JavaClient.jar
> --2014-04-19 06:21:14--  https://kvm/JavaClient.jar
> Resolving kvm (kvm)... x.x.x.x
> Connecting to kvm (kvm)|x.x.x.x|:443... connected.
> ERROR: cannot verify kvm's certificate, issued by ‘/C=US/ST=RI 02892/L=W.
> Kingston/O=American Power Conversion Corp./OU=APC/CN=American Power
> Conversion Corp./emailAddress=http://www.apc.com/support’:
>   Self-signed certificate encountered.
>     ERROR: certificate common name ‘American Power Conversion Corp.’ doesn't
> match requested host name ‘kvm’.
> To connect to kvm insecurely, use `--no-check-certificate'.

Just for the record, have you tried importing this certificate into your user account's IcedTea-Web certificate store?
You can do this by launching the IcedTea-Web Control Panel (NetX) then heading over to Certificates, choosing "Trused Root CA Certificates" and/or "Trusted Certificates" for "Certificate Type" and importing the above certificate. Or, you can import it with the keytool on the command line. By default, your user account's trusted IcedTea-Web certificate stores are located in ~/.config/icedtea-web/security/{trusted.cacerts,trusted.certs}.

You can download the above certificate while connecting to https://kvm with your browser. In Firefox you can export the certificate either when you are prompted to accept or deny the certificate, or after the web page has loaded via right-clicking on the page/View Page Info (or Ctrl+I)/Security/View Certificate/Details/Export... Or, via Edit/Preferences/Advanced/Certificates/View Certificates/Servers after you have accepted the certificate and the page has loaded.

If it turns out to be working for you, please contact your network or kvm administrator to update their kvm web interface certificate, so that it gets automatically verified and accepted in your organization.

Comment 18 Sitsofe Wheeler 2014-12-26 09:03:20 UTC
I've finally tried the steps described in comment #16 on a Fedora 21 system with icedtea-web-1.5.2-0.fc21.x86_64
and the KVM firmware has been upgraded. Things seem to have become worse because Firefox no longer offers icedtea as an application to open JNLP files and only offers gedit...

Running:
$ javaws https://kvm/Inquery

results in the following:
netx: Read Error: Could not read or parse the JNLP file. (Root element is not a jnlp element.)

The contents of Inquery looks roughly like this:
<?xml version="1.0" encoding="utf-8"?><jnlp spec="1.0+" codebase="https://kvm:443"><information><title>JavaClient</title><vendor>American Power Conversion Corp.</vendor><homepage href="http://www.apc.com/"/><description>JavaClient</description></information><security><all-permissions/></security><resources><j2se version="1.5+" max-heap-size="128m" href="http://java.sun.com/products/autodl/j2se"></j2se><jar href="JavaClient.jar" main="true"/></resources><application-desc main-class=" com.main.Main"><argument>ConnID=STRING</argument><argument>ServPt=9000</argument><argument>Username=user</argument><argument>Host=kvm</argument></application-desc></jnlp>

Running
$ javaws Inquery

results in this:
netx: Initialization Error: Could not initialize application. (Fatal: Initialization Error: Unknown Main-Class. Could not determine the main class for this application.)
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize application. The application has not been initialized, for more information execute javaws from the command line.
	at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:782)
	at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:522)
	at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:904)
Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Unknown Main-Class. Could not determine the main class for this application.
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:684)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:277)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(JNLPClassLoader.java:351)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:418)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:394)
	at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:774)
	... 2 more

But I think this is to be expected until at least 1.6 of icedtea. Importing the certificate makes no difference to this result.

Moving on to the compilation I roughly did this:
hg clone http://icedtea.classpath.org/hg/icedtea-web/
cd icedtea-web/
curl -O http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140807/8eaaa850/httpsSolution_01-0001.patch
hg up 1078:b4363c984e1b
patch -p1 < httpsSolution_01-0001.patch
./autogen.sh
./configure
make

but the make process failed with an error message:
[...]
/home/user/dev/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc: In function ‘char* NP_GetMIMEDescription()’:
/home/user/dev/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:2091:24: error: ambiguating new declaration of ‘char* NP_GetMIMEDescription()’
 NP_GetMIMEDescription ()
                        ^
In file included from /home/user/dev/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.h:44:0,
                 from /home/user/dev/icedtea-web/plugin/icedteanp/IcedTeaJavaRequestProcessor.h:47,
                 from /home/user/dev/icedtea-web/plugin/icedteanp/IcedTeaScriptablePluginObject.h:45,
                 from /home/user/dev/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:59:
/usr/include/xulrunner-33.0/npfunctions.h:255:24: note: old declaration ‘const char* NP_GetMIMEDescription()’
 NP_EXPORT(const char*) NP_GetMIMEDescription(void);
                        ^
[...]
Makefile:897: recipe for target '/home/user/dev/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.o' failed
make: *** [/home/user/dev/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.o] Error 1

Comment 19 jiri vanek 2015-01-27 14:25:06 UTC
hi!

I was able to parse the posted jnlp file by javaws without issues. So the "not xml" issue probably caused (again) by jar not being downloaded.

However (of course) the https://kvm:443 is unavailable for me.

however. looking to:
Error: Unknown Main-Class. Could not determine the main class for this application.)
Which you posted, and to jnlp, there is <application-desc main-class=" com.main.Main">

So the main class have space in it! And ITW is *not* trimming the main class attribute. 


So there are two times two issues I can see:
- main class is wrongly defined
- jar(s) is not accessible via https

And the solutions are
- in your intranet, fix the jnlpfile and fix https settings [1]
- in itw, we may trim the main class attribute, but personally I'm against. It may be dangerous, and I think in past this discussion already happened (with not trimming result). We probably will never be able to fix https issue[1]


[1] http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-August/028915.html  (whole thread is interesting for you if yuu will be fixing the server)

Comment 20 Sitsofe Wheeler 2015-06-08 11:39:16 UTC
Jiri:
Thanks for your effort on this. The "can't access the file on https" is because there is a narrow window before I'm logged out on this particular KVM (this is to try and work around other KVM issues involving a black screen). Normally the JNLP download happens so quickly that a user wouldn't face this issue.

I'll just summarise this issue to make it easier to come across this issue in Google:

The way the APC KVM2132P Version 1.0.086 (by Schneider Electric) Java Web Start applet is served has a bug that will make IcedTea (icedtea-web-1.6-3.fc22.x86_64) pop up an error dialog saying:

Fatal: Initialization Error: Could not initialize application. The application has not been initialized, for more information execute javaws from the command line. Clicking the Show Details button will show a backtrace similar to the following:

net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize application. The application has not been initialized, for more information execute javaws from the command line.
	at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:813)
	at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:532)
	at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:936)
Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Unknown Main-Class. Could not determine the main class for this application.
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:704)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:285)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(JNLPClassLoader.java:357)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:429)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:403)
	at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:805)
	... 2 more

The problem occurs because the JNLP file that is served by the KVM's web server has an error in it ([...]<application-desc main-class=" com.main.Main">[...]) - the main-class is prefixed with a space thus breaking the parsing when IcedTea reads it.

If you happen to work for ATEN, American Power Conversion (or whoever writes the software for these KVMs) and you happen to come across this comment - please contact me as there are other additional issues I'd like to discuss with you...

Comment 21 Fedora End Of Life 2015-11-04 15:30:47 UTC
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is 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  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

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.

Comment 22 Fedora End Of Life 2015-12-02 03:10:39 UTC
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.