使用带有-clientjar选项的jaxws-maven-plugin

本文介绍了使用带有-clientjar选项的jaxws-maven-plugin的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我正在使用来执行wsimport是一个Web服务消费者应用程序。我在wsimport上使用 -clientjar 选项，这是在2010年与JAX-WS 2.2.2 RI一起引入的。我这样做是因为我想在jar中捆绑WSDL 。

I'm using jaxws-maven-plugin to execute wsimport for a web service consumer app. I'm using the -clientjar option on wsimport which was introduced with JAX-WS 2.2.2 RI in 2010. I do this because I want to bundle the WSDL within the jar.

我没有制作pom的问题。对于插件配置，我执行以下操作：

I don't have a problem crafting the pom. For plugin configuration I do something like:

<configuration>
    ...
    <args>
        <arg>-clientjar</arg>
        <arg>bundled-wsdl.jar</arg>
    </args>
</configuration>

当我执行构建我创建的jar时，我们可以调用它 myapp.jar ，其中包含文件 bundled-wsdl.jar 。在 bundled-wsdl.jar 的META-INF目录中，我发现wsdl和xsd就像我喜欢它们一样。我对使用 -clientjar 选项产生的生成的java代码也很满意。到目前为止一直很好。

When I execute a build my created jar, lets call it myapp.jar, has file bundled-wsdl.jar within it. Inside the bundled-wsdl.jar's META-INF directory I find the wsdl and xsd just as I like them. I'm also quite happy with the generated java code that come as a result of using the -clientjar option. So far so good.

但这些东西应该在 myapp.jar 的META-INF中，对吧？
事实上，它位于 bundled-wsdl.jar 的META-INF中对我没什么帮助。

But this stuff should be in myapp.jar's META-INF, right?The fact that it sits within bundled-wsdl.jar's META-INF doesn't help me a lot.

有趣的是，我确实在 myapp.jar 的META-INF中获得了一个wsdl文件，这使得应用程序实际上可以工作。怎么到达那里我不知道。另外xsd文件不存在，仅在 bundled-wsdl.jar 的META-INF。

The funny thing is that I do in fact get a wsdl file in myapp.jar's META-INF which makes the application actually work. How it gets there I don't know. Also the xsd file isn't there, only in bundled-wsdl.jar's META-INF.

基本问题是如何在Maven项目中正确使用wsimport -clientjar 选项？

The basic question is how to correctly use wsimport -clientjar option in a Maven project ?

Java 1.7.0_45。

Java 1.7.0_45.

推荐答案

-clientjar 选项的记录很少，恕我直言。
以下是我认为它的工作原理：

The -clientjar option is really poorly documented, IMHO.Here's how I believe it works:

当使用 -clientjar< jarfile> 选项时事情正在发生：

When the -clientjar <jarfile> option is used three things are happening:

你会得到一个< jarfile> 在
指向的目录中生成 -d 参数 wsimport 工具。这将包含在
内的WSDL和任何相关的XSD文件。这个小包不会用于任何东西。如果你想使用它，那完全取决于你。但在你看到下面的（2）之前。我不确定除了作为一种文档形式之外还要使用这个jar文件。

你将得到一个WSDL的副本放入一个名为
<$的文件中C $ C> META-INF / WSDL /< SVCNAME>的.wsdl 。生成的类将在no-arg代理构造函数中使用此
文件。因此，如果您使用 -clientjar
选项请求捆绑的WSDL文件，那么实际上将使用
。

如果您在 wsdlLocation > @WebServiceClient 类，将是捆绑的WSDL（来自（2）），而不是远程WSDL。实际上，如果您在命令行中使用 -wsdllocation 以及 -clientjar ，那么您使用 -wsdllocation 将无效，因为 -clientjar 将优先。

You'll get a <jarfile> generated in the directory pointed to bythe -d argument to the wsimport tool. This will contain withinit both WSDL and any relevant XSD files as well. This little bundle will not be used for anything at all. If you want to make use of it it would be entirely up to you. But before you do see (2) below. I'm not sure what to use this jarfile for other than as a form of documentation.
You'll get a copy of the WSDL put into a file calledMETA-INF/wsdl/<svcname>.wsdl. The generated classes will use thisfile in the no-arg proxy constructor. So this is what will actuallybe used if you request a bundled WSDL file with the -clientjaroption.
The generated code will change so that wsdlLocation, if you are using the default no-arg constructor on the @WebServiceClient class, will be that of the bundled WSDL (from (2)), rather than the remote WSDL. Indeed if you use -wsdllocation on your command line together with -clientjar then whatever you specify with -wsdllocation will have no effect as -clientjar will take precedence.

因此我们必须关注（2）和（3），因为这是唯一实际使用的...至少如果你按原样使用生成的代码。

So we must focus on (2) and (3) because that's the only one being actually used ... at least if you use the generated code as-is.

值得注意的是，（2）的结果只是一个WSDL文件。此文件可能已嵌入到XSD文件的链接，但据我所知，此链接永远不会被遵循。原因是，当我们说Web服务使用者在运行时需要WSDL时，它实际上只需要WSDL本身，而不是模式。模式被硬编码到消费者中，并且无法在运行时更改它。因此，没有理由在运行时读取模式信息。（这是我的理解）

It is interesting to note that the result of (2) is only a WSDL file. This file may have embedded links to XSD files but as far as I can tell such link will never be followed. The reason is that when we say a web service consumer needs the WSDL at runtime it really only needs the WSDL itself, at not the schema. The schema is "hardcoded" into the consumer and there's no way of changing it at runtime. Hence there's no reason to read schema information at runtime. (THIS IS FROM MY UNDERSTANDING)

关于（2）中包含的WSDL的第二件事：它实际上只是原始WSDL的副本，所以它可能不是有你想要的终点。实际上在大多数情况下它不会。这意味着在这种情况下，您需要自己设置端点：

Second thing to note about the WSDL that's included with (2): It is really just a copy of the original WSDL so it may not have endpoint you want. Actually in most cases it won't. This means that in this situation you'll need to set the endpoint yourself :

// Use no-arg constructor. Means it uses the WSDL bundled into the
// META-INF/wsdl directory rather than trying to retrieve WSDL over the
// network.
service = new HelloSvc_Service();
hello = service.getHelloSvcPort();

// Since we're using a bundled WSDL the web service URL cannot
// be derived from that (it would be wrong!). So we have to set
// it explicitly.
((BindingProvider) hello).getRequestContext().put(
                BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
                "http://myhellowebservice-address");

这篇关于使用带有-clientjar选项的jaxws-maven-plugin的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！