Web Service Client, plantage du Wizard, comment débuger le WSDL ?

Bonjour,

J'essaie de générer un proxy java à partir d'un WSDL. Jusque là rien de très particulier. Par contre ce que je ne comprends pas et là où je suis bloqué c'est que lorsque je remplis le champ avec l'URL du WSDL la validation ne fonctionne pas. Je fais exactement les même étapes que ce tutoriel : http://px.pats.no/px/Eclipse_tutorial.html

Et là j'obtiens ces erreurs lors de la vérification.
http://www.developpez.net/forums/att...1&d=1345138807

Du coup je désactive la vérification dans les options d'Eclipse et je retente l'expérience. Sauf qu'à la génération des classes du jar, j'obtiens cette erreur:
http://www.developpez.net/forums/att...1&d=1345138829

Du coup je dirais que le problème vient du WSDL, mais comment savoir ce qui veut pas ? Il n'y a pas de debugging de possible vu que j'utilise le wizard d'éclipse ! Je suis perdu et ne sais quoi faire.

Quelqu'un aurait-il une technique pour me dire comment trouver ce qui génère cette erreur de NullPointerException ?

Je vous remercie par avance.

Je travaille sous Windows 7 avec :
Eclipse Java EE IDE for Web Developers.
Version: Indigo Service Release 2
Build id: 20120216-1857

Bonjour,

Tu peux faire confiance aux warnings, ils indiquent précisément le problème.

Le WSDL lui est probablement valide, seulement il n'est pas auto-suffisant, il est visiblement composé de schémas XSD, lesquels doivent également être présents aux endroits indiqués par les URL.

Voilà, donc à toi de te débrouiller pour faire en sorte que les fichiers XSD requis soient placés aux endroits indiqués.

Merci Laurent.B pour ta réponse,

le problème c'est qu'en recherchant toutes les occurrences du wsdl concerné sur le server il y a bien l'ensemble des fichiers xsd (ceux affichés dans les warnings) dans le même répertoire que le fichier wsdl.

Donc soit il s'agit d'un problème d'accès au répertoire, mais n'étant pas admin système je ne sais pas ce qu'il faudrait ajouter comme privilège.

Du coup c'est pas la proposition 1 car les fichiers sont bien présents au même endroit que le wsdl. la proposition 2 c'est qu'il arrive pas à les lire. Ca pourrait être ça mais normalement rien n'interdit l'accès en lecture.
la proposition 3 c'est que le root node des fichiers xsd ne serait pas xsd:schema.
Or c'est bien le cas pour tous ceux qui sont listés.

J'ai pas d'idée...

Mais si tu rapatries tous ces fichiers dans un projet Eclipse et que tu fais la validation du WSDL, cela fonctionne-t-il ?
Les import/include de schémas présents dans le WSDL, sont-ils conformes à ce qui est attendu au niveau des chemins ?

Ah non je je n'ai pas testé mais il me semblait que l'adresse du WSDL passé en paramètre ne pouvait être qu'une URL en http et non locale du type D:\Workspace\Eclipse\JWebServiceClient\wsdl\dataExchangeService.wsdl

à ce moment là les boutons next et finish sont grisés :
http://www.developpez.net/forums/att...1&d=1345457036

et si je fais browse ca me dit que l'url doit être un wsdl:

http://www.developpez.net/forums/att...1&d=1345457077

Du coup pour générer un proxy depuis le wsdl et les xsd en local je ne sais pas faire.

Si tu sais comment faire je suis preneur.

Concernant la location des xsd, ils sont bien dans le même répertoire que le wsdl et dans la définition du wsdl c'est précisé que c'est en local par exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

<xsd:schema targetNamespace="http://bank.net/bank/common" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:include schemaLocation="common.xsd"/> </xsd:schema>   <xsd:schema xmlns:common="http://bank.net/bank/common">   <xsd:import namespace="http://bank.net/bank/common" schemaLocation="common.xsd"/>   ....   </xsd:schema>

---

Bon alors j'ai copié les fichiers en local dans le projet et la du coup on peut charger le WSDL. Je ne comprends pas trop pourquoi une adresse absolue ne passe pas alors qu'une locale oui mais bon.

