Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
er kann doch über die system property java.class.path an die verzeichnise und jars im classpath kommen. so sollte das doch gehen *grübl*
ob das sinn macht oder nicht ist ja ne andere sache...
er kann doch über die system property java.class.path an die verzeichnise und jars im classpath kommen. so sollte das doch gehen *grübl*
ob das sinn macht oder nicht ist ja ne andere sache...
1. Es heißt CLASSpath, nicht RESOURCEpath (so als Denkanstoß)
2. Innerhalb meines JARs sollten mir die vorhandenen Dateien bekannt sein, schließlich habe ich sie reingepackt.
Der Classpath ist eine Liste von Verzeichnissen und JARs, in denen benötigte Class-Dateien rumlungern. Relativ zu einer Class-Dateien kann ich mittels ClassLoader auch Resourcen laden. Macht ja auch Sinn.
Weniger Sinn macht es wild im Classpath Resourcen reinzupfeffern und dann rumsuchen zu müssen. Im Falle der Teilpfade zum JRE verbietet sich das einfach. Im Falle von Pfaden die auf JARs zeigen greift Punkt 2 meines obigen Posts.
Es läuft immer darauf hinaus:
1. Sind es meine Dateien, muss ich eh wissen wo sie sind und wie sie heißen.
2. Woanders im Classpath haben Resourcen nichts zu suchen, also brauche ich da auch nicht suchen.
Vielleicht kommt noch jemand auf die krude Idee seine Bilder in einen Ordner zu legen und diesen dann dem Classpath hinzuzufügen, damit er dann in seiner Anwendung.. nein ich möchte gar nicht weiter drüber nachdenken!
es ist durchaus legitim, z.B. Icons in JAR-Archive zu packen (such mal in den Java-SDK-JARs nach *.gif und *.png ). Will ich jetzt z.B. eine Toolbar vom Nutzer konfigurieren lassen so mit Bildchen und so, steht ich *bumm* genau vor dem gleichen Problem, welches Franz hat.
Aber ich stimme dir zu, es gibt sicher genug Fälle, wo diese Vorgehensweise absolut verkehrt ist.
es ist durchaus legitim, z.B. Icons in JAR-Archive zu packen (such mal in den Java-SDK-JARs nach *.gif und *.png ). Will ich jetzt z.B. eine Toolbar vom Nutzer konfigurieren lassen so mit Bildchen und so, steht ich *bumm* genau vor dem gleichen Problem, welches Franz hat.
Hab ich ja auch geschrieben und handhabe ich ja auch so. Allerdings schrieb ich auch, dass ich dann weiß wo welche Datei sitzt (Pfad im JAR), sprich, ich muss mich in meinem eigenen JAR doch nicht über den Classpath und Wildcards an meine Resourcen ranrobben. Es sei denn ich habe das Teil mal im Vollrausch programmiert...
zunächst Mal vielen Dank für eure Bemühungen, doch bisher ist noch keine brauchbare Lösung darunter.
Ich werde mein Problem noch einmal genauer schildern:
Für eine erweiterbare Komponentensoftware soll in einer neutralen Fehlerhandling-
Komponente durch die Übergabe einer Fehlernummer der Klartext ermittelt werden.
Die Zuordnung von Fehlernummer zu Fehlertext steht in einer XML-Datei deren Namen
folgende Konvention erfüllen muss: <Komponentename>_Fehlertexte.xml.
Weiterhin muss die Datei bzw. das JarFile, das die Fehlertexte enthält im
Classpath vorhanden sein.
Da die Komponentensoftware von Dritten beliebig erweiterbar ist, ist der Name der Zuordnungsdatei nicht fix.
Ich weiß nur, dass am Ende des Namens _Fehlertexte.xml steht.
Deshalb wäre eine Suche im Classpath mit dem Filter *_Fehlertexte.xml notwendig.
na kannst du nicht den Komponentennamen ermitteln ? Ich meine, das dürfte doch eine simple Anforderung sein, daß externe Komponenten einen Namen liefern können. Zur Not tuts ja auch der Klassenname.
Dann kannst du nämlich aus Package, Name und Suffix ("_Fehlertexte.xml") einen kompletten Pfad zusammenbauen. Mit getResourceAsStream(String name) kannst du dann gucken, ob es die Datei gibt und sie schlißlich laden.
Da gibts genügend Möglichkeiten, von denen alle wohl besser sind als den CLASSPATH zu durchsuchen.
Ich nehm mal an, dass du ein Interface hast, dass alle Plugins implementieren müssen. Dort könntest du z.B. eine Methode machen
Code:
public String getErrorCode(int errorId);
Dann brauchst du in der Hauptklasse nicht alle Jars die "extern" eingebunden sind zu durchsuchen (!!!!)
So brauchst du auch nicht drauf hoffen, dass jede Person welche ein Plugin schreibt, auch gleich so eine <Komponentenname>_Fehlertexte.xml erstellt, da dass dann jeder Programmierer selbst entscheiden kann.
Für kleine Plugins kannst du die Fehlercodes auch hardcoden, oder du packst sie in ne properties/ini Datei, u.s.w.
Insgesamt bist du so dann wesentlich flexibler.
//Edit: Schwachsinn, ein Interface hält ja nur Methodensignaturen^^
Jetzt hast Du ein Array mit Jar-Dateien und Verzeichnissen, die in Classpath stehen.
Ich gehe mal davon aus, ZIP's und Verzeichnisse kann man hier ignorieren.
Jetzt nur die Jar's durchsuchen
Code:
for(int i=0; i<paths.length; i++) {
if(paths[i].length()>2 && paths[i].substring(paths[i].length()-3).toLowerCase().equals("jar")) {
File jarFile = new File(paths[i]);
if(jarFile.exists() && jarFile.canRead()) {
JarFile f = new JarFile(jarFile);
Enumeration e = f.entries();
while(e.hasMoreElements()) {
JarEntry entry = (JarEntry)e.nextElement();
// hier kannst Du anhand von entry.getName() die Einträge finden
// z.B. if(entry.getName().endsWith("_Fehlertexte.xml"))
}
f.close();
}
}
}
