Problème de ClassLoader rigolo (ou pas)

[Nicolas Delsaux]

Salut,

- petit préambule - Cette question est un résumé de celle-ci :
http://stackoverflow.com/q/7804357/15619

je développe actuellement une application Glassfish client. Dans cette
application, "logiquement", je récupère mes EJBs distants en utilisant
un InitialContext. Enfin, j'essaye.
En effet, j'obtiens à chaque fois des ClassNotFoundException sur
SerialInitContextFactory.
J'ai pourtant bien tous les jars de Glassfish dans mon projet maven,
et ils sont bien placés dans le bon répertoire pour l'exécution.
Le plus curieux, c'est quand je cherche l'URL de mes resources :

getClass().getClassLoader().getResource("com/sun/enterprise/naming/impl")
= jar:file:/C:/Users/pouet/pouet/target/jars/glassfish-naming-3.1.jar!/com/sun/enterprise/naming/impl

getClass().getClassLoader().getResource("com/sun/enterprise/naming/impl/SerialInitContextFactory")
= null

Ici, on voit bien que le package est accessible au ClassLoader, mais
PAS les classes qui sont dedans.
Qu'est-ce qui peut faire ça ?
Et comment je peux faire en sorte que ça marche ?

[Lilians Auvigne]

Je ne connais pas glassfish, mais cela ressemble à une isolation de
classloader à la OSGI.
Verifie le export-package du META-INF de
C:/Users/pouet/pouet/target/jars/glassfish-naming-3.1.jar

Post by Nicolas Delsaux
Salut,
http://stackoverflow.com/q/7804357/15619
je développe actuellement une application Glassfish client. Dans cette
application, "logiquement", je récupère mes EJBs distants en utilisant
un InitialContext. Enfin, j'essaye.
En effet, j'obtiens à chaque fois des ClassNotFoundException sur
SerialInitContextFactory.
J'ai pourtant bien tous les jars de Glassfish dans mon projet maven,
et ils sont bien placés dans le bon répertoire pour l'exécution.
getClass().getClassLoader().getResource("com/sun/enterprise/naming/impl")
=
jar:file:/C:/Users/pouet/pouet/target/jars/glassfish-naming-3.1.jar!/com/sun/enterprise/naming/impl
getClass().getClassLoader().getResource("com/sun/enterprise/naming/impl/SerialInitContextFactory")
= null
Ici, on voit bien que le package est accessible au ClassLoader, mais
PAS les classes qui sont dedans.
Qu'est-ce qui peut faire ça ?
Et comment je peux faire en sorte que ça marche ?
--
Nicolas Delsaux

[Nicolas Delsaux]

Post by Lilians Auvigne
Je ne connais pas glassfish, mais cela ressemble à une isolation de
classloader à la OSGI.
Verifie le export-package du META-INF de
C:/Users/pouet/pouet/target/jars/glassfish-naming-3.1.jar

Export-Package: com.sun.enterprise.naming;include:=SerialInitContextFa
ctory;uses:="javax.naming,javax.naming.spi,com.sun.enterprise.naming.
util,org.jvnet.hk2.annotations,org.jvnet.hk2.component,org.glassfish.
api,org.glassfish.internal.api,com.sun.enterprise.naming.impl";versio
n="3.1.0",com.sun.enterprise.naming.impl;uses:="javax.naming,org.glas
sfish.api.naming,org.jvnet.hk2.component,org.jvnet.hk2.annotations,co
m.sun.enterprise.naming.util,org.omg.CORBA,org.glassfish.api.invocati
on,javax.naming.spi,com.sun.logging,com.sun.corba.ee.spi.folb,org.gla
ssfish.api.admin,org.glassfish.internal.api,com.sun.enterprise.util,c
om.sun.jndi.cosnaming,org.omg.CosNaming.NamingContextPackage,org.omg.
CosNaming,javax.rmi,org.omg.CORBA.ORBPackage";version="3.1.0",com.sun
.enterprise.naming.spi;uses:="org.glassfish.api.naming,org.jvnet.hk2.
annotations";version="3.1.0",com.sun.enterprise.naming.util;uses:="ja
vax.naming,com.sun.enterprise.naming.spi,org.jvnet.hk2.annotations,ja
vax.naming.spi,org.jvnet.hk2.component,com.sun.enterprise.naming,org.
osgi.framework,org.glassfish.internal.api,org.osgi.util.tracker,org.o
sgi.service.packageadmin";version="3.1.0"

Ca fait un sacré paquet de trucs, hein ?

Bon, j'imagine que, si je remplace le
com.sun.enterprise.naming.impl.SerialInitContextFactory par
com.sun.enterprise.naming.SerialInitContextFactory Ca marchera mieux ?

