Chargement d'un fichier par rapport à l'exécution de fichier jar

La question, dit-il.

La spécialité dans mon cas, c'est que le répertoire de travail actuel n'est pas l'emplacement du fichier jar, mais c:\Windows\system32 (Mon fichier jar est lancé par windows à l'aide du clic droit menu, je veux passer un chemin d'accès au dossier en tant que paramètre à la jarre).

Maintenant je veux charger un fichier de configuration appelé config.xml qui est dans le même dossier que le pot. Le but de ce fichier est, bien sûr, de fournir des paramètres pour le pot. Il est important pour moi que le fichier xml est à l'extérieur du fichier jar pour l'édition facile.

Je vais avoir un moment difficile de charger ce fichier. Windows s'exécute la ligne

cmd /k java -jar D:\pathToJarfile\unpacker-0.0.1-SNAPSHOT-jar-with-dependencies.jar

Appelant le tout avec cmd /k feuilles de l'invite de commande windows ouvrir afin que je puisse voir le pot de sortie.

Je ne peux pas utiliser new File(".") ou System.getProperty("user.dir") pour le chemin relatif de ces fonctions renvoient C:\Windows\system32\. et C:\Windows\system32, respectivement (qui est le dossier de travail pour tout ce que windows exécute autant que je sache).

Je n'ai eu aucun succès avec Launcher.class.getResourceAsStream("/../config.xml"). Depuis que le chemin commence par /, la recherche commence au nœud racine de la jarre. Va ../config.xml point exactement à ce fichier, mais les retours d'appel null.

Quelqu'un peut me pointer dans la bonne direction? Je suis vraiment coincé ici. Ce fichier de chargement des trucs vraiment m'énerve à chaque fois...

Exigences par moi-même:

Je ne veux pas coder en dur le chemin d'accès dans le code source java
Je ne veux pas passer le chemin d'accès du fichier comme paramètre à la java -jar appel (ni en tant que paramètre à la main(String[] args) ni l'utilisation de -Dpath=d:\... pour définir un système de propriété)

En plus le problème d'origine, j'ai eu beaucoup de mal à avoir maven2 place Class-Path: . dans le MANIFEST.MF (La solution que BalusC posté) lors de l'utilisation de jar-with-dependencies.
Le problème est que la ligne est apparu dans l'ordinaire de jar fichier de MANIFESTE, mais pas le jar-with-dependencies.jar'fichier MANIFEST (2 fichiers jar sont générées).
Pour quelqu'un qui se soucie de la façon dont je l'ai fait:

<plugin>
    <artifactId>maven-assembly-plugin</artifactId>
    <version>2.2-beta-5</version>
    <configuration>
      <archive>
        <manifest>
          <mainClass>${mainClass}</mainClass>
          <addClasspath>true</addClasspath>
          <!--at first, i tried to place the Class-Path entry
              right here using <manifestEntries>. see below -->
        </manifest>
      </archive>
      <descriptorRefs>
        <descriptorRef>jar-with-dependencies</descriptorRef>
      </descriptorRefs>
    </configuration>
    <executions>
      <execution>
        <goals>
          <goal>attached</goal>
        </goals>
        <phase>package</phase>
        <configuration>
          <descriptorRefs>
            <descriptorRef>jar-with-dependencies</descriptorRef>
          </descriptorRefs>
          <archive>
            <manifest>
              <mainClass>${mainClass}</mainClass>
            </manifest>
            <!--this is the correct placement -->
            <manifestEntries>
              <Class-Path>.</Class-Path>
            </manifestEntries>
          </archive>
        </configuration>
      </execution>
    </executions>
  </plugin>

OriginalL'auteur f1sh | 2010-09-02

6

Pour obtenir Launcher.class.getResourceAsStream("/../config.xml") de travail, vous devez ajouter le chemin d'accès à la Class-Path entrée du POT de MANIFEST.MF fichier. C'est la pratique normale.

des sons plus joli 🙂
Dois-je placer le chemin d'accès absolu dans le MANIFEST.MF ou ne .. suffit-il? Ce dernier serait souhaitable. Désolé pour demander au lieu d'essayer, je n'ai pas mon IDE à cette machine.
Non, le chemin relatif vers le fichier JAR de lui-même. Si vous voulez avoir la config.xml dans le même dossier que le fichier JAR de lui-même, puis Class-Path: . suffit (n'oubliez pas d'ajouter une ligne vide à la fin de MANIFEST.MF!). Ensuite, vous pouvez obtenir le config.xml par getResourceAsStream("config.xml"). Garder les choses simples 🙂
C'est une très belle approche, mais je ne peux pas le faire fonctionner. La raison en est le maven assembly plugin qui génère le jar-with-dependencies. Dans l'ordinaire .fichier jar, mon MANIFEST.MF est de la mettre dans le pot correctement, mais le jar-with-dependencies fichier n'utilise pas le manifeste que j'ai précisé :-/ est-ce que quelqu'un connais une solution rapide à cette situation?
Désolé, je n'ai pas utiliser Maven, donc je ne peux pas aller dans le détail. Vous devez spécifier au moins quelque part un supplément de dépendance chemin pour être inclus dans le classpath. Par ailleurs, une correction pour le commentaire précédent, si le Launcher classe elle-même est dans un autre package, vous devriez avoir utilisé "/config.xml" comme le nom de la ressource. Sinon, il est à la recherche par rapport à l'emplacement de Launcher classe (à l'intérieur du POT).

OriginalL'auteur BalusC

Voici une solution possible à l'aide de Classe.getProtectionDomain():

final Class<?> referenceClass = YourMainClass.class;
final URL url =
    referenceClass.getProtectionDomain().getCodeSource().getLocation();

try{
    final File jarPath = new File(url.toURI()).getParentFile();
    System.out.println(jarPath); //this is the path you want 
} catch(final URISyntaxException e){
    //etc.
}

YourMainClass peut être remplacé par n'importe quelle classe dans votre bocal.

De la Classe.getProtectionDomain() docs:

Returns the ProtectionDomain of this class.
If there is a security manager installed, this method first calls
the security manager's checkPermission method with a
RuntimePermission("getProtectionDomain") permission to ensure it's
ok to get the ProtectionDomain.

Returns:
  the ProtectionDomain of this class
Throws:
  SecurityException - if a security manager exists and its
  checkPermission method doesn't allow getting the ProtectionDomain.

C'est vraiment agréable de savoir dans le cas où j'aurai besoin le chemin d'accès dans le code. Actuellement je n'en ai pas, donc je vais essayer d'utiliser BalusC de réponse.

OriginalL'auteur Sean Patrick Floyd

Vous devez vous connecter pour publier un commentaire.