Du coup j'ai ça comme erreur.
http://www.developpez.net/forums/att...1&d=1345469886

Du coup effectivement même si l'admin système me dit qu'il a les droits comme il faut pour accéder au fichier c'était bien un problème de droits.

Par contre je sais pas comme résoudre ce problème de nullPointer car si je passe la vérification je me retrouve avec la même stacktrace présente dans mon premier message.

Bien...

Les warnings WS-I sont beaucoup moins gênants et le contenu du WSDL n'est pas de ton ressort j'imagine... mais par contre, bizarrement il y a un plantage de la vérification, pour un raison qui est difficile à connaître à ce niveau-là.

Sinon, avant de lancer la génération, il faut effectuer la validation du WSDL (clic droit > Validate) et de cette manière tu devrais savoir où sont les erreurs et les warnings. Il y a peut-être des histoires de version quelque part...

Côté serveur, si ce n'est pas un problème d'URL, alors c'est que la configuration du serveur n'autorise pas l'accès aux fichiers *.xsd, a contrario des fichiers *.html, *.wsdl ...
Pour en être sûr, il suffit de taper leur adresse dans ton navigateur web.

Il serait préférable de copier/coller les messages d'erreur plutôt que d'en faire des screenshots, c'est plus pratique pour les moteurs de recherche...

Alors

Si je fais un validate comme tu le préconises cela me donne la même chose à savoir un seul warning :

Citation:

---

Description Resource Path Location Type
WS-I: A problem occured while running the WS-I WSDL conformance check: org.eclipse.wst.wsi.internal.analyzer.WSIAnalyzerException: null
------------------------------------------------------------------------------
Nested exception is:

java.lang.NullPointerException
The WSDLAnalyzer was unable to validate the given WSDL File. dataExchangeService.wsdl /JWebServiceClient/wsdl line 1 WSDL Problem

---

Or si tu regardes le fichiers WSDL les premières sont :

Code:

---

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

<?xml version="1.0" encoding="UTF-8"?> <wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:soapwsdl="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://dataExchange.soa.bank.net" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="dataExchangeService" targetNamespace="http://dataExchange.soa.bank.net">

---

Du coup en cherchant sur le net j'ai trouvé qu'ils recommandent d'utiliser wsdl2java.exe en ligne de commande via le post suivant : http://fusesource.com/forums/thread.jspa?messageID=3938

Du coup j'ai utilisé Apache CXF.
Je le lance via la commande :

Citation:

---

wsdl2java -client -all -impl -compile -verbose -d "D:\Workspace\Eclipse\JWebServiceClient\src" D:\Workspace\Eclipse\JWebServiceClient\wsdl\dataExchangeService.wsdl

---

Et la ça me génère bien tout un tas de .class et .java.

Que je peux voir et utiliser dans mon projet. Mais ça va pas me poser de problème de compil vu que j'ai pas de jar associé ? et aussi comment savoir que tout s'est bien passé et qu'aucune classe n'a été omise ou mal importée ? Car même en -verbose les seul logs que j'ai c'est ça :

Citation:

---

Loading FrontEnd jaxws ...
Loading DataBinding jaxb ...
wsdl2java -client -all -impl -compile -verbose -d D:\Workspace\Eclipse\JWebServiceClient\src D:\Workspace\Eclipse\JWebServiceClient\wsdl\dataExchangeService.wsdl
wsdl2java - Apache CXF 2.6.1

---

CXF est effectivement une bonne option... Cherche bien parmi ses options, il doit quand même y avoir de quoi afficher plus d'informations je pense.

Pourquoi penses-tu avoir des problèmes de compilation ?

Pour le simple fait que je n'ai pas de fichier .jar associé. Mais le fait d'avoir l'ensemble des .class et .java revient au même je crois.

Ce qui m'embête c'est de ne pas savoir si la génération de fichier s'est bien passée étant donné que la validation c'est justement mal passée. Rien ne me dit que certes classes soient mal générées ou même ignorées.

Sinon comment je peux configurer le Server pour qu'il autorise l'accès aux xsd ?

Citation:

---

Sinon comment je peux configurer le Server pour qu'il autorise l'accès aux xsd ?

---

Citation:

---

