Erreur AXIS2 / JAX-WS lors de la non-arshalling Fichier XML avec de grands éléments de texte

Question

Je suis complètement coincé et j'ai besoin de votre aide ... J'ai créé un talon de service Web avec JAXB 2.x pour un service qui envoie un fichier binaire (images JPG codées Base64) dans un message SOAP. Tout a bien fonctionné et j'ai pu recevoir et afficher les images, jusqu'à ce que j'essaye d'exporter l'application Eclipse RCP vers un produit, ce qui a provoqué ImEdiatly LinkageErrors (comme d'habitude, javax.xml.namespace.qname et encore plus).

J'ai pu résoudre ce problème pour «reconditionner» AXIS2 et maintenant tout fonctionne à nouveau bien - sauf l'analyse de la partie de fichier binaire dans le talon, ce qui provoque désormais une exception (élément inattendu).

Un coup d'œil a révélé de plus près que le lecteur (OmStaxWrapper), qui est utilisé dans le stub généré par Axis2-Jaxb, ne lit désormais pas le texte de la base64 mais seulement les 10000 premiers octets. Ensuite, il ne trouve pas la fin correcte de l'élément et lance une exception.

Comme mentionné précédemment - cela ne s'est pas produit au début, donc j'espère que ce n'est qu'un paramètre ou une option. Un grand merci d'avance pour chaque aide ou indice!

ÉditerCe n'était pas Jaxb, j'ai utilisé JAXWS et WSIMPORT pour créer le talon pour le fichier WSDL ...

Answer 1

Pour un peu d'arrière-plan, OmStaxWrapper fait partie d'Axiom, qui est l'utilitaire de streaming personnalisé d'AXIS2 pour les services Web, qu'Axis2 utilise en remplacement de SAAJ. Je ne serais pas extrêmement surpris s'il était buggy, si mon expérience antérieure avec Axis est quelque chose à passer.

Si vous souhaitez envoyer de gros binaires sur du savon, la meilleure technologie pour cela semble être mtom (voir ici pour comment l'utiliser avec axis2). Cela peut mieux optimiser la représentation binaire et votre problème pourrait disparaître. Cependant, le client et le serveur doivent être capables de parler MTOM, donc ce n'est peut-être pas une option pour vous.

Alternativement, il devrait être possible de convaincre AXIS2 d'utiliser l'API SAAJ standard au lieu d'utiliser Axiom. SAAJ est plus lent, mais devrait être moins buggy.

Ma suggestion finale est d'abandonner AXIS2 pour votre client et d'utiliser quelque chose de plus léger. Printemps-ws Fournit une très belle API client, qui est actuellement mon outil de choix pour parler aux services Web distants. Il prend en charge Axiom et Saaj, ainsi que MTOM, et il est suffisamment léger qu'il soit assez facile de savoir pourquoi quelque chose ne va pas.