Izpack échoue avec 'There is no script engine for file extension ".js",

Question

Sur la machine de test utilisant Izpack 5 Beta 11, si je lance install.jar à l'aide d'un exe winrun4j 64 bits exécutant le java 64 bits intégré, Izpack se plaint de ce qui suit

There is no script engine for file extension ".js" , puis se plaint The installer could not launch with administrator permissions , puis une tentative d'installation dans le répertoire d'installation par défaut échoue parce que vous n'avez pas les droits d'administrateur, l'installation dans un autre dossier en dehors de C:/Program Files se déroule correctement.

Alors que si je l'exécute avec le programme d'installation winrun4j 32 bits utilisant java 32 bits, cela fonctionne bien.

si je lance directement install.jar sans le wrapper exe.

i.e. java -jar install.jar

Ces erreurs se produisent aussi bien avec une JVM 32 bits qu'avec une JVM 64 bits.

donc la seule solution qui fonctionne pour le moment est l'installation avec un wrapper exe 32bit, mais j'ai aussi besoin d'un wrapper 64 bit.

Les questions sont donc

1. Pourquoi l'exe 32 bits fonctionne-t-il et l'exe 64 bits ne fonctionne-t-il pas ?
2. Pourquoi ni 32bit ni 64bit si j'essaie d'installer sans le wrapper.

Suivi

J'ai trouvé ce fil à propos de l'erreur javascript (mais pas Izpack) et a découvert que les fichiers .js étaient associés à Utlradedit, l'éditeur que j'utilise pour modifier la plupart des types de fichiers.

Le simple fait de dissocier .js de Ultraedit signifie que maintenant, lorsque j'exécute

• java -jar install.jar en utilisant java 32bit sur 32bit install.jar
• java -jar install.jar en utilisant java 64bit sur 64bit install.jar
• wrapper winrun4j 32 bits.

cela fonctionne maintenant :)

Mais winrun4j 64bit ne démarre pas l'installation et ne fonctionne pas du tout, si je l'exécute à partir de la fenêtre de commande, je peux voir qu'au lieu de cela

de la course

wscript C:\Users\MESH\AppData\Local\Temp\Installer.js 
 c:\Code\WidgetReleases\1.0_Beta_2\widget-windows64\JVM64\bin\javaw.exe 
 -Dizpack.mode=privileged -jar 
C:\Code\WidgetReleases\1.0_Beta_2\widget-windows64\install.jar

ils ont couru

wscript C:\Users\MESH\AppData\Local\Temp\Installer.js 
 c:\Code\WidgetReleases\1.0_Beta_2\widget-windows64\JVM64\bin\javaw.exe 
 abort exit 
 -Dizpack.mode=privileged -jar 
 :\Code\WidgetReleases\1.0_Beta_2\widget-windows64\install.jar

Les questions à suivre sont donc :

1. Pourquoi le simple fait d'associer le type de fichier à un éditeur casse-t-il ce truc javascript ? Je peux imaginer que ce problème ou un problème similaire pourrait affecter beaucoup d'utilisateurs.
2. Pourquoi l'exécution à partir de mon wrapper 64 bits entraîne l'exécution d'Abort Exit dans le fichier installer.js ?

Answer 1

Quatre questions sont posées ici :

1. Pourquoi l'exe 32 bits fonctionne-t-il et l'exe 64 bits ne fonctionne-t-il pas ?
2. Pourquoi ni 32bit ni 64bit si j'essaie d'installer sans le wrapper.
3. Pourquoi le simple fait d'associer le type de fichier à un éditeur casse-t-il ce truc javascript ? Je peux imaginer que ce problème ou un problème similaire pourrait affecter beaucoup d'utilisateurs.
4. Pourquoi l'exécution à partir de mon wrapper 64 bits entraîne l'exécution d'Abort Exit dans le fichier installer.js ?

Je vais tenter d'y répondre :

1. Des erreurs et des bogues se produisent parfois dans des programmes qui sont censés gérer de manière transparente les systèmes 32 et 64 bits. Le programme de réparation des définitions SEP de Symantec en est un exemple : il fonctionne parfois, mais pas toujours. Votre commentaire confirme ces bugs, et vous avez même identifié un programme concurrent qui n'a pas d'erreur dans cette gestion 32/64 : "Je n'ai pas résolu ce problème, mais je l'ai contourné en exécutant le programme d'installation à l'aide de launch4j au lieu de winrun4j ". Félicitations ! :)

2. Je soupçonne que l'application/wrapper requis n'est pas dans le PATH de votre système. Deux dossiers dans votre chemin sont C:\WINDOWS y C:\WINDOWS\SYSTEM32. À l'invite de commande, tapez le mot SET (capsules non nécessaires). Une liste de variables classées par ordre alphabétique apparaît. Dans celle qui dit PATH=, cherchez le chemin complet du dossier du wrapper qui doit lancer votre application. Il n'est probablement pas là. Vous pouvez l'ajouter si vous le souhaitez.

3. Bonne question, mais il y a une bonne raison : en associant un type de fichier à ouvrir avec un programme, vous dites à votre ordinateur de toujours ouvrir le fichier, dans ce cas se terminant par .js, avec un éditeur de fichiers. Il fait ce que vous lui avez dit de faire, et non ce que vous prévu . Un moyen populaire d'obtenir ce que vous prévu est de ré-associer le fichier avec le programme qu'il avait avant (vous sauriez probablement lequel est le meilleur), et de modifier le fichier, ajoutez votre éditeur JS préféré à l'option "Ouvrir avec..." du menu contextuel de l'Explorateur Windows. Je peux trouver et lier une ou deux pages sur la façon de faire cela, si vous le souhaitez.

4. Je pense que cela est fortement lié à la question et à la réponse n°1.

Faites-moi savoir si cela vous aide.

Answer 2

La modification de l'action par défaut pour les fichiers .js pose des problèmes pour la même raison que la modification de l'action par défaut pour les fichiers .exe. Les programmes s'attendent à ce que l'action par défaut d'un autre programme soit de l'exécuter. L'édition devrait toujours être une action par clic droit et non l'action par défaut.