Axis2 dans servlet

Le Tue, 3 Nov 2009 17:10:17 +0100
"1 connu" <inconnue@bluewin.ch> a écrit :

Bonjour,


J'ai fait une servlet qui accède à un WebService utilisant Axis2. En
dev. ca ce passe bien.

Je l'ai mis sur un serveur Tomcat et j'ai l'erreur suivante :

java.lang.Error: Unresolved compilation problem:
The type org.apache.axis2.AxisFault cannot be resolved. It is
indirectly referenced from required .class files

Pourtant la classe se trouve bien dans axis2-kernel-1.5.jar qui est
bien présent dans /context/WEB-INF/lib.

Merci pour toute aide

Je ne sais pas si ça va aider, mais a priori le message signale une
erreur de *compilation*. Ca voudrait dire qu'il n'a pas pu compiler
ton code parce qu'il ne trouvait pas la classe au moment de la
compilation (et non dans l'appli déployée). Donc normalement tu
devrais avoir une erreur de compilation signalée par ton EDI dans la
classe concernée, revérifie.

Et sinon je sais pas désolé. Mais ça ne ressemble pas à un message de
classe/jar manquant lors de l'exécution (ClassNotFoundException ou
quelque chose du genre).

Euh... tout ça si je ne dis pas de bêtise et qu'il n'est pas en train
d'essayer de compiler quelque chose dans l'appli déployée. Je ne
connais pas Axis, est-ce qu'il est censé compiler quelque chose la
première fois que tu utilises la classe fautive (celle qui indique
une erreur) ? Dans la pile d'appel, est-ce bien un de tes classes qui
signale l'erreur ou est-ce une classe d'Axis, qui pourrait se trouver
dans un autre jar ?

merci pour tes remarques.

J'ai pas d'erreur de compilation sur ma machine de dev.
Je ne connais rien à Axis (sacré usine à gaz) mais je suis une API fourni par le fournisseur du WebService
http://eutils.ncbi.nlm.nih.gov/entrez/query/static/esoap_java_help.html

c'est la ligne EFetchPubmedServiceStub service = new EFetchPubmedServiceStub();
qui plante dans l'exemple "Using WebEnv & QueryKey example"

J'ai placé l'équivalent de ce code dans le doGet de ma servlet.

Pierre



"Yliur" <yliur@free.fr> a écrit dans le message de news: 20091103211722.6e8d6de5@alcheringa...
Le Tue, 3 Nov 2009 17:10:17 +0100
"1 connu" <inconnue@bluewin.ch> a écrit :

Bonjour,


J'ai fait une servlet qui accède à un WebService utilisant Axis2. En
dev. ca ce passe bien.

Je l'ai mis sur un serveur Tomcat et j'ai l'erreur suivante :

java.lang.Error: Unresolved compilation problem:
The type org.apache.axis2.AxisFault cannot be resolved. It is
indirectly referenced from required .class files

Pourtant la classe se trouve bien dans axis2-kernel-1.5.jar qui est
bien présent dans /context/WEB-INF/lib.

Merci pour toute aide

Je ne sais pas si ça va aider, mais a priori le message signale une
erreur de *compilation*. Ca voudrait dire qu'il n'a pas pu compiler
ton code parce qu'il ne trouvait pas la classe au moment de la
compilation (et non dans l'appli déployée). Donc normalement tu
devrais avoir une erreur de compilation signalée par ton EDI dans la
classe concernée, revérifie.

Et sinon je sais pas désolé. Mais ça ne ressemble pas à un message de
classe/jar manquant lors de l'exécution (ClassNotFoundException ou
quelque chose du genre).

Euh... tout ça si je ne dis pas de bêtise et qu'il n'est pas en train
d'essayer de compiler quelque chose dans l'appli déployée. Je ne
connais pas Axis, est-ce qu'il est censé compiler quelque chose la
première fois que tu utilises la classe fautive (celle qui indique
une erreur) ? Dans la pile d'appel, est-ce bien un de tes classes qui
signale l'erreur ou est-ce une classe d'Axis, qui pourrait se trouver
dans un autre jar ?

