Wie ist ClassLoader.getResources zu verwenden?

[DarthShader]

Hallo,

ich verstehe nicht, wie man ClassLoader.getResources(...) verwenden soll. Was ich erwartet hätte ist, dass ich eine "Liste von Resourcen" (bzw. ein Enumeration< URL >) erhalte, wenn ich als resourcen-Name Wildcards verwende. Aber anscheinend geht das nicht, bzw. ich kann einfach keine gescheiten Beispiele dafür finden. Ich habe zum Beispiel dies hier probiert:

Enumeration< URL > resources = getClass().getClassLoader().getResources( "de/test/*.*" );

oder auch

Enumeration< URL > resources = getClass().getClassLoader().getResources( "classpath*:de/test/*.*" );

In beiden Fällen erhalte ich eine leere Enumeration - er findet also anscheinend nichts.

Habe ich den Sinn von ClassLoader.getResources(...) falsch verstanden?


Über Eure Hilfe würde ich mich sehr freuen


Vielen Dank!

 

[Thomas Darimont]

Hallo,

AFAIK unterstützt cl.getResource(...) bzw. cl.getResources(...) keine Wildcards bzw. Patterns. Du musst die Resourcen immer voll Qualifizieren. Hast du beispielsweise eine Datei foo.properties im ClasssPath-Root bekommst du mit cl.getResource("foo.properties") eine URL zu der Datei im Classpath mit cl.getResources(...) bekommst du eine Enumeration mit der URL. Wie kann man nun mehrere Resourcen zurück bekommen? Beispielsweise wenn im "sichtbaren" Classpath des ClassLoaders mehrere Jars liegen, welche ihrerseits z.Bsp im root eine Datei jndi.properties haben, so findet ein cl.getResources("jndi.properties") alle jndi.properties im classpath -> die Enumeration enthält dann die URLs zu den Resourcen. Das wäre mal der unterschied und die Funktionsweise zu getResource vs. getResources.

Ruft man wiederum an einer Class .getResource auf, so wird die Suche relativ zur Klasse ausgeführt im gegensatz zu ClassLoader getResource (dort werden die Suchen relativ zum "classpath-Root" ausgeführt.
Beispiel:

package de.tutorials;                                                                                                                           
                                                                                                                                                
public class GetResourcesExample {                                                                                                              
    public static void main(String[] args) throws Exception{                                                                                    
        Class<GetResourcesExample> clazz = GetResourcesExample.class;                                                                           
        ClassLoader cl = clazz.getClassLoader();                                                                                                
        System.out.println(cl.getResource("de/tutorials/GetResourcesExample.class"));                                                           
        System.out.println(clazz.getResource("GetResourcesExample.class"));                                                                     
    }                                                                                                                                           
}

Ausgabe:

file:/C:/development/java/workspaces/sts233M1/de.tutorials.java.training/target/classes/de/tutorials/GetResourcesExample.class
file:/C:/development/java/workspaces/sts233M1/de.tutorials.java.training/target/classes/de/tutorials/GetResourcesExample.class

Gruß Tom

 

[DarthShader]

Hallo Thomas,

vielen Dank für die Antwort - jetzt habe ich den Unterschied zwischen "getResource(...)" und "getResources(...)" verstanden.

Ich frage mich nur, wie Frameworks wie Reflections (http://code.google.com/p/reflections/) oder Spring's ClassPath Scanner das machen. Das was ich bisher gelesen habe, deutete immer darauf hin, dass sie unter der Haube auch mit "getResources(...)" arbeiten.

Mein Ziel war es, eine Liste von Klassen zu erhalten, die in einem bestimmten Package sind und die einem bestimmten Namensmuster folgen (z.B. "xxxListener"). Ich wollte mir für diese kleine Sache eigentlich nicht die Abhängigkeit zu Spring oder anderen Frameworks machen, da ich dachte, dass dies nicht so tricky sei - aber anscheinend ist es das doch.

 

[Oliver Gierke]

Spring geht her und holt sich alle Resourcen bis zum ersten wildcard und traversiert den Rest dann mehr oder weniger manuell. Nachzulesen in beliebiger Detailtiefe im Fisheye [1]. Die spannende Methode hierbei ist findPathMatchingResources.

Gruß
Ollie

[1] - https://fisheye.springsource.org/br...thMatchingResourcePatternResolver.java?r=HEAD

 

[DarthShader]

Hallo Oliver,

hm ja, ich denke jetzt habe ich den Mechanismus verstanden - er holt sich quasi ne Start-Resource (wie Du sagst, z.B. ein package-Prefix bis zum ersten Wildcard) und dann traversiert er einfach die echten Verzeichnisse des Dateisystems oder die des JAR files, und versucht dann, sich anhand dieser Dateinamen wieder die Resourcen zu holen.

Ich denke das ist der "Trick", nach dem ich gesucht hatte.