Install4j: programme d'installation Windows affichant java.lang.LinkageError: ClassCastException

Question

Je génère le programme d'installation pour les systèmes Windows et Linux. Après l'écran d'accueil, j'ai un composant CustomForm où je prends les détails de l'utilisateur et les envoie ensuite à un serveur en utilisant javax.ws.rs.client.ClientBuilder. Mais dans Windows, lorsque my Class tente de générer le client à partir de ClientBuilder, le programme d'installation affiche java.lang.LinkageError: ClassCastException. est indiqué dans le journal tout ci-dessous:

java.lang.LinkageError: ClassCastException: attempting to cast 
jar:file:/C:/Users/lutful.kabir/AppData/Local/Temp/e4j363A.tmp_dir1460795758/user/javaee-api-7.0.jar!/javax/ws/rs/client/ClientBuilder.class to 
jar:file:/C:/Users/lutful.kabir/AppData/Local/Temp/e4j363A.tmp_dir1460795758/user/javaee-api-7.0.jar!/javax/ws/rs/client/ClientBuilder.class 
at javax.ws.rs.client.ClientBuilder.newBuilder(ClientBuilder.java:97) 
at javax.ws.rs.client.ClientBuilder.newClient(ClientBuilder.java:114) 
at install4j.AuthorizationHandler.verifyAuthorization(AuthorizationHandler.java:21) 
at install4j.backendsetup.VerifyBackend.install(VerifyBackend.java:27) 
at com.install4j.runtime.installer.InstallerContextImpl$2.fetchValue(InstallerContextImpl.java:167) 
at com.install4j.runtime.installer.InstallerContextImpl$2.fetchValue(InstallerContextImpl.java:164) 
at com.install4j.runtime.installer.helper.comm.actions.FetchObjectAction.execute(FetchObjectAction.java:14) 
at com.install4j.runtime.installer.helper.comm.HelperCommunication.executeActionDirect(HelperCommunication.java:272) 
at com.install4j.runtime.installer.helper.comm.HelperCommunication.executeActionInt(HelperCommunication.java:247) 
at com.install4j.runtime.installer.helper.comm.HelperCommunication.executeActionChecked(HelperCommunication.java:185) 
at com.install4j.runtime.installer.helper.comm.HelperCommunication.fetchObjectChecked(HelperCommunication.java:168) 
at com.install4j.runtime.installer.InstallerContextImpl.performActionIntStatic(InstallerContextImpl.java:164) 
at com.install4j.runtime.installer.InstallerContextImpl.performActionInt(InstallerContextImpl.java:152) 
at com.install4j.runtime.installer.ContextImpl.performAction(ContextImpl.java:1099) 
at com.install4j.runtime.installer.controller.Controller.executeAction(Controller.java:367) 
at com.install4j.runtime.installer.controller.Controller.executeActions(Controller.java:333) 
at com.install4j.runtime.installer.controller.Controller.handleCommand(Controller.java:194) 
at com.install4j.runtime.installer.controller.Controller.start(Controller.java:94) 
at com.install4j.runtime.installer.Installer.runInProcess(Installer.java:59) 
at com.install4j.runtime.installer.Installer.main(Installer.java:46) 
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) 
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
at java.lang.reflect.Method.invoke(Method.java:606) 
at com.exe4j.runtime.LauncherEngine.launch(LauncherEngine.java:62) 
at com.exe4j.runtime.WinLauncher.main(WinLauncher.java:101) 
at com.install4j.runtime.launcher.WinLauncher.main(WinLauncher.java:26) 

Le code AuthorizationHandler suit:

package install4j; 

import java.net.ConnectException; 

import javax.ws.rs.client.Client; 
import javax.ws.rs.client.ClientBuilder; 
import javax.ws.rs.client.Invocation; 
import javax.ws.rs.client.Invocation.Builder; 
import javax.ws.rs.client.WebTarget; 
import javax.ws.rs.core.MediaType; 
import javax.ws.rs.core.Response; 

import com.install4j.api.Util; 
import com.install4j.api.context.InstallerContext; 

import installerconfigparams.utils.InstallerParameter; 

public class AuthorizationHandler { 

    public static boolean verifyAuthorization(String authToken, InstallerContext context) throws ConnectException { 
     Client client = ClientBuilder.newClient(); 
     WebTarget target = client.target(InstallerParameter.CENTRAL_SERVER_URL.getStringValue()) 
       .path(InstallerParameter.PATH_BACKEND_VERIFICATION.getStringValue()); 
     Builder builder = target.request(MediaType.APPLICATION_JSON); 
     builder.header(InstallerParameter.AUTHORIZATION_HEADER.getStringValue(), authToken); 
     Invocation invocation = builder.buildGet(); 
     Response response; 
     response = invocation.invoke(); 
     response.getStringHeaders(); 
     int status = response.getStatus(); 
     if (InstallerParameter.HTTP_200.getIntValue() != status) { 
      String args = response.getHeaderString("error"); 
      Util.showErrorMessage(context.getMessage("installer.backend.login.invalid") + args); 
      return false; 
     } 
     Util.showMessage(context.getMessage("installer.backend.login.successful")); 
     return true; 
    } 

Maintenant, en ce que je sais et après mes recherches sur Internet, cela peut se produire quand il pourrait y avoir des ressources en double (à partir du journal, vous pouvez également voir que les classes ClientBuilder qu'il utilise proviennent également de chemins identiques). Je me suis assuré qu'il n'y a pas de doublons ajoutés afin que l'installateur puisse le confondre. Je ne connais pas très bien ClassLoaders ni comment cela fonctionne pour Install4j. J'ai également essayé d'utiliser l'action Run Script, en écrivant les codes directement là, mais j'ai fini par avoir la même exception.

J'ai utilisé les mêmes classes et méthodes depuis que j'ai construit l'installateur. Et n'a eu aucun problème jusqu'à aujourd'hui. J'ai même vérifié à mon ancien Commit avant que je fasse face à ce problème. Mais le résultat est le même. Et ce problème se produit uniquement pour le programme d'installation dans Windows. JAX-WS utilise le chargeur de classe de contexte pour certaines opérations.

Answer 1

Appel

Thread.currentThread().setContextClassLoader(getClass().getClassLoader()); 

définit la classe de contexte chargeur au même chargeur de classes qui charge le script, qui est différent du chargeur de classe système depuis install4j 6.1. À partir de la version 6.1.2 de install4j, le chargeur de classe de contexte sera ajusté automatiquement afin que la solution de contournement ci-dessus ne soit plus nécessaire.