Erreur Axis2/JAX-WS lors d'unmarshalling fichier xml avec des éléments de texte volumineux

Question

Je suis complètement bloqué 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 encodées en base64) dans un message de savon. Tout a bien fonctionné et j'ai pu recevoir et afficher les images, jusqu'à ce que j'essaie d'exporter l'application RCP eclipse vers un produit, ce qui a causé immédiatement LinkageErrors (comme d'habitude, javax.xml.namespace.QName et quelques autres).

J'ai été capable de résoudre ce problème de 'rebundle' axis2 et maintenant tout fonctionne correctement - sauf l'analyse de la partie du fichier binaire dans le stub, qui provoque maintenant une exception (élément inattendu). Un examen plus attentif a révélé que le lecteur (OMStAXWrapper), utilisé dans le Stub généré par axis2-jaxb, ne lit désormais pas tout le texte base64 mais seulement les 10000 premiers octets. Ensuite, il ne trouve pas la fin correcte de l'élément et déclenche une exception.

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

Modifier Il n'a pas été JAXB, j'ai utilisé JAXWS et wsimport pour créer le talon pour le fichier wsdl ...

Answer 1

Pour un peu de fond, OMStAXWrapper fait partie de Axiom, qui est la coutume de Axis2 Utilitaire de streaming pour les services Web, utilisé par Axis2 en remplacement de SAAJ. Je ne serais pas énormément surpris s'il était buggé, si mon expérience antérieure avec Axis est quelque chose à faire. Si vous voulez envoyer des binaires volumineux sur SOAP, la meilleure technologie pour ce moment semble être MTOM (voir here pour savoir 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, ce qui peut ne pas être 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 bogué.

Ma dernière suggestion est d'abandonner Axis2 pour votre client, et d'utiliser quelque chose de plus léger. Spring-WS fournit une API client très agréable, qui est actuellement mon outil de choix pour parler à des services Web à distance. Il supporte Axiom et SAAJ, ainsi que MTOM, et il est suffisamment léger pour qu'il soit facile de savoir pourquoi quelque chose ne va pas.