problema classloader

Question

Ho una domanda interessante sul comportamento classloader.

Prima domanda:? Qual è l'ordine in cui il programma di caricamento classe caricherà vasetti

I seguenti vasetti e contenenti le classi sono date:

a.jar
  +-com/scheffield/foo/A.class

b.jar
  +-com/scheffield/foo/B.class

Quale classe verrà caricata?

Domanda due:? E 'vero che il percorso e il nome di un file nel percorso di classe è unica

I seguenti vasetti e contenenti classi sono indicate (esempio realworld):

spring-beans-3.0.3.RELEASE.jar
  +-META-INF/spring.schemas

spring-aop-3.0.3.RELEASE.jar
  +-META-INF/spring.schemas

Quello che posso dirvi è che entrambi i file vengono caricati entro la primavera altrimenti si sarebbe verificato un'eccezione (vedi questo articolo ).

Perché sto chiedendo che:

ho fatto un cosiddetto grande vaso ( libro di cucina voce per Gradle ). Quello è un vaso con le classi di applicazioni e tutte le altre dipendenze decompresso e pacchetto in grande vaso. E non sono assolutamente sicuro di cosa fare con i file duplicati.

Answer 1

1. Le classi sono risolti comunque un classloader vuole risolverli (che è il punto di avere un'architettura classloader). La maggior parte dei classloader avete a che fare con, in pratica, sono varianti di java.net .URLClassLoader quali classi carichi (e risorse) sulla base di un percorso di ricerca (percorso classe) delle directory e vasetti. Ogni posizione nel percorso di ricerca è trattata come una fonte di classi e le posizioni vengono ricercati in ordine.

2. No, i nomi non sono univoci. La prima incontrato nell'ordine di ricerca verranno utilizzati.

Se si combinano vasetti in un unico grande vaso v'è una possibilità definita di conflitto. Se si sta attenti a unirle dall'ultimo fonte nel classpath efficace al primo (imperativi quindi vasi successivi con vasetti precedenti), si otterrà circa lo stesso risultato.

dico circa, perché i manifesti in vasi contengono le istruzioni di elaborazione aggiuntive che devono essere fuse pure. Ad esempio, un manifesto può contenere un Class-Path attributo che comprende vasi supplementari nel classpath. E 'possibile unire vasi ma perdono attributi evidenti, si specifica parte del vostro percorso di classe effettiva necessità. Se il manifesto contiene sigillato o firmato vasetti allora si potrebbe non essere in grado di fare questa fusione a tutti, senza violare le parti firmate del il vaso.

In sintesi, vasi non sono realmente progettato per essere incorporata in questo modo. Può funzionare, ma ci sono molte possibilità per errore, alcuni dei quali non sono possibili per risolvere. Una causa comune di errore è quello di unire due file jar e finire con più di una voce con lo stesso percorso, che è consentito in zip file. I compiti jar e zip formica consentono di unire più fonti e in grado di produrre questo tipo di problemi.

In realtà, è meglio applicazioni web al posto del pacco composto da molti vasi e fonti in un unico guerra o EAR archivio. Questo è il genere di tutto il punto del perché esistono.

Answer 2

1. i file vengono caricati in ordine i barattoli contenenti appaiono sul classpath. questo vale per le classi. se si sta caricando altre risorse (come lo spring.schema) è possibile utilizzare sia classloader.getResource (...) o classloader.getResources (...). il primo returnes la prima risorsa nel classpath, il secondo returnes anche le risorse in ombra.
2. Non credo che un archivio zip valida contiene voci duplicate.

Per quanto riguarda