WSIT, Maven y wsimport - ¿Pueden funcionar juntos?

Question

Estoy trabajando en un pequeño proyecto multi-módulo en Maven. Hemos separado la interfaz de usuario de la capa de la base de datos mediante los servicios web y, gracias al plugin jaxws-maven, la creación del WSDL y el cliente WS se manejan más o menos para nosotros. (El plugin es esencialmente un envoltorio alrededor de wsgen y wsimport.) Hasta ahora todo bien.

El problema surge cuando trato de capar la seguridad de WSIT en la imagen. NetBeans me permite generar los metadatos de seguridad fácilmente, pero wsimport parece completamente incapaz de lidiar con nada más allá de un nivel de seguridad de autenticación básica.

Aquí es nuestra actual forma, insegura de llamar wsimport durante una construcción Maven:

<plugin> 
    <groupId>org.codehaus.mojo</groupId> 
    <artifactId>jaxws-maven-plugin</artifactId> 
    <version>1.10</version> 
    <executions> 
     <execution> 
      <goals> 
       <goal>wsimport</goal> 
      </goals> 
      <configuration> 
       <wsdlUrls> 
        <wsdlUrl>${basedir}/../WebService/target/jaxws/wsgen/wsdl/WebService.wsdl</wsdlUrl> 
       </wsdlUrls> 
       <packageName>com.yourcompany.appname.ws.client</packageName> 
       <sourceDestDir>${basedir}/src/main/java</sourceDestDir> 
       <destDir>${basedir}/target/jaxws</destDir> 
      </configuration> 
     </execution> 
    </executions> 
</plugin> 

He tratado de jugar con xauthFile, xadditionalHeaders, pasando javax.xml.ws.security.auth.username y contraseña a través args. También intenté usar wsimport desde la línea de comandos para apuntar al WSDL generado por Tomcat, que tiene la información de seguridad adicional. Sin embargo, nada parece cambiar la composición de los archivos generados por wsimport.

Así que supongo que mi pregunta aquí es, para obtener un cliente compatible con WSIT, ¿estoy atascado abandonando por completo el plugin de Maven y jaxws? ¿Hay alguna manera de hacer que un cliente de WSIT se autogenere? ¿O tendré que generar el cliente a mano?

Deseo saber si necesita información adicional más allá de lo que he escrito aquí. Estoy implementando en Tomcat, aunque eso no parece ser un problema, ya que Maven parece feliz de incorporar a Metro al archivo WAR desplegado.

¡Gracias de antemano!

EDIT: Después de jugar mucho con WSIT, esto es lo que funcionó para mí.

Para empezar, use Netbeans para generar un cliente WSIT. Pruébelo para asegurarse de que funciona, y luego mueva los archivos de configuración de WSIT (wsit-client.xml y [su nombre de servicio web] .xml) al directorio META-INF del proyecto de cliente de WS.

La adición relevante para su proyecto, desde el punto de vista de seguridad, es la etiqueta en el servicio web xml:

<wsp:Policy wsu:Id="WebPortBindingPolicy"> 
    <wsp:ExactlyOne> 
     <wsp:All> 
      <sc:CallbackHandlerConfiguration wspp:visibility="private"> 
       <sc:CallbackHandler default="wsitUser" name="usernameHandler"/> 
       <sc:CallbackHandler default="changeit" name="passwordHandler"/> 
      </sc:CallbackHandlerConfiguration> 
      <sc:TrustStore wspp:visibility="private" location="C:\Apps\apache-tomcat-6.0.24\certs\client-truststore.jks" type="JKS" storepass="changeit" peeralias="xws-security-server"/> 
     </wsp:All> 
    </wsp:ExactlyOne> 
</wsp:Policy> 

Obviamente, hay algunas dependencias no modificables aquí que vamos a necesitar para gestionar durante nuestra construcción. El usuario, la contraseña, la ubicación del almacén de confianza y las peeralias son todos valores predeterminados de desarrollo, y cambiarán a medida que el sistema pase del desarrollo a las pruebas y la producción. Estamos jugando con algunas estrategias diferentes para gestionar esto, pero probablemente terminaremos configurando variables de entorno en Hudson para construir cada entorno.

Violín con la configuración del plugin jaxws de Maven un poco. Generamos el WSDL como parte de la compilación, por lo que no necesitamos referenciarlo localmente. Aquí está la etiqueta plugin para el comando wsimport en nuestra meta de clientes WS:

<plugin> 
    <groupId>org.codehaus.mojo</groupId> 
    <artifactId>jaxws-maven-plugin</artifactId> 
    <version>1.12</version> 
    <executions> 
     <execution> 
      <goals> 
       <goal>wsimport</goal> 
      </goals> 
      <configuration> 
       <wsdlUrls> 
        <wsdlUrl>${basedir}/../WebService/target/jaxws/wsgen/wsdl/WebService.wsdl</wsdlUrl> 
       </wsdlUrls> 
       <staleFile>${project.build.directory}/jaxws/stale/WebService.stale</staleFile> 
       <packageName>com.yourcompany.appname.ws.client</packageName> 
       <sourceDestDir>${basedir}/src/main/java</sourceDestDir> 
       <destDir>${basedir}/target/jaxws</destDir> 
      </configuration> 
      <id>wsimport-generate-WebService</id> 
      <phase>generate-sources</phase> 
     </execution> 
    </executions> 
    <dependencies> 
     <dependency> 
      <groupId>javax.xml</groupId> 
      <artifactId>webservices-api</artifactId> 
      <version>2.0-b30</version> 
     </dependency> 
    </dependencies> 
    <configuration> 
     <sourceDestDir>${project.build.directory}/generated-sources/jaxws-wsimport</sourceDestDir> 
     <xnocompile>true</xnocompile> 
     <verbose>true</verbose> 
     <extension>true</extension> 
    </configuration> 
</plugin> 

Y, por último, por supuesto, asegúrese de que todos los proyectos que tendrá que llamar a los servicios web tienen la dependencia de metro configurado correctamente.

Answer 1

¿No se supone que solo proporcione los archivos de configuración de WSIT del lado del cliente para el cliente? ¿Qué espera de wsimport exactamente?

Editar: como da a entender, el documento WSIT describes dos archivos de cliente de Configuración: wsit-client.xml y {wsdl file name}.xml y:

Cuando se ejecuta el cliente, estos archivos tienen que estar en la ruta de clase, ya sea en la raíz de classpath (es decir, compilación/clases) o en un directorio META-INF en la raíz de classpath.

Trasladado a un proyecto Maven, el lugar natural para estos archivos sería src/main/resources o src/main/resources/META-INF carpeta. Personalmente, tiendo a preferir ponerlos en META-INF.