[JAVA] Problema con custom classloader

[tylerdurden83]

Buongiorno a tutti. Sto cercando di scrivere un classloader custom (estende URLClassLoader) per caricare/ricaricare a runtime certe classi.

Ho provato in vari modi ma ho una serie di problemi. Ad esempio, non riesco a "collegare" correttamente il custom classloader alla gerarchia di classloader. In pratica, riesco a fargli caricare un jar a runtime, ma quando carico una classe specifica dentro quel jar mi va in ClassNotFoundException su classi che avrebbe dovuto trovare nei classloader padri (ad es org.apache.log4j)...

Qualcuno ha già dovuto sbattere la testa sui custom classloader e mi sa dare una mano?

[banryu79]

Non posso darti consigli circostanziati, perchè fin'ora non mi sono mai cimentato nello studio del meccanismo di class loading e nell'implementazione di un custom ClasslLoader, però prova a vedere se questa lettura aiuta:
http://books.google.com/books?id=EhX9BjHj9M4C&pg=PA112&dq=Java+Security+Classloader&hl=it&ei=fpfrTLSuF6Pb4wbRopx2&sa=X&oi=book_result&ct=result&resnum=1&ved=0CCwQ6AEwAA#v=onepage&q=Java%20Security%20Classloader&f=false

[tylerdurden83]

Non posso darti consigli circostanziati, perchè fin'ora non mi sono mai cimentato nello studio del meccanismo di class loading e nell'implementazione di un custom ClasslLoader, però prova a vedere se questa lettura aiuta:
http://books.google.com/books?id=EhX9BjHj9M4C&pg=PA112&dq=Java+Security+Classloader&hl=it&ei=fpfrTLSuF6Pb4wbRopx2&sa=X&oi=book_result&ct=result&resnum=1&ved=0CCwQ6AEwAA#v=onepage&q=Java%20Security%20Classloader&f=false

Ancora una volta ban è in soccorso! Grazie, vado a documentarmi!

[euks]

Se estendi URLClassLoader basta passare il classloader padre al costruttore

[tylerdurden83]

Se estendi URLClassLoader basta passare il classloader padre al costruttore

Vero, ma ho comunque un problema, ossia il fatto che se una classe usata nella classe che carico dinamicamente è già stata caricata ottengo un classcastexception perchè la stessa classe caricata da due class loader diversi è diversa...

[euks]

Strano. Mi è capitato più volte di fare in questo modo e non ho avuto problemi.
Potresti postare il codice?

[banryu79]

...perchè la stessa classe caricata da due class loader diversi è diversa...
Questo è esatto.
Ed è giusto che sia così per via di implicazioni inerenti la sicurezza, quando si caricano classi remote.

[tylerdurden83]

La main class


