JAVAFX: l'Emplacement n'est pas défini d'erreur
Mon projet fonctionne correctement dans eclipse mais lorsque je crée un fichier jar de ce projet et d'essayer de le lancer par un cmd il est montrant l'Emplacement n'est pas défini" erreur.
Mon projet structure:
La Méthode est (en cours d'Exécution dans eclipse):
@FXML
private void RegularCustomer(ActionEvent event) throws Exception{
Stage stage = (Stage) dailySales.getScene().getWindow();
Scene scene = dailySales.getScene();
FXMLLoader loader = new FXMLLoader(getClass().getResource("../customer/CustomerHome.fxml"));
System.out.println(loader.getLocation());
scene.setRoot(loader.load());
stage.setScene(scene);
stage.show();
}
Quel est le problème avec ce code?
Il y a une certaine forme de questions, mais elles sont différentes. Leur code n'est pas exécuté dans l'IDE, mais mon code à exécuter dans l'IDE.
Pour info: j'ai apporté quelques modifications dans la structure de dossiers et a été en mesure d'exécuter avec succès. Mais cette structure a été horrible car j'ai mis toutes mes FXML des fichiers et des contrôleurs dans le même package.
Réouverture de la question, plutôt que de le marquer comme un double de JavaFX Emplacement n'est pas définie message d'erreur.
OriginalL'auteur Mr. Dijkstra | 2016-01-12
Vous devez vous connecter pour publier un commentaire.
Lorsque vous utilisez
getClass().getResource(...)
vous êtes le chargement d'une ressource, pas de spécifier un chemin d'accès à un fichier. Dans le cas où la classe loader charge des classes de système de fichiers, ces essentiellement équivaut à la même chose, et il ne fait le travail (même si, même alors, il n'y a pas de raison technique, il a pour). Lorsque le chargeur de classe est le chargement des classes par d'autres mécanismes (et probablement dans tous les cas de toute façon), alors il est important de prêter attention à la Java les spécifications d'une ressource.En particulier, la note de:
(Mon accent.) Depuis
..
n'est pas valide Java identificateur, il n'y a aucune garantie de cette ressource, qui peut être résolu. Il arrive que le système de fichiers du chargeur de classe résout ce dans la façon dont vous vous attendez à ce, qui est pourquoi il fonctionne dans votre IDE, mais la mise en œuvre degetResource(...)
dans le pot chargeur de classe n'est pas mise en œuvre dans la façon dont vous êtes l'espoir.Essayer
À l'aide du contrôleur emplacements pour charger FXML:
Puisque vous avez organisé votre code, de sorte que chaque FXML est dans le même package que son correspondant contrôleur de fichier (qui je pense est un bon moyen de faire des choses), vous pouvez également tirer parti de ce dans le chargement du FXML: il suffit de charger le FXML "par rapport à son contrôleur":
Cela semble assez naturel dans cette configuration, et le compilateur de vérifier que vous avez le nom de package pour
CustomerHomeCtrl
corrects au moment où l'importation de la classe. Il rend également facile à refactoriser: par exemple, supposons que vous vouliez splitsm.admin
en plusieurs sous-paquets. Dans Eclipse, vous créez la sous-paquets, faites glisser et déposez le FXML et des contrôleurs à la appropriée des sous-paquets, et que l'importation des déclarations serait mis à jour automatiquement: il n'y aurait pas d'autres changements nécessaires. Dans le cas où le chemin d'accès spécifié dans legetResource(...)
, tous ceux qui aurait du être changé par la main.Merci beaucoup pour ce super solution. Il fonctionne maintenant parfaitement.
Mise à jour de la réponse à être un peu plus précis. Serais intéressé si cela fait plus de sens?
Bien à mon humble avis, le vrai problème est le système de fichiers, vous opérer. Natif des systèmes de fichiers de support ".." alors que jar-file-systèmes ne sont pas
Je suppose que mon point est qu'il y a un cahier des charges pour combien de ressources naming se comporte qui est indépendant du système de fichiers. Tant que votre nom de la ressource est conforme à cette spécification, il fonctionnera indépendamment de la façon dont l'application est déployée. (En théorie, même si le sous-jacent système de fichiers ont des exigences plus strictes que les ressources de dénomination spec.)
OriginalL'auteur James_D