Wsimport of multiple equal services with several unnecessary operations

Navigation
0

In Java, I'm using the wsimport tool. The process works. However there are some problems.

I have to do the wsimport in the services of several different providers (all of them third, I have no control over them). WSDLs are almost identical, just changing the destination URL.

Each of these WSDLs defines a lot of different operations / methods. It happens that among this lot of operations, only a 2 or 3 I'm really going to need. Almost at the end of each of these WSDLs there is this: 

  <wsdl:service name="Exemplo">
    <wsdl:port name="ExemploSoap" binding="tns:ExemploSoap">
      <soap:address location="https://www.example.com/wsIntegracao/exemplo.asmx" />
    </wsdl:port>
    <wsdl:port name="ExemploSoap12" binding="tns:ExemploSoap12">
      <soap12:address location="https://www.example.com/wsIntegracao/exemplo.asmx" />
    </wsdl:port>
  </wsdl:service>

From one WSDL to another, almost nothing changes. In general, the only thing that changes are those URLs that are in the excerpt above.

Here's the relevant part of pom.xml . I have this for each different WSDL / service, so each of them will generate a distinct JAR (there is a pom.xml for each service, each in a different folder). 

        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>jaxws-maven-plugin</artifactId>
            <executions>
                <execution>
                    <goals>
                        <goal>wsimport</goal>
                    </goals>
                    <configuration>
                        <wsdlFiles>
                            <wsdlFile>servico-teste.wsdl</wsdlFile>
                        </wsdlFiles>
                        <wsdlLocation>servico-teste.wsdl</wsdlLocation>
                        <wsdlDirectory>${basedir}</wsdlDirectory>
                        <packageName>br.com.example.servico2</packageName>
                        <verbose>true</verbose>
                    </configuration>
                </execution>
            </executions>
        </plugin>

        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <configuration>
                <source>1.8</source>
                <target>1.8</target>
                <encoding>UTF-8</encoding>
                <compilerArgs>
                    <arg>-Xlint:none</arg>
                </compilerArgs>
            </configuration>
        </plugin>

The differences between pom.xml and other are minimal. Just about the name of the package to be generated and the name of the WSDL file.

As I mentioned, the process works. But this way, if I have 20 different services, 20 almost identical JAR files will be generated. If each of them has 100 classes, this will generate 2000 different classes in 20 JARs, and only 3 or 4 I use effectively.

So I ask two questions:

  • Is there any way to optimize wsimport so that it needs to be run only once when the services are the same or similar enough, where only the URL in soap:address location varies? > Is there any way to instruct wsimport to generate only the classes needed for a particular part of the WSDL, not everything that is referenced in the WSDL?

    • asked by anonymous 14.12.2016 / 16:53

    2 answers

    0

    The buffer response helped me a lot, but it still was not the ideal solution.

    Also, this answer from SOen helped me a lot, although it was not yet the complete solution.

    Firstly, I took one of the WSDLs and changed the URL there by placing a generic URL, generating in the maven classes the same way I already did.

    In Java, instead of instantiating the main class of the service to integrate using the default constructor, I started using the constructor that receives URL and QName . This builder is also generated by default by ws-import.

    When invoking this constructor, just like in the SOen response, I pass URLs that start with http://localhost/wsdl . Within the META-INF folder, then I create a jax-ws-catalog.xml file with the following content: 

    <catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog" prefer="system">
    <system systemId="http://localhost/wsdl/servico1.wsdl" uri="wsdls/servico1.wsdl"/>
    <system systemId="http://localhost/wsdl/servico2.wsdl" uri="wsdls/servico2.wsdl"/>
    <system systemId="http://localhost/wsdl/servico3.wsdl" uri="wsdls/servico3.wsdl"/>
</catalog>

    Within a wsdls folder, I add the WSDL files I downloaded from each service. This folder is placed inside the generated JAR / WAR of the application. This jax-ws-catalog.xml file instructs JAX-WS to search for these WSDLs locally.

    In this way, I only need to use wsimport once. Finally, to reduce the number of unnecessary things generated, I can edit the generic WSDL.

        
    16.12.2016 / 15:22
    1

    If you can only generate one jar, you will not have to worry. I do so, I have a jar only with my webservices classes.

    So everything that is common is overwritten by having classes shared.

    If you want to insist on several jars, I did some tests and it is possible, but you will need some "gambiarra" to leave round.

    According to the link below:

    link

    You will see that if you make a binding like mine, the schema that is shared will go to a specific package. In my binding, the schemas are inside the wsdls (attention). 

    <bindings xmlns="http://java.sun.com/xml/ns/jaxb" version="2.1">

    <bindings scd="x-schema::bons1"
        xmlns:bons1="http://www.dominio.net/services/metadata/v2.0">
        <schemaBindings>
            <package name="br.common.metada" />
        </schemaBindings>
    </bindings>

    <bindings scd="x-schema::e"
        xmlns:e="http://www.dominio.net/services/errors/v1.0">
        <schemaBindings>
            <package name="br.common.errors" />
        </schemaBindings>
    </bindings>

</bindings>

    But I did not find a way to not generate specific classes, so here I suggest you edit the schemas that will be shared by keeping only what you want to generate, or else, delete the classes of the packages you do not want. >

    Then, when generating the specific classes, point the generated episode to xjc as the link.

    I found it very painful, but I had already asked myself this question and it was the closest I came.

        
    14.12.2016 / 20:45
    Code in the c ++ dev of the problem, but in another compiler it works Assign a value to a Boolean variable according to Radio Button selected