public static void main(String[] args) throws ClassNotFoundException, IllegalAccessException, InstantiationException {
try {
ClassLoader parentClassLoader = MyClassLoader.class.getClassLoader();
MyClassLoader classLoader = new MyClassLoader(parentClassLoader);
Class myObjectClass = classLoader.loadClass("monitor.resource.Resource");
Resource object1 = (Resource) myObjectClass.getConstructor(String.class,String.class,String.class,boolean.class,String.class).newInstance("resourceFile","patternFile","resourceName",true,"parserClass");
...
}


MyClassLoader:


public class MyClassLoader extends URLClassLoader{

public MyClassLoader(ClassLoader parent) {
super(new URL[0],parent);
}

@Override
public Class loadClass(String name) throws ClassNotFoundException {
if(!"monitor.resource.Resource".equals(name) ){
System.out.println("DELEGATING LOADING OF "+name+" TO PARENT CLASSLOADER");
return super.loadClass(name);
}
try {
if("monitor.resource.Resource".equals(name)){
System.out.println("LOADING monitor.resource.Resource...");
String url = "jar:file:C:\\Documents and Settings\\User15\\Documenti\\NetBeansProjects\\monitorv4.0.2\\dist\\monitorv4.0.2.jar!/";
this.addURL(new URL(url));
return this.findClass("monitor.resource.Resource");
}
...
}


Lo stack trace:


LOADING monitor.resource.Resource...
DELEGATING LOADING OF java.lang.Object TO PARENT CLASSLOADER
DELEGATING LOADING OF java.lang.String TO PARENT CLASSLOADER
Exception in thread "main" java.lang.ClassCastException: monitor.resource.Resource cannot be cast to monitor.resource.Resource
at varioustests.MyClassLoaderTest.main(MyClassLoaderTest.java:31)
Java Result: 1

[tylerdurden83]

Precisazione, il classCast (dovrebbe) essere dovuto appunto al fatto che monitor.resource.Resource era già stata caricata in precedenza in quanto contenuta in un jar che va necessariamente incluso nel classpath

[banryu79]

Precisazione, il classCast (dovrebbe) essere dovuto appunto al fatto che monitor.resource.Resource era già stata caricata in precedenza in quanto contenuta in un jar che va necessariamente incluso nel classpath

Che io sappia il meccanismo di class loading è di tipo lazy: allo start-up la virtual machine non contiene nessuna classe caricata in memoria. Prima viene caricato il class file del programma in esecuzione, poi altre classi/interfacce vengono caricate man-mano che se ne incontra il riferimento nel bytecode in esecuzione.
Quindi in questo caso credo non sia sufficiente il fatto che la risorsa (file jar) in cui è contenuto il bytecode della classe in questione (monitor.resource.Resource) si trovi nel classpath per giustificarne il caricamento da parte del system class loader: deve essere già stato incontrato un riferimento nel codice eseguito prima dell'esecuzione di:

...
Class myObjectClass = classLoader.loadClass("monitor.resource.Resource");

...

Nel codice che hai postato, prima di quella istruzione, ci sono riferimenti espliciti solo ai tipi Object, MyClassLoaderTest, String, ClassLoader, MyClassLoader e Class.
In base al mio ragionamento, andando per esclusione, gli unici candidati papabili sembrano essere MyClassLoaderTest e MyClassLoader.

@EDIT:
Qua trovi un articolo (http://java.sys-con.com/node/37659) focalizzato (2003) sul meccanismo del class loading.

@RI-EDIT:
Altre due risorse che contengono ulteriori info (in una si parla pure di class unloading) e mi sembrano più complete
link1 (http://onjava.com/pub/a/onjava/2005/01/26/classloading.html) link2 (http://www.developer.com/java/other/article.php/2248831/Java-Class-Loading-The-Basics.htm)

[tylerdurden83]

Quindi in questo caso credo non sia sufficiente il fatto che la risorsa (file jar) in cui è contenuto il bytecode della classe in questione (monitor.resource.Resource) si trovi nel classpath per giustificarne il caricamento da parte del system class loader: deve essere già stato incontrato un riferimento nel codice eseguito prima dell'esecuzione di:


E' vero. Tuttavia, nella MyClassLoaderTest (quella con il main), quando incontra:


Resource object1 = ...


cerca Resource nel classpath e lo carica. Questo Resource, caricato dal classloader della classe MyClassLoaderTest è diverso dal Resource restituito dalle due righe subito sopra:


MyClassLoader classLoader = new MyClassLoader(parentClassLoader);
Class<?> myObjectClass = classLoader.loadClass("monitor.resource.Resource");


Quindi quando faccio:


Resource object1 = (Resource) myObjectClass.getConstructor(...);


ottengo il ClassCastException

[banryu79]

Sì, stiamo dicendo la stessa cosa, la mia era una precisazione (circa il discorso relativo ad avere o no il jar nel classpath ai fini del class loading).

L'errore è quello: hai già caricato una classe monitor.resource.Resource con il system classloader, quando poi carichi monitor.resource.Resource anche con il tuo custom classloader, esso internamente dovrebbe delegare normalmente al parent classloader anche il caricamento di questa classe, e solo se non la trova già caricata dal parent classloader si occupa lui di caricarla.

Negli esempi canonici di cui ho letto/ho visto io di estensione del class loader, di solito non si fa l'override del metodo loadClass, ma del metodo findClass (normalmente è il motivo principale per cui ci si scrive un proprio class loader, ti rimando alle risorse che ti ho linkato, in particolare l'estratto su google book).

A questo punto forse è meglio se ci spieghi cosa stai cercando di ottenere?

[tylerdurden83]

hai già caricato una classe monitor.resource.Resource con il system classloader, quando poi carichi monitor.resource.Resource anche con il tuo custom classloader, esso internamente dovrebbe delegare normalmente al parent classloader anche il caricamento di questa classe, e solo se non la trova già caricata dal parent classloader si occupa lui di caricarla.

Questo è il motivo per cui ho override loadclass invece di findclass. L'obiettivo è quello di ricaricare delle classi, che a loro volta potrebbero usare internamente una nuova classe non ancora caricata / presente nel classpath e quindi che va caricata da zero.

Se faccio come dici e cioè caricare una classe solo se nn la trova gia caricata dal parent classloader posso ottenere il secondo target (caricare classi non ancora caricate), ma non ricaricare "a caldo" una classe modificata (la cui versione precedente era gia stata caricata)

[banryu79]

...
Se faccio come dici e cioè caricare una classe solo se nn la trova gia caricata dal parent classloader posso ottenere il secondo target (caricare classi non ancora caricate), ma non ricaricare "a caldo" una classe modificata (la cui versione precedente era gia stata caricata)
Infatti, da quel che ho letto (e ancora una volta devo sottolineare la mia mancanza di esperienza diretta con il meccanismo di class loading, perchè tu ne devi essere consapevole e rpendere cum grano salis quello che ti dico) le due cose che vuoi fare sono appunto due cose diverse.

Questo perchè una classe XYZ, una volta che è stata caricata viene tenuta in cache; se al class loader chiedi di "ricaricarla" esso non la ricarica, la pesca dalla cache.

Bisogna quindi vedere se (e come) è possibile scaricare una classe già caricata da un class loader, in generale; e poi nello specifico (se nel tuo caso sarà per forza di cose il system class loader quello coinvolto con il caricamento delle classi in questione) se e come scaricare una classe dal system class loader.