Discussion :

[mysianne]

Bonjour,
Une fois de plus je reviens avec l'un de ces problèmes gonflant !

mon application JEE marchait correctement jusqu’à ce que je la redéploie de nouveau. J’obtiens l'erreur suivante:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Exception while loading the app : java.lang.IllegalStateException:
 ContainerBase.addChild: start: org.apache.catalina.LifecycleException: 
java.lang.RuntimeException: java.lang.NoClassDefFoundError: Lglp/dao
/InterfaceDao;. Pour plus d’informations, consultez le fichier server.log.

j'ai lu des articles sur les erreurs

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

java.lang.NoClassDefFoundError:

mais je n'ai pas encore eu de solution à cee problème. La chose dont je suis cependant sure est que toute mes classes sont disponible dans le classpath mais le classloader pour une raison que j'espère avoir ici refuse de toutes les charger ! merci d'avance pour votre aide
PS je travaile avec Glassfish V3 et JDk 7

[tchize_]

Visiblement, il te manque

Lglp/dao/InterfaceDao


Cette classe se trouve ou?

[mysianne]

Je m'excuse pour mon absence prolongé, et te remercie pour l’intérêt porté à mon problème.
En effet, l'interface se trouve bien là la JVM dit qu'elle n'est pas. J'ai déjà eu des problème identique plusieurs fois sous glassfish et j'ai du de façon radicale réinstaller glassfish pour résoudre le problème. aujourd'hui j'en ai marre et je veux vraiment comprendre pourquoi cela ce produit. pour quelle raison le classloader peut manquer une classe à l'exécution d'un programme et surtout comment charge t-il les classe sous glassfish car je me doute fort que c'est là la source de mes soucis

[tchize_]

En effet, l'interface se trouve bien là

Oui, mais où là? C'était la question

comment charge t-il les classe sous glassfish car je me doute fort que c'est là la source de mes soucis

Si c'est une application type webapp, les classes sont chargée depuis le WEB-INF/lib/*.jar et le WEB-INF/classes du war.

[mysianne]

Quand je dit là où la JVM dit qu'elle n'est pas; c'est-à-dire dans le package glp.dao Je le sais parceque j'ai ouvert l'arborescence de mon jar et la classe s'y trouvait bien!

Mon application est de type JEE avec un module EJB et un modules WEB, c'est justement l'interface de mon EJB qui à un certains moment n'est pas chargé ou n'est pas visible par la JVM.

les classes sont chargée depuis le WEB-INF/lib/*.jar et le WEB-INF/classes du war.

Oui ça je le sais mais pourquoi certaine classe peuvent être chargé et pas d'autres alors qu'elles sont localisées au même endroit?

J'ai envisager que puisque mon module web utilise l'EJB, peut-être à un certains moment une classe de mon module war essai d'utiliser l'interface de l'EJB alors qu'il n'est pas encore chargé par le classloader. Mais j'ai des doutes qui persistes puisque l'erreur survient au déploiement.
Alors j'essaie de déployer le module EJB tout seul (.jar) et c'est pareil.

java.lang.NoClassDefFoundError:

et c'est là que je me perds !

[tchize_]

il y a les règles de java pour le classloading, ensuite il y a les règles de j2EE (qui obligent une isolation entre tes wars, entre tes ear, qui permettent aux wars inclus dans un ear de voirs les ejbs, qui interdisent aux ejb de voir les war) et puis il y a les exceptions spécifiques au conteneur (glassfish) qu'on peux configurer dans ce cas si, si je ne me trompe pas, par des fichier manifest.mf.


Donc ma question est:

ta classe se trouve ou (physiquement, quel est le path du jar)
et le code qui tente de l'utiliser se trouve ou (physiquement, la dernière classe dans la pile d'erreur se trouve où?)


Ca permettrais déjà de voir si t'essaie de faire quelque chose d'interdit dans le specs.

Aussi, si tu génère le ear dans netbeans, et que tu le déploie manuellement dans un glassfish qui tourne à part de netbeans, l'erreur est toujours là? Les IDE ont parfois tendance, pour permettre des déploiements rapide, à bidouiller un peux le classpath des conteneur j2EE, comme par exemple en leur demandant d'aller chercher directement les classes dans le répertoire de build de l'IDE, ce qui est un peu suspect selon moi

Enfin, pour l'ordre de chargement des classes, ca n'existe pas. La jvm charge ses classes à la demande. T'as besoin de X, elle le charge. Quand elle charge X elle constate que X a besoin de Y elle le charge, etc.


Vérifie aussi que tu ne duplique pas certains classes. Quand on joue avec des EJB on se retrouve vite, par mégarde, à avoir les ejb à la fois dans le EAR et dans le WAR, ce qui fous le bordel car le WAR vois des classes différentes de celles que vois le EAR du coup

[mysianne]

ta classe se trouve ou (physiquement, quel est le path du jar)
et le code qui tente de l'utiliser se trouve ou (physiquement, la dernière classe dans la pile d'erreur se trouve où?)

Je ne comprend pas bien le sens de ta question, Mais je vais repeter ce que j'ai dis précédemment: mon jar et mon war sont tous deux contenu dans le .ear qui provient de la compilation de mon application (sous netbeans)

et le code qui tente de l'utiliser se trouve ou (physiquement, la dernière classe dans la pile d'erreur se trouve où?)

L'exception est levé au déploiement de l'application sur un autre serveur glassfish se trouvant sur une autre machine physique, donc à ma connaissance, il y a pas de code explicitement écrit par moi qui chercherait à utiliser la classe introuvable avant le déploiement complet sous glassfish.

Je te rappelle aussi que chaque fois (en moyenne 3 fois) que j'ai eu cette exception, j'ai du réinstaller glassfish et comme par magie tout est rentré dans l'ordre.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Vérifie aussi que tu ne duplique pas certains classes.

je scrute la hiérarchie des répertoire de mon projet mais en dehors du projet EJB que j'inclus dans mon projet web, il y a même pas une classe portant le même nom.

Une précision qui peut peut-être signifier quelque chose: Ceci arrive en générale après plusieurs redéploiement du projet

[tchize_]

tu peux nous donner le log complet de ton glassfish?

Si c'est un serveur distant (en général on développe avec un serveur local ) c'est peux être simplement que le fichier qui arrive sur le serveur au rédéploiement est incomplet. As-tu été chercher les jar / ear sur ce serveur après l'erreur pour voir si ils sont complets?