Eh ben non, toujours pareil !

Là où c'est vraiment trop fort, c'est que, dans mon code, j'écris
p.setProperty(Context.INITIAL_CONTEXT_FACTORY,
com.sun.enterprise.naming.SerialInitContextFactory.class.getCanonicalName());

Qui "marche" bien, puisque ça compile et qu'à l'exécution ça se passe
bien, mais j'ai quand même l'exception après. Fou, non ?

[Rémi Forax]

Post by Nicolas Delsaux
Salut,
http://stackoverflow.com/q/7804357/15619
je développe actuellement une application Glassfish client. Dans cette
application, "logiquement", je récupère mes EJBs distants en utilisant
un InitialContext. Enfin, j'essaye.
En effet, j'obtiens à chaque fois des ClassNotFoundException sur
SerialInitContextFactory.
J'ai pourtant bien tous les jars de Glassfish dans mon projet maven,
et ils sont bien placés dans le bon répertoire pour l'exécution.
getClass().getClassLoader().getResource("com/sun/enterprise/naming/impl")
= jar:file:/C:/Users/pouet/pouet/target/jars/glassfish-naming-3.1.jar!/com/sun/enterprise/naming/impl
getClass().getClassLoader().getResource("com/sun/enterprise/naming/impl/SerialInitContextFactory")
= null
Ici, on voit bien que le package est accessible au ClassLoader, mais
PAS les classes qui sont dedans.
Qu'est-ce qui peut faire ça ?
Et comment je peux faire en sorte que ça marche ?

Cela veut dire que la classe est déjà chargé par un jar situé dans le
bootclasspath.

Rémi

[Nicolas Delsaux]

Post by Rémi Forax

Post by Nicolas Delsaux
Ici, on voit bien que le package est accessible au ClassLoader, mais
PAS les classes qui sont dedans.
Qu'est-ce qui peut faire ça ?
Et comment je peux faire en sorte que ça marche ?

Cela veut dire que la classe est déjà chargé par un jar situé dans le
bootclasspath.

Ah !
Bon, cela dit, après quelques lectures de blog, j'en suis aussi arrivé
à la constatation d'un problème de ClassLoder, que j'ai résolu d'un
vigoureux
Thread.currentThread().setContextClassLoader(getClass().getClassLoader())
qui marche du feu de dieu.
C'est peut-être pas super propre, mais ça marche !

[Jean-Baptiste BRIAUD -- Novlog]

<PHILO allez-pourquoi-pas-c'est-pas-forcement-un-troll=true>
A lire les réponses et la question, j'ai une sorte de sentiment qui se précise :
ils ont tué Java.

Je comprends de mieux en mieux pourquoi d'autres langages voient le jour.
Dommage ...

OSGI et tout son bazar de paramètrage super puissant qui viens avec, tu va voir on peux tout faire, c'est cool, c'est beau
+ Maven
+ Eclipse où il faut pêcher des plugins avant de bosser, même pour un truc aussi banal que SVN (ah oui mais c'est gratuit, donc il faudrait ne rien dire)
+ des Factory avec des fichiers de paramètrage en XML
+ des logs avec plein de librairies différentes et aussi des fichiers XML pour le paramètrage mais aussi parfois des .properties, mais pas toujours, çà dépends de la lib
+ des EJB avec des descripteurs de déploiements XML et des éléments spécifiques pour le conteneur, mais pas toujours, çà dépends et encore, maintenant, les EJB c'est simple
+ Hibernate et des fichiers de paramètrages en XML mais pas forcément depuis les annotations JPA mais avec des annotations spécifiques car JPA ne fait pas tout
+ ...
Cette stack "à la mode" me donne la nausée.
Franchement, cela me semble insensé.

Où est passé ce qui semblait être un certain esprit de simplicité ?
Où sont passé les erreurs de compilation qui permettait de savoir où se trouvait un problème ?
</PHILO>

[jerome moliere]

Je me suis gaufré dans mon envoi
désolé
J.MOLIERE - Mentor/J
auteur Eyrolles
blog: http://romjethoughts.blogspot.com






---------- Message transféré ----------
De : jerome moliere <***@gmail.com>
Date : 18 octobre 2011 15:31
Objet : Re: Problème de ClassLoader rigolo (ou pas)
À : Jean-Baptiste BRIAUD -- Novlog <j-***@novlog.com>


En ce qui concerne OSGi je ne suis pas vraiment d'accord mais pour le reste +1
Et encore Jean Baptiste je ne sais pas si t'as vu ce que nous prépare Java 8 ...
demandes à Remi d'expliquer comment en douce on voit revenir
l'héritage multiple ?
quand je pense qu'il y a 10 ans les gens disaient que  la STL était
trop complexe car les Collections Java 8 avec le support tant attendu
des Closures n'est pas sans me rappeler cette STL mais je dois radoter
-)

