URLClassLoader kann nicht mit jar: file urls umgehen?

Ich möchte eine Bibliothek in getrennten Classloader laden, da nicht direkt als Abhängigkeit hinzugefügt werden soll, um nicht mit anderen Versionen im Projekt zu kollidieren. habe ich einen Lader:URLClassLoader kann nicht mit jar: file urls umgehen?

public LibLoader(String resourcePath) { 
    //resourcePath="/lib/Log4JHack-1.0.jar" 
    URL url = getClass().getResource(resourcePath); 
    loader = new URLClassLoader(new URL[] {url}, getClass().getClassLoader()); 
}

url = [file:/D: /..../ lib/Log4JHack-1.0.jar]

wenn url eine Datei ist , dann funktioniert es gut.

url = [jar: file:/C: /..../ Log4JHackLoader-1.0.jar /lib/Log4JHack-1.0.jar]

wenn url ein jar ist: Datei (jar innerhalb jar), dann es nicht funktionieren:

ERROR StatusLogger Unable to open jar:jar:file:/C:/Users/Dani/.m2/repository/hu/daniel/hari/log4jhack/Log4JHackLoader/1.0/Log4JHackLoader-1.0.jar!/lib/Log4JHack-1.0.jar!/META-INF/log4j-provider.properties java.net.MalformedURLException: no !/ in spec 
    at java.net.URL.<init>(URL.java:620) 
    at java.net.URL.<init>(URL.java:483) 
    at java.net.URL.<init>(URL.java:432) 
    at java.net.JarURLConnection.parseSpecs(JarURLConnection.java:175) 
    at java.net.JarURLConnection.<init>(JarURLConnection.java:158) 
    at sun.net.www.protocol.jar.JarURLConnection.<init>(JarURLConnection.java:81) 
    at sun.net.www.protocol.jar.Handler.openConnection(Handler.java:41) 
    at java.net.URL.openConnection(URL.java:972) 
    at java.net.URL.openStream(URL.java:1038) 
    at org.apache.logging.log4j.util.ProviderUtil.loadProvider(ProviderUtil.java:79) 
    at org.apache.logging.log4j.util.ProviderUtil.<init>(ProviderUtil.java:66) 
    at org.apache.logging.log4j.util.ProviderUtil.lazyInit(ProviderUtil.java:122) 
    at org.apache.logging.log4j.util.ProviderUtil.hasProviders(ProviderUtil.java:106) 
    at org.apache.logging.log4j.LogManager.<clinit>(LogManager.java:91) 
    at hu.daniel.hari.log4jpattern.logrenderer.log4j.log4j.capture.log4j2.StringLoggerCapture.<clinit>(StringLoggerCapture.java:34) 
    at hu.daniel.hari.log4jpattern.logrenderer.log4j.Log4j2Hack.doRender(Log4j2Hack.java:30) 
    at hu.daniel.hari.log4jpattern.logrenderer.log4j.Log4j2Hack.render(Log4j2Hack.java:23) 
    at hu.daniel.hari.log4jpattern.logrenderer.log4j.renderer.AbstractLog4jRendererAdapter.render(AbstractLog4jRendererAdapter.java:25) 
    at hu.daniel.hari.log4jpattern.logrenderer.service.LogRendererServiceImpl.getOutput(LogRendererServiceImpl.java:44) 
    at hu.daniel.hari.log4jpattern.logrenderer.service.LogRendererServiceImpl.render(LogRendererServiceImpl.java:37) 
    at hu.daniel.hari.log4jpattern.logrenderer.TestMain.main(TestMain.java:14) 
Caused by: java.lang.NullPointerException: no !/ in spec 
    at sun.net.www.protocol.jar.Handler.parseAbsoluteSpec(Handler.java:171) 
    at sun.net.www.protocol.jar.Handler.parseURL(Handler.java:151) 
    at java.net.URL.<init>(URL.java:615) 
    ... 20 more

Da ich die ladbare Log4JHack-1.0.jar zu Log4JHackLoader-1.0.jar verpacken möchten, ich brauche eine Lösung für laden g von innen Glas.

Quelle

2016-06-04 Daniel Hári

Es ist mir nicht 100% klar, was Sie hier machen wollen. Warum versuchen Sie, widersprüchliche Abhängigkeiten in Ihren Klassenpfad aufzunehmen?

In jedem Fall ist dies eine bekannte Einschränkung von UrlClassLoader. Haben Sie in Betracht gezogen, das verschachtelte Jar als temporäre Datei im Dateisystem zu extrahieren und dann den Klassenlader darauf zu verweisen?

Quelle

2016-06-04 20:20:18 ck1

Genau das ist der eigentliche Ressourcenpfad. Ich erstelle einen Tester für log4j, also habe ich gehackt, um auf etwas zuzugreifen, und ich möchte dies von der normalen Verwendung von log4j im Projekt trennen. Es funktioniert, wenn das Glas nicht in ein anderes Glas geschachtelt ist, sonst nicht. –

Es sieht so aus, als ob du Maven benutzt. Haben Sie darüber nachgedacht, das Shade-Plugin zu verwenden, um eine gepatchte Version von Log4J mit Ihren Änderungen zu erstellen, so dass Sie nicht durch die Klassenlade-Hoops springen müssen? https://maven.apache.org/plugins/maven-shade-plugin – ck1

Ja ist es Log4JHack-1.0.jar mit Maven Schatten-Plugin gemacht. Der Ressourcenpfad entspricht dem Beispiel. Aber ich wollte die ganze Geschichte in das Ladermodul packen, um das Benutzermodul nicht mit hartcodierten Stringklassenreferenzen zu verschmutzen. Nach dem normalen Laden des Ladermoduls als Abhängigkeit geschieht dies. –

URLClassLoader kann nicht mit jar: file urls umgehen?

Antwort

Verwandte Themen