Comprendre le mécanisme du CLASSLOADER

Hello,

Je cherche à comprendre et cerner le mécanisme du classLoader.:mrgreen:

J'ai fait des recherches sur internet j'ai trouvé différentes choses sur le sujet, mais j'avoue avoir encore le sentiment de ne pas tout bien comprendre encore.

Par exemple, lors du lancement d'un JVM, combien de classloader sont utilisés?
Comment savoir quel classloader est utilisé pour une classe donnée?

En fait, j'aimerai pouvoir échanger sur le sujet avec quelqu'un qui maitrise le sujet (qui à échanger hors forum, afin de ne pas le polluer)

Je vous remercie par avance pour votre aide,

Cordialement,

Citation:

---

Envoyé par fabszn

Hello,

Je cherche à comprendre et cerner le mécanisme du classLoader.:mrgreen:

---

Il charge des classes, avec un mécanisme de délagation prioritaire vers le parent, "en général"

Citation:

---

Par exemple, lors du lancement d'un JVM, combien de classloader sont utilisés?

---

Ca dépend de la jvm, de son implémentation. a la base t'as en général une classloader pour les classe de la jvm + un classloader pour ton application en elle même. Ce petit code donne une idée.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

public class Main {     public static void main(String[] argv) { ClassLoader cl = new Main().getClass().getClassLoader(); while (cl!=null){ System.out.println("Classloader "+cl); cl=cl.getParent(); } }   }

---

Citation:

---

Comment savoir quel classloader est utilisé pour une classe donnée?

---

Code:

---

monMachin.getClass().getClassloader()

---

Hello,

Merci beaucoup pour ta réponse rapide.

En exécutant le code que tu m'as indiqué, j'obtiens ce résultat :

Code:

---

1 2 3

Classloader sun.misc.Launcher$AppClassLoader@11b86e7 Classloader sun.misc.Launcher$ExtClassLoader@35ce36

---

Cela veut dire que ma classe Main est chargée par le classLoader AppClassLoader et que ce dernier est chargé par ExtClassLoader?

ExtClassLoader est le classLoader de la JVM (pour une implémentation donnée) et le classloader AppClassLoader est celui à la responsabilité de charger les classes développées?

Dans le cas d'un serveur d'application, type Tomcat par exemple, il doit y avoir un classloader pour le démarrage de la JVM (ExtClassLoader), un founit par tomcat (??) et enfin un pour le chargement d'une application (war)..

Est ce que le nombre de classloader peut/ou doit être limité ?
est ce que je peux choisir /et comment quel classloader va charger ma classe?

Je suis désolé pour toutes ces questions.. mais j'aimerai comprendre les tenants et les aboutissants du mécanisme.


Merci d'avance pour ton aide,


Cordialement,

Citation:

---

Envoyé par fabszn

Cela veut dire que ma classe Main est chargée par le classLoader AppClassLoader et que ce dernier est chargé par ExtClassLoader?

---

pas nécessairement, la JVM peut très bien démarrer les deux classloaders a son démarrage et les liers entre eux. Le "parent" dans le code d'exemple est celui utilisé par le système de délagation (quand on demande un classe à AppClassLoader, il va d'abord vérifier que ExtClassLoader ne l'a pas). C'est sa popotte interne ;)

Citation:

---

ExtClassLoader est le classLoader de la JVM (pour une implémentation donnée) et le classloader AppClassLoader est celui à la responsabilité de charger les classes développées?

---

C'est ce que les noms suggèrent, mais on en sait rien à priori, il faudrait voir le code de ces deux classes, code qu'on ne connais pas et qui est spécifique à la JVM de sun.

Citation:

---

Dans le cas d'un serveur d'application, type Tomcat par exemple, il doit y avoir un classloader pour le démarrage de la JVM (ExtClassLoader), un founit par tomcat (??) et enfin un pour le chargement d'une application (war)..

---

Il y en a plus que ça, mais c'est documenté sur le site de tomcat

Citation:

---

Est ce que le nombre de classloader peut/ou doit être limité ?

---

Non, il n'y a pas de limite. Un classloader c'est juste une classe qui étends ClassLoader. C'est plus le nombre de classes de l'application qu'il faut garder à l'oeil ;)

Citation:

---

est ce que je peux choisir /et comment quel classloader va charger ma classe?

---

Oui et non. Toutes les classes de ton application de base seront chargées par le classloader imposé par la JVM / par le conteneur J2EE / etc suivant le contexte. Par contre rien ne t'interdit d'utiliser ton propre classloader pour charger des classes supplémentaire. C'est utile par exemple pour mettre en place un système de plugins où tu voudrais isoler les plugins l'un de l'autre. Chaque plugin pourrait avec des classes avec le même nom, elle ne se marcheraient pas sur le pieds. Dans ce cas, la class UrlClassLoader te sera bien utile ;). Une fois le classloader construit, des appel à

Code:

---

tonClassLoader.forName("nom.de.Classe").newInstance()

---

te permettra d'instancier des classes qui y sont.

Hello,

Merci beaucoup pour ta réponse!

Je commence à mieux cerner le truc...:D

Je n'avais jamais fait attention à cette partie de la documentation sur Tomcat.

J'aurais une question complémentaire :

Par exemple, lorsque je configure mon logger (log4j) dans une webApp. Je charge le fichier de configuration en utilisant le mécanisme de chargement de ressource via le classloader.

Code:

---

MaClasse.class.getClassLoader().getResource("com/toto/titi/MyFile.xml")

---

Lorsque je teste en local (sous window) ca marche très bien... en revanche lorsque je déploie sur un environnement tiers (sous linux) il ne trouve pas le fichier de configuration.
Est ce que c'est une différence d'implémentation de la JVM sous jacente qui peut être à l'origine du problème?