Envoyé par Wilgard

même si l'admin système me dit qu'il a les droits comme il faut pour accéder au fichier c'était bien un problème de droits.

---

C'est une histoire de droits donc, comment le sais-tu ?

C'est à l'admin système qu'il faut en parler et la configuration dépend du type de serveur...

Je pense qu'il s'agit une histoire de droits car il n'y a qu'un seul utilisateur qui a les droits pour parcourir les répertoires contenant les wsdl et xsd.
Pour les autres ça ne fonctionne pas. Du coup il a mis les droits pour que n'importe quel utilisateur puisse parcourir les répertoires. Mais la je pense qu'on fait fausse route car là je parle de droits Windows rien à voir avec les droits de restrictions qui peuvent se trouver côté server.

Si je tape l'adresse des fichiers wsdl et xsd dans le navigateur ils s'affichent bien. Donc ils sont consultable depuis un autre poste.

Citation:

---

Envoyé par Wilgard

Je pense qu'il s'agit une histoire de droits car il n'y a qu'un seul utilisateur qui a les droits pour parcourir les répertoires contenant les wsdl et xsd.

---

En fait, je ne pensais pas du tout aux droits du filesystem mais aux droits de diffuser, par le serveur web, des fichiers autres que *.html, *.wsdl dont je t'ai parlé au début. Ca peut produire le même effet mais il est possible de paramétrer spécifiquement le serveur web pour lui indiquer ce qu'il a le droit de diffuser ou non et ne pas simplement s'appuyer sur les droits qui lui sont accordés par le filesystem.

Citation:

---

Envoyé par Wilgard

Si je tape l'adresse des fichiers wsdl et xsd dans le navigateur ils s'affichent bien. Donc ils sont consultable depuis un autre poste.

---

Ah ben voilà ! Donc non, ce n'est pas une histoire de droits mais c'est dommage parce que du coup, ça reste un mystère...

Par contre, dans ton premier screenshot il manque une partie des détails warnings... Peut-être qu'ils ont leur importance.

Sinon, avec CXF tu dois pouvoir générer de la même manière avec l'URL du fichier WSDL distant, as-tu essayé ? Et ne te laisse pas déconcerter par le fait qu'il termine sa tâche en restant laconique, si ça ne fonctionne pas, il te l'indique à mon avis.

Alors concernant les autres warnings je n'ai pas mis le début de la liste c'est toujours le même warning à savoir qu'il n'arrive pas à accéder aux autres xsd, il n'y a que la dernière ligne qui change. Faudrait que je puisse faire un Validate sur l'URL du wsdl pour pouvoir faire un copier coller de l'ensemble des warnings.

Par contre ce qui est étrange c'est que par 3 fois il me demande de me connecter au server via cet écran Pièce jointe 101125.

Et malgré que j'arrive à accéder au contenu du wsdl via le navigateur j'ai toujours cet écran qui revient lui aussi 3 fois avant que je puisse faire browse.
Pièce jointe 101126

Du coup si j'essaie de générer les .class et .java depuis l'URL et non depuis le fichier copié en local j'ai l'erreur suivante :

Citation:

---

wsdl2java - Apache CXF 2.6.0


WSDLToJava Error: org.apache.cxf.wsdl11.WSDLRuntimeException: Fail to create wsdl definition from : http://192.168.1.76:9081/exchange/Da...geService.wsdl
Caused by : WSDLException: faultCode=PARSER_ERROR: Problem parsing 'http://192.168.1.76:9081/exchange/DataExchangeService.wsdl'.: java.io.IOException: Server response code: 401 for URL: http://192.168.1.76:9081/exchange/Da...geService.wsdl

