Un peu à l'avance info:
J'ai un service de savon (hébergé à l'aide de JAX-WS (classe de terminaison), mais je ne pense pas que ce soit important). P>
Je peux me connecter à et utilisez le service Web tout simplement bien avec Visual Studio générant le client (C #). P>
J'ai généré un client Java utilisant Eclipse Web Tools (New -> Autres -> Services Web -> Services Web -> Services Web ). P>
Puis j'ai écrit un test Junit pour tester le client. Le test passe, mais il faut une période extrêmement longue pour courir. Chaque appel de service prend 300 secondes (donner ou prendre quelques secondes). En outre, peu importe la rapidité avec laquelle l'ordinateur est rapide. Si j'exécute cela sur mon ordinateur portable de travail très lent, il faut le même temps que si je l'exécute sur ma machine à domicile rapide. p>
J'ai débogué dans le code de l'axe à la fonction suivante dans Org.apache.axis.encoding.deserializationContext: P>
BasicClientConfig basicClientConfig = new BasicClientConfig(); SimpleChain simpleChain = new SimpleChain(); simpleChain.addHandler(new CommonsHTTPSender()); basicClientConfig.deployTransport("http", simpleChain); ExecuterServiceLocator l = new ExecuterServiceLocator(basicClientConfig); ...
4 Réponses :
Très probablement un délai d'attente. Pourrait être cet analyseur essayant de télécharger quelque chose d'Internet (DTD, XSD, etc.), mais vous êtes derrière un proxy / pare-feu. p>
Essayez de prendre la trace de pile du serveur, lors de l'exécution du test pour voir ce qui se passe (par exemple JPS / JStat). P>
J'ai vécu cela à la maison et au travail. De plus, je suis sûr que le serveur n'est pas le problème, car il est rapide lorsqu'un client généré par un studio visuel l'appelle.
1) Vérifiez que les clients C # et Java envoient exactement les mêmes demandes au serveur. Si vous utilisez une jetée, allumez La journalisation de la requête vous donnerait probablement la données dont vous avez besoin. p>
2) Une fois que l'analyseur SAX commence à s'exécuter sur le client, il va faire des rappels qui se termineront - directement ou indirectement - invoquer des méthodes dans votre client généré. Vous devriez être capable de définir des points d'arrêt au début et à la fin (et / ou (BTW, dans l'API SAX, les URL telles que retourner code> s) des méthodes client générées et utilisez-les pour déterminer où le délai [S] arrive [S]. p>
http://xml.org/sax/properties/lexical-handler code> sont utilisées localement pour identifier les noms de propriété; rien ne va chercher rien à cette adresse. Voir http://xerces.apache.org/xerces2-j/ Propriétés.html Pour plus d'informations.) P>
Cela m'a conduit à la bonne réponse. J'ai mis à jour ma question pour montrer comment je l'ai réparé au cas où quelqu'un se demande.
Votre problème est exactement ce que je suis confronté maintenant. Et drôle, j'ai traversé à peu près le même cycle (du service de fin du point de terminaison, le client .Net fonctionne bien et la clientèle générée par Eclipse prenant une bonne 5 minutes à traiter). Merci, en effet, pour avoir publié les mises à jour et la solution. Je ne suis pas une avertissement Java, alors puis-je demander si vous avez appliqué la solution au même code client généré par Eclipse? Ou avez-vous fait quelque chose de complètement différent? Si vous avez modifié le code client généré par Eclipse, où avez-vous ajouté exactement ces lignes? P>
Merci et et j'apprécie vraiment l'aide :) p>
acclamations, Arash p>
Le code que j'ai affiché pour le faire fonctionner est ce que vous mettrez à l'intérieur de votre code pour instancier l'accesseur de service Web. Vous n'avez pas besoin de changer de code généré. Si vous allez réellement appeler le service, vous devez ajouter ce gestionnaire HTTP lorsque vous créez un service de service.
Merveilleux :) merci beaucoup. Cela fonctionne parfaitement maintenant. Je voterai très certainement votre question dès que ma réputation atteint 15: D
J'ai eu le même problème et j'ai résolu la modification de la version HTTP.
Un moyen plus simple de cela est, à l'intérieur de la classe de stub, appelant la méthode SetProperty sur l'instance d'appel: P>
_call.setProperty(MessageContext.HTTP_TRANSPORT_VERSION,HTTPConstants.HEADER_PROTOCOL_V11);
Pourrait-il que vous ayez un problème avec l'URL ( xml.org/sax/properties/lexical- Handler ) Et vous frappez un délai d'attente après 5 minutes? Expliquerait pourquoi cela prend toujours la même période, quelle que soit la vitesse de l'ordinateur.
Je suppose que cela pourrait être que, mais je reçois toujours les valeurs de retour correctes, ce qui semble bizarre.
Une autre chose qui me fait penser que ce n'est pas un délai d'expiration de l'URL est que la demande réelle y arrive rapidement. Je peux voir le serveur exécutant la commande immédiatement.
Cette URL 404S lorsque vous le frappez avec un navigateur. Je fais une tonne de fonctionnement du client SOAP avec un code généré par Eclipse. 300 secondes est trop propre un nombre de retard pour être tout sauf un délai d'attente. Le WSDL est-il utilisé publiquement visible? Pouvez-vous le poster?
Je conviens que c'est probablement un délai d'attente, mais je pense que cela pourrait être un délai d'attente sur une prise de courant.
Je viens d'essayer de faire la même chose avec un service hébergé à l'aide de Visual Studio et cela fonctionnait parfaitement. Ce doit être une interaction étrange entre le service Axis et le client Web Tools.