Comment je peux maîtriser ce genre de problème qui je pense est lié au classloader?


Merci d'avance pour ton aide,

Cordialement

Salut,

Citation:

---

Envoyé par fabszn

Code:

---

MaClasse.class.getClassLoader().getResource("com/toto/titi/MyFile.xml")

---

Lorsque je teste en local (sous window) ca marche très bien... en revanche lorsque je déploie sur un environnement tiers (sous linux) il ne trouve pas le fichier de configuration.
Est ce que c'est une différence d'implémentation de la JVM sous jacente qui peut être à l'origine du problème?

---

Vérifies bien le nom du fichier, et un éventuelle problème de minuscule/majuscule.

:arrow: Le classloader utilise le système de fichier de l'OS hôte, ce qui pourrait être à l'origine d'une différence de comportement de ce style ;)


a++

Hello,

Merci pour ta réponse adiGuba.

Je vais vérifier ça tout de suite.
Aussi, par ta réponse, je comprends que tu écartes avec certitude le problème de classloader que j'évoquais?

Merci d'avance pour votre aide,

Cordialement,

oui le classloader n'est pas en cause. D'ailleurs si tu package ton application dans un jar, c'est sur d'avoir toujours le même comportement. Ce n'est pas parce que d'un JVM à l'autre la hierarchie des classloader n'est pas la même que le contrat des méthode de classloader n'est pas respecté. Le classpath de ton application au final est prévisible quel que soit la jvm, et la manière dont se comporte getResource par rapport à ce classpath est le même.

Je n'écartes rien en particulier... mais ces problèmes de casses ont été la majeur partie des problèmes d'une migration d'une appli web de Windows vers Linux.

a++

un petit complément (qui vaut ce qu'il vaut... mais bon)
ICI

Hello,

Merci pour vos réponses.

@professeur shadoko : Le lien ne fonctionne pas.. :-(

@adiGuba : effectivement.. problème de casse..:oops:


Une dernière question, pour résumer un peu, mise à part écrire son propre classloader, à priori on ne peut pas influencer celui qui va charger nos classes au démarrage de la JVM?


En tout cas merci pour votre aide.

Cordialement,

Citation:

---

Envoyé par fabszn

@adiGuba : effectivement.. problème de casse..:oops:

---

classique ;)

Citation:

---

Envoyé par fabszn

Une dernière question, pour résumer un peu, mise à part écrire son propre classloader, à priori on ne peut pas influencer celui qui va charger nos classes au démarrage de la JVM?

---

Dans quel objectif ?


a++

Citation:

---

Envoyé par fabszn

@professeur shadoko : Le lien ne fonctionne pas.. :-(

---

comment se fait-ce? :?:
(ça marche pour moi avec différents réseaux et firefox)

Citation:

---

Envoyé par fabszn

Code:

---

1 2 3

Classloader sun.misc.Launcher$AppClassLoader@11b86e7 Classloader sun.misc.Launcher$ExtClassLoader@35ce36

---

...

ExtClassLoader est le classLoader de la JVM (pour une implémentation donnée) et le classloader AppClassLoader est celui à la responsabilité de charger les classes développées?

---

non ExtClassLoader est le ClassLoader des extensions. Le ClassLoader de bootstrap n'est pas forcément vu par getParent() du fait de cet élement de la doc: "Some implementations may use null to represent the bootstrap class loader. This method will return null in such implementations if this class loader's parent is the bootstrap class loader. "

Citation:

---

Envoyé par fabszn

Une dernière question, pour résumer un peu, mise à part écrire son propre classloader, à priori on ne peut pas influencer celui qui va charger nos classes au démarrage de la JVM?

---

Ca n'a pas d'intéret et de toutes façons, tu n'a pas le controle sur le classloader du démarrage de la JVM. Tu as juste le controle sur les classes supplémentaire que ton applicaiton java déjà en cours de fonctionnement, ajoute avec ses propres classloaders.

Hello,


@adiGuba : Je n'ai pas d'objectif particulier, c'est juste pour comprendre le mécanisme et mieux le maîtriser.

@professeur shadoko : Désolé, sa doit être le réseau de mon entreprise qui doit avoir des problèmes, j'ai testé depuis mon mobile et ça marche. Je n'ai pas encore tout lu, mais le lien a l'air très intéressant.

Citation:

---

Le ClassLoader de bootstrap

---

Le bootstrap c'est celui que est utilisé par la JVM au moment du démarrage?

Merci pour votre aide,

Cordialement

c'est le classloader de base, celui chargé notamment de tout ce qui se trouve dans java.lang

Hello,

Merci à tous pour vos réponses et votre aide. Ma lanterne est maintenant un peu plus claire! :D:D

Hello,

Je reviens après avoir lu l'article conseillé par professeur shadoko. Très intéressant et il m'a encore plus éclairci les idées sur le sujet.

J'ai fait quelques tests pour aller un peu plus loin..

Il y a un truc que je ne comprends pas.. :oops:

cette ligne ne devrait pas renvoyer le nom d'un classLoader :

Code:

---

System.out.println("ClassLoaderDirect : " + java.lang.String.class.getClassLoader());

---

Le premier qui est chargé au lancement de la JVM?
Lorsque j'exécute ce code, j'ai un référence null.

Merci d'avance pour votre aide,

Cordialement,

comme déjà dit, le bootstrap n'est pas nécessairement visible, d'ou le null ;)

Hello,

:oops::oops::oops::oops::oops:

A temps pour moi! Je pense que maintenant je ne ferai plus l'erreur!


Encore merci!


cordialement