Jerome
J.MOLIERE - Mentor/J
auteur Eyrolles
blog: http://romjethoughts.blogspot.com

[Rémi Forax]

Java 8 n'introduira pas d'héritage multiple
mais une forme sympathique de traits (pas ceux de Scala).
En quelque mot, tu auras la possibilité de mettre du code dans une méthode
d'une interface, si une classe qui implante l'interface ne founi pas de
code,
celui déclarer dans l'interface sera choisie.
Si on implante deux interfaces et que chacune produit du code pour une
même méthode,
le code ne compilera pas et il faudra fournir un nouveau pour la méthode
sachant que l'on pourra appeler le code des interfaces dont on hérite.

Cela devrait résoudre le plus gros probème des interfaces,
le fait que l'on ne peut pas les faires évoluer dans le temps en ajoutant
des méthodes. En effet, il sera binary compatible d'ajouter une méthode
si l'on fourni un code.

Maintenant, ce ne devrait pas être une révolution mais juste une façon
d'étendre des interfaces de la même façon que l'on étant une classe
abstraite mais sans pouvoir ajouter de champs donc pas d'héritage multiple.

Enfin pour ce qui est des lambdas, je pense qu'il n'y a pas photos entre
Collections.sort(list, new Comparator<String>() {
public int compare(String s1, String s2) {
return s1.compareIgnoreCase(s2);
}
};
et
list.sort((s1, s2) -> s1.compareIgnoreCase(s2));
ou mieux
list.sort(String::compareIgnoreCase);

J'espère que l'on arrrivera à sortir le premier draft public
de la spec à la fin du mois.

Rémi

Post by jerome moliere
Je me suis gaufré dans mon envoi
désolé
J.MOLIERE - Mentor/J
auteur Eyrolles
blog: http://romjethoughts.blogspot.com
---------- Message transféré ----------
Date : 18 octobre 2011 15:31
Objet : Re: Problème de ClassLoader rigolo (ou pas)
En ce qui concerne OSGi je ne suis pas vraiment d'accord mais pour le reste +1
Et encore Jean Baptiste je ne sais pas si t'as vu ce que nous prépare Java 8 ...
demandes à Remi d'expliquer comment en douce on voit revenir
l'héritage multiple ?
quand je pense qu'il y a 10 ans les gens disaient que la STL était
trop complexe car les Collections Java 8 avec le support tant attendu
des Closures n'est pas sans me rappeler cette STL mais je dois radoter
-)
Jerome
J.MOLIERE - Mentor/J
auteur Eyrolles
blog: http://romjethoughts.blogspot.com

[jerome moliere]

Post by Rémi Forax
Java 8 n'introduira pas d'héritage multiple
mais une forme sympathique de traits (pas ceux de Scala).
En quelque mot, tu auras la possibilité de mettre du code dans une méthode
d'une interface, si une classe qui implante l'interface ne founi pas de
code,
celui déclarer dans l'interface sera choisie.
Si on implante deux interfaces et que chacune produit du code pour une même
méthode,
le code ne compilera pas et il faudra fournir un nouveau pour la méthode
sachant que l'on pourra appeler le code des interfaces dont on hérite.

les defaults static en effet j'ai conscience que c'est pas simple de
refactorer de l'intérieur sans péter l'API mais je trouve cela un peu
bidouille et cracrac mais cela n'est que mon avis et cela ressemble
fortement (je dis bien RESSEMBLER) à de l'héritage multiple mais la
nuance existe et tu fais bien de l'apporter...

Post by Rémi Forax
Cela devrait résoudre le plus gros probème des interfaces,
le fait que l'on ne peut pas les faires évoluer dans le temps en ajoutant
des méthodes. En effet, il sera binary compatible d'ajouter une méthode
si l'on fourni un code.
Maintenant, ce ne devrait pas être une révolution mais juste une façon
d'étendre des interfaces de la même façon que l'on étant une classe
abstraite mais sans pouvoir ajouter de champs donc pas d'héritage multiple.
Enfin pour ce qui est des lambdas, je pense qu'il n'y a pas photos entre
 Collections.sort(list, new Comparator<String>() {
   public int compare(String s1, String s2) {
      return s1.compareIgnoreCase(s2);
   }
 };
et
 list.sort((s1, s2) -> s1.compareIgnoreCase(s2));
ou mieux
 list.sort(String::compareIgnoreCase);
J'espère que l'on arrrivera à sortir le premier draft public
de la spec à la fin du mois.

j'espère aussi j'ai essayé de bidouiller avec l'existant mais pas
encore user friendly à installer pour faire mumuse ....-)


