generate - Implementación de JAX-WS incluida con Java?
wsimport (3)
Entonces, ¿qué significa decir que Java 7 viene con Metro ...?
Esto no es del todo correcto. JDK6 + incluye JAX-WS RI (implementación de referencia), y Metro es un superconjunto de ello. En otras palabras, Metro = JAX-WS RI + WSIT.
¿Es posible ejecutar un servicio web JAX-WS dentro de Tomcat usando solo los jars que vienen con Java?
Esta es una excelente pregunta. La respuesta es: no, porque la clase WSServlet amplía HttpServlet , y WSServletContextListener implementa las interfaces ServletContextAttributeListener y ServletContextListener . Estas interfaces y clases son todas parte de Java EE, no de Java SE, por lo tanto no están incluidas en JDK / JRE. Sun / Oracle decidió no mezclar Java SE y Java EE, y eso es comprensible a pesar de que significa que estas clases realmente han sido eliminadas de la versión JAX-WS RI que viene con JDK / JRE. Por lo tanto, debe instalar las dependencias de JAX-WS para usar los servicios web basados en JAX-WS en Tomcat, porque Tomcat no viene con eso (por otra parte, si elige Glassfish, por ejemplo, encontrará Metro completo). distribución incluida con él y no tiene que instalar nada adicionalmente). De lo contrario, está atascado con Endpoint#publish mecanismo de Endpoint#publish .
Ver también:
Tengo una aplicación de servicio web JAX-WS que se despliega como un archivo WAR para Tomcat 7. Utiliza una versión reciente de las bibliotecas de Metro, que incluyo dentro del archivo WAR, y funciona bien.
Estoy tratando de simplificar el paquete de implementación. Entiendo que el Sun JDK incluye una copia de Metro (consulte esta pregunta y esta por ejemplo), pero por alguna razón, es aparentemente obligatorio reemplazar esta copia de Metro con una descargada del sitio de glassfish. Estoy tratando de entender si es posible arreglárselas solo con Tomcat y la implementación de metro que viene con el JDK, o si no, por qué no.
Los contenidos de WAR son los siguientes (archivos de clase eliminados):
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 contiene, en parte:
<servlet>
<servlet-name>MyService</servlet-name>
<servlet-class>
com.sun.xml.ws.transport.http.servlet.WSServlet
</servlet-class>
</servlet>
Cuando quito los webservices- * jars - los jars de Metro - del WAR, el servicio web falla con el error "Wrapper no puede encontrar la clase de servlet com.sun.xml.ws.transport.http.servlet.WSServlet o una clase depende de". Esto no es sorprendente porque no puedo encontrar esa clase en ningún lugar de los frascos que vienen con Java 7 SE.
Entonces, ¿qué significa decir que Java 7 viene con Metro, si tiene que descargar otra copia de Metro para hacer que algo como esto funcione? ¿Es posible ejecutar un servicio web JAX-WS dentro de Tomcat usando solo los jars que vienen con Java?
El paquete JAX-WS carece de integración con los contenedores de servlets, ya que está destinado a ser utilizado solo para ofrecer servicios JAX-WS dentro de aplicaciones Java independientes (WTF!?!?!?).
Por supuesto, uno podría pensar en implementar un servlet que haga esa integración, para que no tenga que incluir otra copia de Metro en su WAR. Pero es más fácil simplemente incluir una copia "completa" externa, infla la GUERRA pero no debería tener una gran penalización de rendimiento. Además, de esta manera puede controlar qué versión usa, evitando quedarse atascado con la versión que se incluyó en su JRE.
De todos modos, Sun generalmente cambiaba los nombres de los paquetes en las bibliotecas agrupadas para que no chocaran con las externas, por lo tanto, si el servlet existiera (no existe), probablemente se llamaría:
com.sun.xml. interno. ws.transport.http.servlet.WSServlet
Esto es muy molesto, ya que también cambiaron algunas propiedades de configuración de la misma manera (por ejemplo, relacionadas con el tiempo de espera), por lo que si usa el paquete JAX-WS, debe usar
com.sun.xml. interno. ... propiedades de configuración de estilo,
pero si usas algún JAX-WS externo tienes que usar
com.sun.xml .... propiedades de configuración de estilo.
Gracias sol !!
Es una vieja pregunta pero si alguien todavía está buscando respuestas. No es necesario incluir el jaxws jar a partir de JDK 1.7 (estoy usando precisamente 1.7.0_45). Usé este enlace http://www.mkyong.com/webservices/jax-ws/deploy-jax-ws-web-services-on-tomcat/ para crear un servicio web de muestra y se saltó el paso 5 y todo funciona. Estoy apuntando a la versión 7.0.47 de Tomcat, el proyecto completo se compila con Maven con un alcance predeterminado para los jars jaxws-rt (es decir, compilación).