Est-ce que l'implémentation JAX-WS est incluse avec Java?

Question

Je possède une application de service web JAX-WS qui se déploie comme un fichier WAR pour Tomcat 7. Elle utilise une version récente des bibliothèques Metro, que j'inclus à l'intérieur du fichier WAR, et cela fonctionne très bien.

Je cherche à simplifier le package de déploiement. Je comprends que le JDK Sun inclut une copie de Metro (voir cette question et celle-ci par exemple), cependant, pour une raison inconnue, il semble être obligatoire de remplacer cette copie de Metro par une téléchargée depuis le site glassfish. J'essaie de comprendre s'il est possible de se passer uniquement de Tomcat et de l'implémentation de Metro fournie avec le JDK, ou non et pourquoi.

Les contenus du WAR sont les suivants (fichiers de classe retirés) :

META-INF/MANIFEST.MF
WEB-INF/classes/
WEB-INF/classes/com/[et cetera]
WEB-INF/ibm-web-ext.xml
WEB-INF/lib/
WEB-INF/lib/stax-api.jar
WEB-INF/lib/webservices-api.jar
WEB-INF/lib/webservices-extra-api.jar
WEB-INF/lib/webservices-extra.jar
WEB-INF/lib/webservices-rt.jar
WEB-INF/lib/webservices-tools.jar
WEB-INF/sun-jaxws.xml
WEB-INF/web.xml
wsdl/
wsdl/MyService.wsdl

web.xml contient en partie:

    MyService

        com.sun.xml.ws.transport.http.servlet.WSServlet

Lorsque je supprime les jars webservices-* - les jars Metro - du WAR, le service web échoue avec l'erreur "Le Wrapper ne peut pas trouver la classe de servlet com.sun.xml.ws.transport.http.servlet.WSServlet ou une classe sur laquelle elle dépend". Ce n'est pas surprenant car je ne trouve pas cette classe nulle part dans les jars fournis avec Java 7 SE.

Alors, que signifie-t-il de dire que Java 7 est livré avec Metro, si vous devez télécharger une autre copie de Metro pour faire fonctionner quelque chose comme ça? Est-il possible de faire fonctionner un service web JAX-WS dans Tomcat en utilisant uniquement les jars fournis avec Java?

Answer 1

Alors, que signifie-t-il de dire que Java 7 vient avec Metro..?

Ce n'est pas tout à fait correct. JDK6+ inclut JAX-WS RI (implementación de referencia), et Metro est un sur-ensemble de celui-ci. En d'autres termes, Metro = JAX-WS RI + WSIT.

Est-il possible d'exécuter un service web JAX-WS dans Tomcat en utilisant uniquement les jars fournis avec Java?

C'est une excellente question. La réponse est - non, car la classe WSServlet étend HttpServlet, et WSServletContextListener implémente les interfaces ServletContextAttributeListener et ServletContextListener. Ces interfaces et classes font toutes partie de Java EE, pas de Java SE - donc pas inclus dans JDK/JRE. Sun/Oracle a décidé de ne pas mélanger Java SE et Java EE, et c'est compréhensible même si cela signifie que ces classes ont en réalité été retirées de la version JAX-WS RI fournie avec JDK/JRE. Par conséquent, vous devez installer les dépendances JAX-WS pour utiliser des services Web basés sur JAX-WS sur Tomcat, car Tomcat ne les inclut pas (en revanche, si vous choisissez Glassfish par exemple, vous trouverez une distribution Metro complète intégrée et vous n'avez rien à installer en plus). Sinon, vous êtes coincé avec le mécanisme Endpoint#publish.

Voir aussi:

• WSServletContextListener et WSServlet dans JRE 6

Answer 2

Le JAX-WS groupé manque d'intégration avec les conteneurs de servlets, car il est destiné à être utilisé seulement pour offrir des services JAX-WS à l'intérieur d'applications Java autonomes (WTF!?!?!?).

De toute évidence, on pourrait penser à mettre en place un servlet qui intègre tout ça, comme ça vous n'auriez pas besoin d'inclure une autre copie de Metro dans votre WAR. Mais il est plus simple d'inclure une copie "complète" externe, même si cela gonfle le WAR, cela ne devrait pas avoir un grand impact sur les performances. De plus, de cette manière, vous pouvez contrôler la version que vous utilisez, évitant ainsi de rester bloqué avec la version incluse dans votre JRE.

Quoi qu'il en soit, Sun changeait généralement les noms des packages dans les bibliothèques groupées pour éviter les collisions avec les externes. Par conséquent, si le servlet existait (ce n'est pas le cas), il serait probablement appelé :

com.sun.xml. internal. ws.transport.http.servlet.WSServlet

C'est très agaçant car ils ont également changé certaines propriétés de configuration de la même manière (par exemple : celles liées au timeout), donc si vous utilisez le JAX-WS groupé, vous devez utiliser les propriétés de configuration en style

com.sun.xml. internal.... , mais si vous utilisez un JAX-WS externe, vous devez utiliser

com.sun.xml.... style propriétés de configuration.

Merci Sun !!

Answer 3

C'est une vieille question, mais si quelqu'un cherche toujours des réponses. Il n'est pas nécessaire d'inclure le jar jaxws à partir de JDK 1.7 (j'utilise précisément la version 1.7.0_45). J'ai utilisé ce lien pour construire un exemple de service web et j'ai sauté l'étape 5 et tout fonctionne. Je cible la version 7.0.47 de Tomcat, l'ensemble du projet est construit avec Maven avec la portée par défaut pour les jars jaxws-rt (c'est-à-dire compile).