org.apache.cxf.tools.common.ToolException: org.apache.cxf.wsdl11.WSDLRuntimeException: Fail to create wsdl definition from : http://192.168.1.76:9081/exchange/Dvice.wsdl
Caused by : WSDLException: faultCode=PARSER_ERROR: Problem parsing 'http://192.168.1.76:9081/exchange/DataExchangeService.wsdl'.: java.io.IOException: Server response code: 401 for URL: http://192.168.1.76:9081/exchange/Da...geService.wsdl
at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:293)
at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:103)
at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113)
at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:86)
at org.apache.cxf.tools.wsdlto.WSDLToJava.main(WSDLToJava.java:184)
Caused by: org.apache.cxf.wsdl11.WSDLRuntimeException: Fail to create wsdl definition from : http://192.168.1.76:9081/exchange/Da...geService.wsdl
Caused by : WSDLException: faultCode=PARSER_ERROR: Problem parsing 'http://192.168.1.76:9081/exchange/DataExchangeService.wsdl'.: java.io.IOException: Server response code: 401 for URL: http://192.168.1.76:9081/exchange/Da...geService.wsdl
at org.apache.cxf.wsdl11.WSDLDefinitionBuilder.parseWSDL(WSDLDefinitionBuilder.java:97)
at org.apache.cxf.wsdl11.WSDLDefinitionBuilder.build(WSDLDefinitionBuilder.java:69)
at org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.JAXWSDefinitionBuilder.build(JAXWSDefinitionBuilder.java:82)
at org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.JAXWSDefinitionBuilder.build(JAXWSDefinitionBuilder.java:59)
at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:170)
at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:139)
at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:285)
... 4 more
Caused by: javax.wsdl.WSDLException: WSDLException: faultCode=PARSER_ERROR: Problem parsing 'http://192.168.1.76:9081/exchange/DataExchangeService.wsdl'.: java.: Server returned HTTP response code: 401 for URL: http://192.168.1.76:9081/exchange/Da...geService.wsdl
at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:244)
at org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java:191)
at org.apache.cxf.wsdl11.WSDLDefinitionBuilder.parseWSDL(WSDLDefinitionBuilder.java:78)
... 10 more
Caused by: java.io.IOException: Server returned HTTP response code: 401 for URL: http://192.168.1.76:9081/exchange/Da...geService.wsdl
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1436)
at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:677)
at com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocVersion(XMLVersionDetector.java:186)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:772)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119)
at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:235)
at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:284)
... 16 more

---

Donc là typiquement faut passer les paramètres d'authentification mais visiblement les options -U et -P que je pensais disponibles http://ws.apache.org/axis/java/reference.html n'existent finalement pas d'après l'ensemble des options disponiblent:

Code:

---

1 2 3 4 5 6