Le Wed, 4 Nov 2009 09:55:38 +0100
"1 connu" <inconnue@bluewin.ch> a écrit :

merci pour tes remarques.

J'ai pas d'erreur de compilation sur ma machine de dev.
Je ne connais rien à Axis (sacré usine à gaz) mais je suis une API
fourni par le fournisseur du WebService
http://eutils.ncbi.nlm.nih.gov/entrez/query/static/esoap_java_help.html

c'est la ligne EFetchPubmedServiceStub service = new
EFetchPubmedServiceStub(); qui plante dans l'exemple "Using WebEnv &
QueryKey example"

J'ai placé l'équivalent de ce code dans le doGet de ma servlet.

Pierre

As-tu la pile complète (au moins le dessus de la pile, jusqu'à la
ligne que tu cites) ?

Le Wed, 4 Nov 2009 10:45:57 +0100
"1 connu" <inconnue@bluewin.ch> a écrit :

Tu vois qqchose d'intéressant
là-dedans ?MerciPierrejavax.servlet.ServletException: Error
instantiating servlet class midapi.pubmed.PubMedServlet
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java: 105)
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:14 8)
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.proce ssConnection(Http11BaseProtocol.java:664)
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint. java:527)
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowe rWorkerThread.java:80)
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool. java:684)
java.lang.Thread.run(Thread.java:595)

root cause

java.lang.Error: Unresolved compilation problem:
The type org.apache.axis2.AxisFault cannot be resolved. It is
indirectly referenced from required .class files

midapi.pubmed.PubMedServlet.<init>(PubMedServlet.java:37)
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAc cessorImpl.java:39)
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConst ructorAccessorImpl.java:27)
java.lang.reflect.Constructor.newInstance(Constructor.java:494)
java.lang.Class.newInstance0(Class.java:350)
java.lang.Class.newInstance(Class.java:303)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java: 105)
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:14 8)
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.proce ssConnection(Http11BaseProtocol.java:664)
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint. java:527)
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowe rWorkerThread.java:80)
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool. java:684)
java.lang.Thread.run(Thread.java:595)

Si PubMedServlet est ta Servlet, effectivement on n'apprend pas grand
chose...

Tu as bien regardé s'il n'y avait pas des problèmes de compilation au
niveau du projet (des bibliothèques non trouvées, ...) ? Par exemple
dans Eclipse ça apparaît dans le fenêtre des "Problèmes", sans
affecter de classes particulières. Parfois ça empêche la
recompilation de certaines classes me semble-t-il...

Le jar d'Axis que tu as mis dans ton appli, c'est la version officielle
non modifiée ? Est-ce que toutes tes bibliothèques Axis sont dans
l'appli et rien au niveau du serveur Tomcat ? Et le jar que tu
déploies, c'est exactement le même que celui que tu as en
développement ? Tu poses l'appli telle quelle dans le Tomcat de
"production" et ça ne marche plus ou tu utilises une procédure de
déploiement plus compliquée ?

Et en mettant les bibliothèques d'Axis au niveau de Tomcat plutôt que
dans les bibliothèques de l'appli ?

D'après le message on dirait que c'est la classe que tu utilises qui
est mal compilée (si ce n'est pas ton projet ; tu n'utilises ni ne
références jamais le classe org.apache.axis2.AxisFault dans ta
Servlet ?).

Ou alors Axis compile des trucs la première fois qu'il en a besoin et
quelque chose s'est mal passé parce qu'il n'a pas trouvé les
bibliothèques nécessaires. Et il n'y a rien dans les journaux de
Tomcat (ou d'Axis, s'il écrit dans ses propres journaux) ?

> >Est-ce que toutes tes bibliothèques Axis sont dans l'appli et rien
>au niveau du serveur Tomcat ?