Jerome

[Rémi Forax]

Post by jerome moliere

Post by Rémi Forax
J'espère que l'on arrrivera à sortir le premier draft public

Post by Rémi Forax
de la spec à la fin du mois.

j'espère aussi j'ai essayé de bidouiller avec l'existant mais pas
encore user friendly à installer pour faire mumuse ....-)
Jerome

Pour l'instant le support du compilo est Ok (pas fini mais Ok),
mais le support VM est à la traine comme d'hab :)

Rémi

[marc godin]

+1 mais on doit etre des vieux con:)
Chutt... j aime pas maven non plus mais faut pas trops dire ca ici :) osgi
je suis perplexe or infra type plugin a la eclipse
Le plus enervant c les projets avec 120 libs dand le path...
Le 18 oct. 2011 15:21, "Jean-Baptiste BRIAUD -- Novlog" <

Post by Jean-Baptiste BRIAUD -- Novlog
<PHILO allez-pourquoi-pas-c'est-pas-forcement-un-troll=true>
ils ont tué Java.
Je comprends de mieux en mieux pourquoi d'autres langages voient le jour.
Dommage ...
OSGI et tout son bazar de paramètrage super puissant qui viens avec, tu va
voir on peux tout faire, c'est cool, c'est beau
+ Maven
+ Eclipse où il faut pêcher des plugins avant de bosser, même pour un truc
aussi banal que SVN (ah oui mais c'est gratuit, donc il faudrait ne rien
dire)
+ des Factory avec des fichiers de paramètrage en XML
+ des logs avec plein de librairies différentes et aussi des fichiers XML
pour le paramètrage mais aussi parfois des .properties, mais pas toujours,
çà dépends de la lib
+ des EJB avec des descripteurs de déploiements XML et des éléments
spécifiques pour le conteneur, mais pas toujours, çà dépends et encore,
maintenant, les EJB c'est simple
+ Hibernate et des fichiers de paramètrages en XML mais pas forcément
depuis les annotations JPA mais avec des annotations spécifiques car JPA ne
fait pas tout
+ ...
Cette stack "à la mode" me donne la nausée.
Franchement, cela me semble insensé.
Où est passé ce qui semblait être un certain esprit de simplicité ?
Où sont passé les erreurs de compilation qui permettait de savoir où se
trouvait un problème ?
</PHILO>

[Sebastien Cesbron]

Salut

+1 pour moi aussi

Perso je fais du Play Framework depuis maintenant bientôt 3 mois et je dois
dire que c'est un vrai bonheur. Si un jour je dois revenir à la stack
décrite par Jean Baptiste je crois que j'aurais du mal

A+
Seb

Post by marc godin
+1 mais on doit etre des vieux con:)
Chutt... j aime pas maven non plus mais faut pas trops dire ca ici :) osgi
je suis perplexe or infra type plugin a la eclipse
Le plus enervant c les projets avec 120 libs dand le path...
Le 18 oct. 2011 15:21, "Jean-Baptiste BRIAUD -- Novlog" <
<PHILO allez-pourquoi-pas-c'est-pas-forcement-un-troll=true>

Post by Jean-Baptiste BRIAUD -- Novlog
ils ont tué Java.
Je comprends de mieux en mieux pourquoi d'autres langages voient le jour.
Dommage ...
OSGI et tout son bazar de paramètrage super puissant qui viens avec, tu va
voir on peux tout faire, c'est cool, c'est beau
+ Maven
+ Eclipse où il faut pêcher des plugins avant de bosser, même pour un truc
aussi banal que SVN (ah oui mais c'est gratuit, donc il faudrait ne rien
dire)
+ des Factory avec des fichiers de paramètrage en XML
+ des logs avec plein de librairies différentes et aussi des fichiers XML
pour le paramètrage mais aussi parfois des .properties, mais pas toujours,
çà dépends de la lib
+ des EJB avec des descripteurs de déploiements XML et des éléments
spécifiques pour le conteneur, mais pas toujours, çà dépends et encore,
maintenant, les EJB c'est simple
+ Hibernate et des fichiers de paramètrages en XML mais pas forcément
depuis les annotations JPA mais avec des annotations spécifiques car JPA ne
fait pas tout
+ ...
Cette stack "à la mode" me donne la nausée.
Franchement, cela me semble insensé.
Où est passé ce qui semblait être un certain esprit de simplicité ?
Où sont passé les erreurs de compilation qui permettait de savoir où se
trouvait un problème ?
</PHILO>