j'ai le fichier JNLP suivant:
<jnlp spec="1.0+" codebase="http://****:****" href="tcm2012.jnlp">
<information>
<title>TCM 2012</title>
<vendor>Drift og Performance, *** Servicecenter</vendor>
<homepage href="http://******"/>
<description/>
</information>
<security>
<all-permissions/>
</security>
<resources>
<j2se version="1.6+"/>
<jar href="tcm2012.jar"/>
</resources>
<application-desc main-class="com.****.kundeservice.TCMApplication"/>
</jnlp>
Maintenant, quand j'essaye de me lancer sur le Web, j'obtiens l'erreur suivante:
Found unsigned entry in resource
Avec l’exception suivante
com.Sun.deploy.net.JARSigningException: Found unsigned entry in resource: http://*****:****/tcm2012.jar
at com.Sun.javaws.security.SigningInfo.getCommonCodeSignersForJar(Unknown Source)
at com.Sun.javaws.security.SigningInfo.check(Unknown Source)
at com.Sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResourcesHelper(Unknown Source)
at com.Sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResources(Unknown Source)
at com.Sun.javaws.Launcher.prepareResources(Unknown Source)
at com.Sun.javaws.Launcher.prepareAllResources(Unknown Source)
at com.Sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.Sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.Sun.javaws.Launcher.launch(Unknown Source)
at com.Sun.javaws.Main.launchApp(Unknown Source)
at com.Sun.javaws.Main.continueInSecureThread(Unknown Source)
at com.Sun.javaws.Main.access$000(Unknown Source)
at com.Sun.javaws.Main$1.run(Unknown Source)
at Java.lang.Thread.run(Unknown Source)
Est-ce que quelqu'un sait comment résoudre ce problème?
Cela a fonctionné pour moi:
Allez dans le Panneau de configuration/Java.
Cliquez ensuite sur le bouton «Paramètres» et activez l'option «Conserver les fichiers temporaires sur mon ordinateur».
C’est bizarre, mais ça a marché!
Le problème peut également se produire avec les anciennes versions Java si vous vous connectez avec une version plus récente de Java.
Il semble y avoir un changement incompatible dans l’algorithme de signe.
J'ai eu un problème similaire avec mes applications.
J'ai une application Java Swing déployée avec javaws:
J'ai vérifié tous les fichiers, MANIFEST.MF, etc. et tout allait bien ..__ Enfin, j'ai découvert que j'avais utilisé un nouveau point de terminaison TSA pour signer mes fichiers.
Depuis cette ressource http://docs.Oracle.com/javase/7/docs/technotes/tools/windows/jarsigner.html J'ai lu Pour générer l'horodatage, jarsigner communique avec le TSA. avec le protocole d'horodatage (TSP) défini dans la RFC 3161. En cas de succès, le jeton d'horodatage renvoyé par la TSA est stocké avec la signature dans le fichier de bloc de signature.
Quelqu'un peut donner plus de perspicacité sur ce problème? En particulier, je ne veux pas être obligé d'utiliser un TSA particulier ... Pourquoi y a-t-il des différences entre TSA? Merci
J'ai eu le même problème lors de la compilation sur mon linux maschine (avec JDK 6 U45) . Mais j'ai eu cette erreur seulement lorsque j'ai aussi essayé de démarrer l'application signée avec Java 6 U45.
Lorsque j’essaie de démarrer l’application avec une plus récente Java-Version (par exemple, Java 8), tout était en ordre, sans message d’erreur.
Lorsque j'ai utilisé un maschine windows _ pour compiler le projet (également avec 6 Update 45), cela fonctionne étrangement aussi lorsque j'utilise Java 6 U45 pour démarrer.
Juste mes 2 cents .... À la vôtre!
Dans mon cas l'applet avait vraiment une entrée non signée dans le dossier META-INF. ) Une façon de résoudre ce problème serait de le signer à nouveau . Mais en Java 8, les applets autosignées étaient rétrogradées presque au même niveau que celles non signées. Et l'applet ne nécessitait pas de privilèges supplémentaires . Il suffisait donc simplement de annuler la signature elle et ajouter à la liste des sites de confiance .