Can you post the jar by any chance?

From the looks of it, you have a jar where not all the entries are allowed. Such jars are no longer allowed as they leave the door open for potential security issues.

I can't post it publicly if you have another way for me to get it to you (about 1 MB).  Does the verbose jarsigner output I've attached help at all?

Created attachment 477461 [details]
jarsigner -verify -verbose sinetfactory.jar

Can you grab the packages from http://omajid.fedorapeople.org/java-1.6.0-openjdk/ and check if they fix the problem?

yes, now the applet and app both run again

This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  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 WONTFIX if it remains open with a Fedora 
'version' of '13'.

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 prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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

still an issue with java-1.6.0-openjdk-1.6.0.0-57.1.10.1.fc15.x86_64

*** Bug 738811 has been marked as a duplicate of this bug. ***

The "fix" used to produce packages noted in comment 4 was discussed upstream:
http://thread.gmane.org/gmane.comp.java.openjdk.distro-packaging.devel/12020

(oops, I added this to Bug 738811 - I guess I should say it here too.
Although the context may be important.)

I was wondering whether replacing that jar with a more recent version would
help.
I just tried the latest version (5.1.17) and I seem to still get the same
thing.
Can you verify that the new jar has the same problem?
I now realize that this particular url, using ids driver, does not even need
the mysql driver.  When I remove the jar from the list it works!
However, I would then expect the same problem to affect the other url which
does use the mysql driver.  And yet that one gets much further -- why is that?

BTW,
Doesn't this seem the sort of thing that mysql (now oracle!) really should fix?
Or is it possible that all other java implementation accept unsigned index
files?

Finally
The fix above seems to require changing my java distribution, which means that
the applet still would not work for others using the standard dist, right?
I was hoping that I could at least arrange to sign the unsigned entry and then
have that new jar work for everyone.

Created attachment 533940 [details]
.JAR file which causes the problem reported in this issue too

While trying to use following application:

http://semweb.salzburgresearch.at/apps/rdf-gravity/jws/rdf-gravity.jnlp

same problem occured to me:

net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize application.
	at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:659)
	at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:436)
	at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:830)
Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Application Error: Cannot grant permissions to unsigned jars.
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.setSecurity(JNLPClassLoader.java:251)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:171)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:283)
	at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:650)
	... 2 more
Caused by: 
net.sourceforge.jnlp.LaunchException: Fatal: Application Error: Cannot grant permissions to unsigned jars.
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.setSecurity(JNLPClassLoader.java:251)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:171)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:283)
	at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:650)
	at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:436)
	at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:830)


System details:

$ uname -r
2.6.40.6-0.fc15.x86_64
$ java -version
java version "1.6.0_22"
OpenJDK Runtime Environment (IcedTea6 1.10.4) (fedora-60.1.10.4.fc15-x86_64)
OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)

This is still a problem in F17. Specifically, the target service which fails is Dell's idrac.

(In reply to comment #12)
I can confirm this.

(In reply to comment #14)
> (In reply to comment #12)
> I can confirm this.

Just encountered this with some Dell machines, too.

(In reply to comment #15)
> (In reply to comment #14)
> > (In reply to comment #12)
> > I can confirm this.
> Just encountered this with some Dell machines, too.

One more confirmation here, iDRAC6 firmware 1.70 (Build 21).

Confirmed with java-1.7.0-openjdk-1.7.0.3-2.2.1.fc17.8.x86_64 on Dell iDRAC6.

Seeing this with SuperMicro IPMI console application and java-1.7.0-openjdk-1.7.0.5-2.2.1.fc17.9.i686.

This problem is affecting the Fedora system management with the IBM built in console applications

java-1.7.0-openjdk.i686                  1:1.7.0.5-2.2.1.fc17.9         @updates
java-1.7.0-openjdk.x86_64                1:1.7.0.5-2.2.1.fc17.9         @updates

Some sort of work around would be nice ;).

A workaround (which I use as I need to work with a lot of DRACs at my day job) is to uninstall the IcedTea plugin RPM, download the JDK RPM from Oracle and install. Then symlink the provided .so plugin into your Firefox, e.g.:

# ln -s /usr/java/jdk1.7.0_05/jre/lib/amd64/libnpjp2.so /usr/lib64/mozilla/plugins/libnpjp2.so

The DRACs work fine with the official RPM from Oracle - this bug's been open for almost a year and a half. :(

Icedtea-web, which is replacement of openjdk-plugin have been heavily enhanced in last year. I would like to test your DRAc issues on head and soon to be released 1.3
Second reproducer mentioned here works fine with 1.3.

I have tried comment #13, but I was unable to loggin.

for f17 - there have been spotted regressions due to jdk7 - eg.: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=843

Confirm same problem with all iDRAC6 versions I've used, both with Chrome and Firefox.  I'm on Fedora17, latest errata applied.

Versions:
java-1.7.0-openjdk-1.7.0.5-2.2.1.fc17.9.x86_64
icedtea-web-1.2-2.fc17.x86_64

Error message I get:
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize application. 
	at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:778)
	at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:552)
	at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:889)
Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Application Error: Cannot grant permissions to unsigned jars. Application requested security permissions, but jars are not signed.
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.setSecurity(JNLPClassLoader.java:283)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:203)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:317)
	at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:770)
	... 2 more
Caused by: 
net.sourceforge.jnlp.LaunchException: Fatal: Application Error: Cannot grant permissions to unsigned jars. Application requested security permissions, but jars are not signed.
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.setSecurity(JNLPClassLoader.java:283)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:203)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:317)
	at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:770)
	at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:552)
	at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:889)

You pretty much can't use a KVM until this bug is fixed, since they rely on JNLP for remote console viewing. 18 months and counting...

I also note that invoking

javaws -nosecurity launch.jnlp

seems to have no effect - whatever "-nosecurity" does, it's not related to jar signing exceptions. Sigh...

This is the same issue as the one seen in 753960.

Sorry about this, it is only evident with JDK7 and happens when a certificate presented by an https site has a different domain name associated with it than the actual domain. We are working on a fix right now but it is rather complex due to the changes that JDK7 introduced :(

*** This bug has been marked as a duplicate of bug 753960 ***

Hoping to see a solution soon as I'm beginning to work with new Dell Servers (R720) and iDRAC7 (fw 1.20.20) and I see the same problem.
In my case:
Fedora 17 and icedtea-web-1.2-2.fc17.x86_64

Thanks in advance,
Gianluca

Confirming again, This is still open with 
  icedtea-web-1.3-1.fc17.x86_64 
and 
  java-1.7.0-openjdk-1.7.0.9-2.3.3.fc17.1.x86_64

net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize application. 
	at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:778)
	at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:552)
	at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:889)
Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Application Error: Cannot grant permissions to unsigned jars. Application requested security permissions, but jars are not signed.
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.setSecurity(JNLPClassLoader.java:312)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:232)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:357)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:330)
	at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:770)
	... 2 more

Hi Colin,

Can you please try the RPMS here?

http://people.redhat.com/dbhole/fedora/icedtea-web/