wsimport - cómo generar clases de punto final de servicio y clases JAXB en proyectos/carpetas separados

Question

Estamos utilizando un enfoque descendente para un proyecto con múltiples servicios web (WSDL múltiples). Cada servicio web debe configurarse como un proyecto separado y desplegarse como una guerra separada.

El problema es que los WSDL comparten algunos archivos .xsd comunes. Actualmente, si ejecutamos wsimport para cada WSDL, las clases comunes de JAXB se duplicarán en cada proyecto de servicio web.

Idealmente, quisiéramos generar las clases JAXB por separado en un proyecto común compartido, y luego reutilizar el proyecto de clases JAXB en cada uno de los proyectos de servicio web, pero wsimport no proporciona la opción de omitir la generación de clase JAXB O especifique una ubicación diferente para las clases de JAXB.

¿Alguna idea sobre cómo puedo compartir las clases JAXB entre diferentes puntos finales del servicio web JAX-WS?

Answer 1

Sé que esta pregunta es muy antigua, pero quería compartir la respuesta para aquellos que están buscando. Sé que me tomó un tiempo encontrar la respuesta.

A partir de JAXB 2.1 RI, hay una función llamada "episodios" que puede utilizar para facilitar esto.

Digamos que tiene un esquema llamado myschema.xsd. Luego, debería llamar a lo siguiente:

xjc -episode myschema.episode myschema.xsd 

Esto también funciona si está compilando múltiples archivos xsd con una sola llamada. La llamada producirá los enlaces, así como el archivo myschema.episode.

El archivo de episodio es un archivo de enlaces especial. A continuación, puede utilizar este archivo con wsimport, así:

wsimport mywsdl.wsdl -b myschema.episode 

wsimport utilizará ahora los archivos generados con anterioridad JAXB, y va a generar algo que falta.

Consulte this page para obtener más información.

Answer 2

Si está utilizando maven, puede usar un complemento para hacerlo.
Using the JAXB XJC Maven 2 Plugin

Answer 3

Por lo general, lo que he visto con el conjunto de herramientas de IBM Rational:

generar todas las clases JAXB y de servicios y almacenarlos con el proyecto de servicio. A continuación, regenere JAXB y las clases de cliente de servicio y almacénelas en un proyecto de cliente.

Sí, esto es una duplicación. Pero creo que el razonamiento detrás de esto es que separa las preocupaciones de los proveedores de servicios y los consumidores de servicios. Desde una perspectiva del conjunto de herramientas, ¿cómo puede saber si su cliente es .NET, C++ o Java? O viceversa. Si usted es un cliente, ¿cómo sabe si el proveedor es .NET, C++ o Java, etc.? Tu no Por lo tanto, IBM proporciona esta forma de separación de preocupaciones.

Ahora, la desventaja es que tiene un código duplicado, si tiene la fuente tanto para el proveedor del servicio como para el consumidor. Esto puede ser un dolor para mantener.

Así que quizás sería mejor generar el servicio y el cliente en un proyecto Java (no un proyecto J2EE o un proyecto web) y hacer un jar de él. De esta forma, todas las clases de JAXB están allí (y solo una vez). El WSDL está allí (una vez). El servicio está allí una vez y se puede implementar en el servidor en un EAR o GUERRA. Y el cliente existe en caso de que quiera dárselo a alguien para consumir su servicio. Si su cliente permite la creación dinámica basada en la ubicación WSDL, aún mejor.

Tengo a post that may help con eso desde una perspectiva guiada por un asistente. Está más relacionado con la seguridad, pero puede encontrar algunos consejos útiles.

Answer 4

Puede lograr esto usando JAXB/JAX-WS personalización. Supongamos que tiene tipos XSD incrustados en WSDL. A continuación, la personalización se verá así:

<jaxws:bindings version="2.0" 
    xmlns:jaxws="http://java.sun.com/xml/ns/jaxws" 
    xmlns:jaxb="http://java.sun.com/xml/ns/jaxb" 
    xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
    xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 
    wsdlLocation="../wsdl/some.wsdl"> 

    <jaxws:package name="org.company.project.ws" /> 

    <!-- XSD types customization within WSDL --> 
    <jaxb:bindings node="//xsd:schema"> 
     <jaxb:schemaBindings> 
      <jaxb:package name="org.company.project.beans" /> 
     </jaxb:schemaBindings> 
    </jaxb:bindings> 
</jaxws:bindings> 

La configuración anterior se refiere la siguiente estructura de directorios:

+-- binding 
| +-- jaxws-binding.xml 
+-- wsdl 
| +-- some.wsdl 
+-- src 
    ... 

Si utiliza org.codehaus.mojo:jaxws-maven-plugin plugin, a continuación, es necesario especificar <bindingDirectory>binding</bindingDirectory>.

En caso de que su XSD es externo a WSDL, entonces es necesario que especifique las personalizaciones por separado:

+-- binding 
| +-- jaxb-binding.xml 
| +-- jaxws-binding.xml 
+-- wsdl 
    ... 

Entonces jaxb-binding.xml será parecida:

<jaxb:bindings version="1.0" 
    xmlns:jaxb="http://java.sun.com/xml/ns/jaxb" 
    xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc" 
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 

    <jaxb:bindings schemaLocation="my.xsd" node="//xsd:schema"> 
     <jaxb:schemaBindings> 
      <jaxb:package name="org.company.project.beans" /> 
     </jaxb:schemaBindings> 
    </jaxb:bindings> 
</jaxb:bindings> 

• Para construcción Ant sólo tiene que generar dos frascos para diferentes paquetes.
• Como personalmente no conozco ninguna forma de crear dos artefactos JAR de un proyecto Maven :) entonces la solución más simple sería generar clases JAXB de XSD en el proyecto project-beans y en el proyecto project-ws eliminar las clases JAXB generadas después de wsimport ejecutar (puede usar el complemento Ant para eso).