wsimport - comment générer des classes de point de terminaison de service et des classes JAXB dans des projets / dossiers distincts

Nous sommes à l'aide d'une approche top-down pour un projet avec plusieurs services web (plusieurs WSDL). Chaque service web doit être mis en place comme un projet distinct et déployé en tant que distincte de la guerre.

Le problème est que le WSDL de la part de quelques communes .les fichiers xsd. Actuellement, si nous courons wsimport pour chaque WSDL, la commune de JAXB les classes sont dupliqué dans chaque projet de service web.

Idéalement, nous voulons générer la JAXB classes séparément dans une commune et partagée du projet, et ensuite réutiliser le JAXB classes du projet dans chacun des projets service web, mais wsimport n'offre pas l'option de sauter le JAXB génération de classe OU pour spécifier un autre emplacement pour le JAXB classes.

Des idées sur comment je peux partager la JAXB classes entre les différents JAX-WS web points de terminaison du service?

source d'informationauteur PrasadB | 2011-11-21

12

Je sais que cette question est très vieux, mais je voulais partager la réponse pour ceux qui sont à la recherche. Je sais qu'il m'a fallu un certain temps pour trouver la réponse.

De JAXB 2.1 RI, il y a une fonctionnalité appelée "épisodes" que vous pouvez utiliser pour faciliter cela.

Disons que vous avez un schéma appelé monschema.xsd. Ensuite, vous voulez appeler le suivant:
```
xjc -episode myschema.episode myschema.xsd
```
Cela fonctionne aussi si vous êtes de la compilation de plusieurs fichiers xsd à l'aide d'un seul appel. L'appel sera de produire les liaisons ainsi que la monschema.épisode de fichier.

L'épisode est un fichier spécial de fichier de liaisons. Vous pouvez ensuite utiliser ce fichier avec wsimport, comme suit:
```
wsimport mywsdl.wsdl -b myschema.episode
```
wsimport va maintenant utiliser l'généré précédemment JAXB fichiers, et va générer tout ce qui est manquant.

Voir cette page pour plus d'informations.

Vous pouvez atteindre cet objectif en utilisant JAXB/JAX-WS de personnalisation. Supposons que vous avez les types XSD intégré en WSDL. Alors votre personnalisation va ressembler:

<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 configuration ci-dessus se réfère au projet de structure de répertoire:

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

Si vous utilisez org.codehaus.mojo:jaxws-maven-plugin plugin, vous devez spécifier <bindingDirectory>binding</bindingDirectory>.

Dans le cas où votre XSD est à l'extérieur de WSDL, vous devez spécifier les personnalisations séparément:

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

Puis jaxb-binding.xml ressemblera:

<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>

Pour Ant vous suffit de générer deux pots pour les packages différents.
Que personnellement je ne connais pas de façon à créer deux POT d'objets d'un projet Maven 🙂 alors la solution la plus simple serait pour vous de générer JAXB classes de XSD dans project-beans projet et dans project-ws projet de supprimer généré JAXB classes après wsimport run (vous pouvez utiliser ant plugin pour ça).

1

Généralement de ce que j'ai vu en utilisant les outils Rational IBM:

Générer toutes les JAXB et les classes de service et de les stocker avec le projet de service. Puis régénérer les JAXB et le service client de classes et de les stocker dans un projet client.

Oui, c'est la duplication. Mais je pense que le raisonnement derrière cela est qu'il sépare les préoccupations des fournisseurs de services et les consommateurs. À partir d'un ensemble d'outils de point de vue, comment savez-vous si votre client .NET, C++, ou Java? Ou vice versa. Si vous êtes un client, comment savez-vous si le fournisseur est .NET, C++, ou Java, etc? Vous n'avez pas. Ainsi, IBM fournit à cette façon de la séparation des préoccupations.

Maintenant le revers de la médaille, c'est que vous avez le code dupliqué, si vous arrive d'avoir le source pour le fournisseur de services et le consommateur. Cela peut être une douleur à maintenir.

Il serait donc peut-être préférable de générer le service et le client dans un projet Java (pas un projet J2EE ou un projet web) et de faire un pot. De cette façon, tous les JAXB sont les classes (et seule fois). Le WSDL est là (pour une fois). Le service est-il une fois et peut être déployé sur le serveur dans une OREILLE ou de la GUERRE. Et le client existe dans le cas où vous voulez donner à quelqu'un de consommer votre service. Si votre client permet la création dynamique basée sur l'emplacement WSDL, encore mieux.

J'ai un post qui peut aider à vous qu'à partir d'un assistant conduit perspective. Il est plus liée à la sécurité, mais vous pouvez trouver quelques conseils utiles.
0

Si vous utilisez maven, vous pouvez utiliser un plug-in pour le faire.

À l'aide de la JAXB XJC Plugin Maven 2

Vous devez vous connecter pour publier un commentaire.