Usage : wsdl2java -fe|-frontend <front-end-name> -db|-databinding <data-binding-name> -wv <wsdl-version> -p <[wsdl-namespace =]package-name>* -sn <service-name> ile-name>* -reserveClass <class-name>* -catalog <catalog-file-name> -d <output-directory> -compile -classdir <compile-classes-directory> -impl -server -client - esolution -allowElementReferences|-aer<=true> -defaultValues<=class-name-for-DefaultValueProvider> -ant -nexclude <schema-namespace [= java-package-name]>* -exs e)> -noTypes -dns <Default value is true> -dex <(true, false)> -validate -keep -wsdlLocation <wsdlLocation> -xjc<xjc-arguments>* -asyncMethods<[=method1,method2 ethods<[=method1,method2,...]>* -mimeMethods<[=method1,method2,...]>* -noAddressBinding -faultSerialVersionUID <fault-serialVersionUID> -exceptionSuper <excepti -generated -h|-?|-help -version|-v -verbose|-V -quiet|-q|-Q -wsdlList <wsdlurl>

---

Bien sûr, si je rajoute en dur le login et le password de la manière suivante :
http://login:password@192.168.1.76..... ca ne fonctionne pas plus et l'erreur reste identique.

Ok... il faut s'authentifier auprès du serveur, à toi de trouver comment, là moi je ne peux pas trop t'aider.

Quand aux détails manquants, je parlais des fins de lignes des warnings. On voit que les messages sont tronqués alors qu'ils semblent énumérer les différentes causes possibles.

Ok désolé j'avais mal compris voici la ligne des warnings en entier.Pièce jointe 101135.

Bon, pour le log, ok, ça n'apporte rien (et tu aurais sans doute pu coller le texte plutôt que de faire un screenshot !!).
En fait, le warning explique qu'il n'a pas obtenu ce qui est attendu, puisque la réponse à la requête demandant le fichier pointé par l'URL, est un erreur 401, expliquant qu'il faut d'abord s'identifier !

Je ne sais pas si tu peux fournir le login/password avec l'assistant d'Eclipse.

A mon avis le mieux est de faire avec CXF. J'ai bien compris que tu as déjà tenté avec les options -U -P mais il faut persévérer dans ce sens je pense.

JAXB n'a rien à voir à ce niveau-là. Les WSDL et les XSD n'ont aucun lien avec cette API (les WebServices n'étant pas propres à Java !). Par contre, c'est à JAXB de déterminer la manière de les exploiter pour produire le code Java adéquate. Ce qui peut se faire que lorsqu'il a pu avoir accès aux WSDL et XSD.

Par contre, il y a un truc étrange, comment l'assistant peut-il avoir accès au WSDL et pas aux XSD ? Le WSDL est censé être soumis à la même nécessité d'authentification préalable... :koi:

Oui en effet il me dit qu'il a pas accès mais il arrive à lire les dépendances et donc le contenu.
Pour le screenshot c'est justement parce que le copier/coller ne fonctionne pas sur cet écran.

Pour la génération du code ça fonctionne via wsdl2java mais aussi via wsimport, là j'ai pas compris la différence entre les 2 executables.

Par contre je viens de me rendre compte d'une chose c'est que le wsdl2java que j'utilise vient du CXF d'Apache et cela ne me génère pas le même code que si j'utilise le wsimport du server d'application WebSphere qui fait tourner le wsdl.

Donc pour faire tourner mon client java j'ai récupéré les jar du le server d'application donc beaucoup de com.ibm.ws.*

L'exécution du programme fonctionne bien sauf quand j'arrive au :

Code:

---

1 2	DataExchangeService_Service ss = new DataExchangeService_Service(wsdlURL, SERVICE_NAME); DataExchangeService port = ss.getDataExchangeServicePort();

---

le getDataExchangeServicePort lance une exception du type:

Code:

---

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

Exception in thread "main" javax.xml.ws.WebServiceException: Unable to create JAXBContext at com.sun.xml.internal.ws.model.AbstractSEIModelImpl.createJAXBContext(AbstractSEIModelImpl.java:153) at com.sun.xml.internal.ws.model.AbstractSEIModelImpl.postProcess(AbstractSEIModelImpl.java:83) at com.sun.xml.internal.ws.model.RuntimeModeler.buildRuntimeModel(RuntimeModeler.java:244) at com.sun.xml.internal.ws.client.WSServiceDelegate.createSEIPortInfo(WSServiceDelegate.java:687) at com.sun.xml.internal.ws.client.WSServiceDelegate.addSEI(WSServiceDelegate.java:675) at com.sun.xml.internal.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:330) at com.sun.xml.internal.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:313) at com.sun.xml.internal.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:295) at javax.xml.ws.Service.getPort(Service.java:92) at dataexchange.DataExchangeService_Service.getDataExchangeServicePort(DataExchangeService_Service.java:47) at client.MyFirstWebService.main(MyFirstWebService.java:51) Caused by: java.security.PrivilegedActionException: com.sun.xml.internal.bind.v2.runtime.IllegalAnnotationsException: 5 counts of IllegalAnnotationExceptions There's no ObjectFactory with an @XmlElementDecl for the element {http://www.bank.net/folio}portfolio. this problem is related to the following location:

---

Alors qu'il y a bien un element de ce type dans le ObjectType.java associé.
J'ai trouvé un poste similaire en terme d'erreur ici :http://old.nabble.com/There's-no-ObjectFactory-with-an-@XmlElementDecl-for-the-element-td12798615.html

Mais je ne vois pas non plus ce qu'il faudrait mettre dans le getResult.

Citation:

---

Envoyé par Wilgard

ça fonctionne via wsdl2java mais aussi via wsimport, là j'ai pas compris la différence entre les 2 executables

---

Deux outils similaire mais avec des implémentations différentes, donc fournissant des résultats différents, ce qui semble assez logique.

Au niveau compatibilité je ne sais pas trop ce que ça donne, désolé...

Pour info, la différence entre les deux c'est que wsimport c'est pour faire du XML basé sur des appels Web Services alors que wsdl2java c'est pour des appels RPC.