覆盖 Glassfish 生成的 WSDL 服务端点地址
我有一个由 wsgen 通过 Maven 生成的 Web 服务。当我将服务部署到 Glassfish 时，它会将服务器 URL 放入 WSDL 中。我们的 Glassfish 服务器前面有一个 Apache 代理服务器。
这一切意味着当有人访问我们的 WSDL 并查看服务端点和他们看到的肥皂地址位置时，
http://app server url/service...
而不是
http://proxy server url/service...
我想我需要对一些项目进行一些澄清...
这个端点地址重要吗？如果端点地址与客户端将调用以调用服务的代理服务器的 URL 不匹配，客户端是否仍然能够运行。这基本上会问“WSDL 到 Web 服务就像接口到对象”这样的问题。
<块引用>更新：在回答第一个问题时，确实出现了“将 Web 服务作为接口的 WSDL 就是反对”。 WSDL 中指定的端点地址并不重要。事实上，在与 WSDL 中指定的端点不同的端点上调用 Web 服务操作相对简单 如此处所述。
//从生成的Service类创建服务和代理。 HelloService 服务 = new HelloService(); HelloPort 代理 = service.getHelloPort();
//覆盖端点地址 ((BindingProvider)代理).getRequestContext().put( BindingProvider.ENDPOINT_ADDRESS_PROPERTY， “http://new/endpointaddress"); proxy.sayHello("你好世界！");当我们部署到 Glassfish 时，WSDL 会自动生成。有没有一种简单的方法可以通过应用程序服务器设置覆盖 Glassfish 中生成的端点地址。如果是这样，我可以创建一个设置来自动将代理服务器 URL 放入生成的 WSDL 中。
如果 1 确实很重要，并且我们无法以任何方式用 2 覆盖它，那么这基本上意味着我们需要为开发和生产进行单独的构建。这并不“感觉正确”，因为在我看来，部署到另一台服务器时我们需要做的唯一一件事就是将现有的（并经过测试的）战争从一个环境删除到新服务器上。
I have a web service generated by wsgen through maven. When I deploy the service to Glassfish it places the server URL into the WSDL. Our Glassfish server is fronted by an Apache proxy server.
What this all means is when someone accesses our WSDL and looks at the service endpoint and the soap address location they see is
http://app server url/service...
instead of
http://proxy server url/service...
I guess I need some clarification on a few items...
Is this endpoint address important? Will clients still be able to function if the endpoint address does not match the URL of the proxy server they will be calling to invoke the service. This basically asks the questions "is WSDL to web service as interface is to object".
UPDATE: In response to this first question it does appear that "WSDL to web service as interface is to object". The endpoint address specified in the WSDL is not important. In fact, it is relatively trivial to invoke a web service operation on a different endpoint than the one specified in the WSDL as described here.
// Create service and proxy from the generated Service class. HelloService service = new HelloService(); HelloPort proxy = service.getHelloPort();
// Override the endpoint address ((BindingProvider)proxy).getRequestContext().put( BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "http://new/endpointaddress"); proxy.sayHello("Hello World!");The WSDL is generated automatically when we deploy to Glassfish. Is there an easy way to override this generated endpoint address in Glassfish through an app server setting. If so, I can create a setting to automatically place the proxy server URL into the generated WSDL.
If 1 is indeed important and we can't override it in any way with 2, then it basically means we'll need to do separate builds for development and production. This does not "feel right" as it seems to me the only thing we should need to do to deploy to another server is drop an existing (and tested) war from one environment onto the new server.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
事实证明，部署服务的
HTTP Listener上有一个Server Name参数。您可以从 Glassfish 管理控制台指定此值，Glassfish 将在请求 URL 中使用此名称而不是主机名。不幸的是，如果您的应用程序服务器和代理服务器不使用相同的端口或协议（我们的不使用），则此参数将不允许您覆盖端口或协议（http 到 https）。
我所做的是 为我的服务编写一个简单的 servlet 过滤器来为我处理这个问题。
It turns out there is a
Server Nameparameter on theHTTP Listenerwhere the service is deployed. You can specify this value from the Glassfish administration console and Glassfish will use this name rather than the host name in the request URL.Unfortunately, this parameter will not allow you to override the port or protocol (http to https) if your app server and proxy server do not use the same ones (ours don't).
What I did instead was write a simple servlet filter for my service to handle this for me.
我发现了一个我认为非常简单的方法来处理这个问题：在 Apache 中使用 mod_substitute。由于我们这些遇到这个问题的人已经在使用 Apache，而且它是内置的且简单，所以我最喜欢这种方法。
我在我的 Apache conf 文件之一中放置了一个类似于以下内容的块，并发现了乐趣：
I discovered what I consider to be a very simple way to deal with the issue: use mod_substitute in Apache. Since those of us with this problem are already using Apache, and it's built in and simple, I liked this approach best.
I put a block similar to the below in one of my Apache conf files and found joy: