Récemment, deux de nos clients ont signalé des problèmes avec nos applets. En regardant la console de plug-in Java, elle est pleine de classesNotFoundException pour que rien de notre code n'est exécuté.
J'ai été capable de reproduire la trace de la pile à l'aide d'une image PC virtuelle avec 0 espace libre sur le disque, mais le problème disparaît car je restaure un espace disque et que les utilisateurs me disent que leur disque n'est pas plein; ils sont capables de créer de nouveaux fichiers.
Notre applet nécessite Java 6 et le problème est apparu avec des mises à jour 1, 10 et 14 de la JRE. Nous avons également essayé différents navigateurs (c.-à-d. Firefox), nettoyer le navigateur et les caches Java, ...
Comment puis-je déboguer ou suivre ce que le JVM fait pour charger notre applet?
Je suppose que le problème réside sur une directive de sécurité sur Windows, de sorte que j'utilise le moniteur de processus de Sysinternal pour enregistrer l'activité, mais je ne sais pas vraiment où regarder.
4 Réponses :
Le cache Java est très probablement gâché. Ouvrez Java dans le panneau de commande et éliminez tous les fichiers temporaires pour voir si elle s'en va.
La journalisation dans la console Java pour chargement des applets peut être activée qui aide tout à fait beaucoup (même si le plugin est extrêmement cryptique). Voir http: //java.sun. Com / Javase / 6 / Documents / Technotes / Guides / Déploiement / Déploiement-Guide / Tracing_logging.html
Merci! J'ai oublié d'activer la traçage sur mon environnement de test complet de mon disque. Maintenant, je l'ai essayé, mais cela ne montre que "Java.IO.IOException: erreur d'écriture". Il n'y a pas de détail de quel chemin essayait d'écrire ou de la cause de l'erreur, alors je pense que cela ne donnera pas suffisamment d'informations si nous permettrons à la traçabilité du PC client. Est-ce que cela traçait le maximum que nous pouvons obtenir de la JVM?
A nettoyé le cache Java aide vos utilisateurs?
Non. Nous avons déjà essayé de nettoyer le cache Java à partir du panneau de commande Java et de la suppression de tous les fichiers JAR_Cache * .TMP à partir du répertoire TEMP. Je suppose que c'est une directive sur la sécurité des fenêtres ou du réseau, mais je ne sais pas où continuer, alors j'essaie d'obtenir un journal détaillé de ce qui se passe.
Si vous avez affaire à des fichiers JAR signés (pour sortir du bac à sable), la chaîne de certificate peut être brisée. J'ai parcouru le code JnLP Launcher récemment et tout ce que vous pouvez obtenir sur la console Java doit avoir été explicitement codé dans le lanceur. Je ne connais pas le nouveau plugin du navigateur. Je suggérerais d'obtenir le code source du plugin que vous utilisez et d'apprendre exactement à quoi la sortie de journalisation que vous voyez. Remarque: OpenJDK ne fera pas, car ces composants ne sont pas sous GPL.
Je regarde la source du plugin depuis la JDK et j'ai constaté que des informations de débogage supplémentaires sont disponibles dans les journaux définissant la variable d'environnement J'ai trouvé un morceau du code du plug-in qui avale toutes les exceptions, alors peut-être que mon problème d'utilisateurs est là ... jpi_plugin2_debug .
Malheureusement, je ne vois toujours que classnotfound Exceptions.
eu des problèmes similaires il y a quelque temps. Dans notre cas, le problème semble être de la manière dont la balise d'applet est configurée sur la page Web. Si c'est dans un mauvais ordre ou contient l'attribut codebase code>, il échoue avec 6U10 +. Cela fonctionne pour nous: <applet name="DMGANTT" archive="DMGantt.zip" code="dm.applet.DMGanttApplet"
width='100%' height='100%' mayscript="mayscript">
J'utilise le script DeployJava.js pour écrire les balises d'applet et nous n'ajoutons pas l'attribut de codeBase. Comment les attributs peuvent-ils être dans le mauvais ordre? Avez-vous un exemple qui échoue à cause de l'ordre de port?
Oui, si je modifie l'ordre du code et des archives, 6U10 recherche le DMGantTApplet sur le serveur et non dans l'archive fournie. Quelles classes manquent - quelle est la trace de votre erreur de votre erreur?
J'ai essayé votre suggestion avec l'ordre des attributs, mais le problème persiste. La classe introuvable dans la trace de la pile est celle qui est spécifiée dans l'attribut de code, alors rien n'est exécuté. Je peux voir dans le journal du serveur que le pot avec les classes est demandé. En fait, le pot est demandé autant de fois que les applets que les applets se trouvent dans la page, mais lors de la visualisation de la page à partir d'un PC qui fonctionne, il est seulement demandé une fois.
@ KD304: Juste pour la curiosité, avez-vous utilisé ou essayé le paramètre de codeBase_Lookup? Java.sun.com/javase/ 6 / DOCS / TECHNOTES / GUIDES / PLUGIN / ... Tous nos applets fonctionnent avec ce paramètre défini sur true, donc si le plugin ne peut pas trouver une classe ou une ressource, il ne demande pas le serveur.
Non, puisque la réorganisation de l'attribut et la suppression du paramètre de codeBase suffisait pour que les choses soient de nouveau fonctionner.
Eh bien, j'ai évoqué certaines de vos autres réponses et de vos questions pour vous remercier de votre aide. Je ne trouve pas correct pour upvote cette réponse particulière car elle n'a pas vraiment contribué à résoudre mon problème. Merci.
@Serhii: Merci, je suis désolé de ne pas pouvoir m'empêcher. Il y a tellement de choses qui peuvent mal tourner avec le navigateur-Java, par exemple. L'acompte endommagée d'une mise à jour, d'un mauvais registre, etc. Vous pouvez également essayer d'exécuter votre applet dans Eclipse avec le mode de débogage et vérifiez si cela fonctionne.
Nous avons eu un problème similaire avec l'un de nos clients. Nous avons découvert que c'était un bogue étrange dans certaines versions de Java liées à la configuration proxy sur le client. Voir cet article pour les détails
http://bugs.sun.com/bugdatabase/view_bug.do ? bug_id = 6723715
En outre, notre applet a échoué avec de nouvelles versions pour une raison différente.
Maintenant, dans des cas similaires, je leur demande de vérifier Javatester.org, de sorte que je puisse voir si des applets (en général) chargent OK dans leur navigateur. Si cette page charge OK, c'est un problème sur notre applet (ou notre page). Sinon c'est un problème dans leur configuration. Je les aide quand même, mais il est plus facile de déboguer.