Ils sont tous dans l'appli dans les lib de mon appli.
Dans le serveur de prod, je ne peux rien placer en commun.
Par contre, j'ai vu dans /common/lib de la prod. : wsdl4j-1.5.1.jar
alors que j'utilise wsdl4j-1.6.2.jar dans le lib de mon appli

il y a aussi un /common/endorsed/xercesImpl.jar alors que j'utilise
xercesImpl-2.6.2.jar dans les miens.

Ils doit se mélanger les pinceaux. Les miens ne sont ils pas sensés
être pris en premier ?

A vérifier dans la doc de Tomcat ou en faisant un essai, mais
justement je crois que les bibliothèques partagées sont prioritaires.
Tu dis que tu ne peux rien modifier en prod, mais tu peux peut-être
récupérer le répertoire common qui se trouve là-bas et le mettre chez
toi ? Ca te permettra de voir si le problème apparaît à ce moment et
de faire des tests plus proches de la réalité chez toi (ça peut ê tre
dans un deuxième Tomcat, séparé de celui que tu utilises pour le
développement).

Le Thu, 5 Nov 2009 10:34:11 +0100
"1 connu" <inconnue@bluewin.ch> a écrit :

"Yliur" <yliur@free.fr> a écrit dans le message de news:
20091104183006.2224d060@alcheringa...


>Tu dis que tu ne peux rien modifier en prod, mais tu peux peut-être
> récupérer le répertoire common qui se trouve là-bas et le mett re
> chez toi ? Ca te permettra de voir si le problème apparaît à ce
> moment et de faire des tests plus proches de la réalité chez toi
> (ça peut être dans un deuxième Tomcat, séparé de celui que tu
> utilises pour le développement).

Merci pour ton aide et tes idées.
J'ai testé dans le Tomcat de dev. en rajoutant les 2 jars xercesImpl
et wsdl4j et ca marche encore !! Peux être qu'il y a encore d'autres
que j'ai pas vu.

Je me demande si c'est pas le 1ier qui tire qui a raison.
Si mon appli est lancé en 1ier, elle utilise mes jars propres sinon
elle utilise les communs déja chargés si d'autres appli utilisent
Axis.

Pierre

Et tu ne peux pas récupérer tout le Tomcat de production chez toi
pour un test, histoire d'être sûr ? Ca pourrait être un autre jar ?
Il faudrait être certain d'avoir la même version de Tomcat, la même
configuration ($TOMCAT/conf) et les mêmes bibliothèques
($TOMCAT/common, je crois que c'est tout mais pas certain...). Et
d'utiliser la même procédure de déploiement.

Pour le "1er qui tire" je ne pense pas, il me semble qu'il y a un ordre
précis pour rechercher les classes et que chaque appli peut utiliser
des classes différentes (un chargeur de classe différent pour chaque
appli web)

> >>>>>>>>>
Pour le "1er qui tire" je ne pense pas, il me semble qu'il y a un
ordre précis pour rechercher les classes et que chaque appli peut
utiliser des classes différentes (un chargeur de classe différent
pour chaque appli web)
>>>>>>>>
Effectivement tu as raison, c'est ce que dit la
doc(http://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html) ,les
classes et jars de l'appli sont utilisés avant les communs. Par
contre les extensions de la JVM sont les tous premiers C'est p-e ca
qui fait la différence ..... a.. Bootstrap classes of your JVM b..
System class loader classes (described above) c.. /WEB-INF/classes of
your web application d.. /WEB-INF/lib/*.jar of your web application
e.. $CATALINA_HOME/common/classes
f.. $CATALINA_HOME/common/endorsed/*.jar
g.. $CATALINA_HOME/common/i18n/*.jar
h.. $CATALINA_HOME/common/lib/*.jar
i.. $CATALINA_BASE/shared/classes
j.. $CATALINA_BASE/shared/lib/*.jar

Tu as essayé de recopier tout ça dans ton Tomcat de développement ? Il
se peut que ça soit là-dedans et que tu l'aies manqué quand tu as
simplement recopié deux jars.