WSIT, Maven et wsimport - peuvent-ils travailler ensemble?

Question

Je travaille sur un petit projet multi-module à Maven. Nous avons séparé l'interface utilisateur de la couche de base de données à l'aide des services Web, et grâce à jaxws-maven-plugin, la création du client WSDL et WS est plus ou moins gérée pour nous. (Le plugin est essentiellement un wrapper autour de wsgen et wsimport.) Jusqu'ici tout va bien.

Le problème survient lorsque j'essaie de superposer la sécurité WSIT dans l'image. NetBeans me permet de générer facilement les métadonnées de sécurité, mais wsimport semble complètement incapable de gérer quoi que ce soit au-delà du niveau de sécurité Basic-auth.

Voici notre façon actuelle, peu sûr d'appeler wsimport lors d'une build 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> 

J'ai essayé de jouer avec xauthFile, xadditionalHeaders, en passant javax.xml.ws.security.auth.username et mot de passe par args. J'ai également essayé d'utiliser wsimport depuis la ligne de commande pour pointer vers le WSDL généré par Tomcat, qui contient les informations de sécurité supplémentaires. Rien, cependant, ne semble changer du tout la composition des fichiers générés par wsimport.

Donc, ma question est la suivante: pour obtenir un client compatible WSIT, suis-je obligé d'abandonner complètement Maven et le plugin jaxws? Existe-t-il un moyen de générer automatiquement un client WSIT? Ou aurai-je besoin de générer le client à la main? Faites-moi savoir si vous avez besoin d'informations supplémentaires au-delà de ce que j'ai écrit ici. Je suis en train de déployer sur Tomcat, même si cela ne semble pas poser de problème, car Maven semble heureux d'intégrer Metro dans le fichier WAR déployé.

Merci d'avance! Après avoir beaucoup joué avec WSIT, voici ce qui a fonctionné pour moi.

Pour commencer, utilisez Netbeans pour générer un client WSIT. Testez-le pour vous assurer qu'il fonctionne, puis déplacez les fichiers de configuration WSIT (wsit-client.xml et [votre nom de service Web] .xml) dans le répertoire META-INF du projet client WS.

L'ajout pertinent à votre projet, du point de vue de la sécurité, est la balise dans le service 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> 

De toute évidence, il y a des dépendances codées en dur dans ici que nous devons gérer pendant notre construction. L'utilisateur, le mot de passe, l'emplacement du fichier de clés certifiées et les peeralias sont tous des paramètres de développement par défaut et changeront à mesure que le système passera de dev à test et production. Nous jouons avec quelques stratégies différentes pour gérer cela, mais nous finirons probablement par définir des variables d'environnement dans Hudson pour la construction de chaque environnement. Finger avec la configuration du plugin javax de Maven un peu. Nous générons le WSDL dans le cadre de la construction, nous n'avons donc pas besoin de le référencer localement. Voici la balise plugin pour la commande wsimport dans notre cible client 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> 

Et enfin, bien sûr, assurez-vous que tous vos projets qui auront besoin d'appeler les services Web ont la dépendance Metro correctement mis en place.

Answer 1

N'êtes-vous pas simplement supposé fournir les fichiers de configuration WSIT côté client pour le client? Qu'attendez-vous exactement de wsimport?

Edit: Comme implicite, le document WSIT describes deux fichiers de configuration côté client: wsit-client.xml et {wsdl file name}.xml et:

Lors de l'exécution du client, ces fichiers devront être dans le chemin de classe, que ce soit à la racine du classpath (c'est-à-dire, build/classes) ou dans un répertoire META-INF sous la racine du classpath.

à un projet Transposé Maven, l'emplacement naturel pour ces fichiers serait dossier src/main/resources ou src/main/resources/META-INF. Personnellement, j'ai tendance à préférer les mettre dans META-INF.