Discussion :

[Wilgard]

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.


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:


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

[Laurent.B]

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.

[Wilgard]

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...

[Laurent.B]

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 ?

[Wilgard]

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 :


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



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 :

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

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>

[Wilgard]

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.


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.