JBoss 4.2.2 Web服务soap：地址
我在JBoss 4.2.2中将EJB3 bean部署为Web服务。 在生产中，服务器位于Apache服务器后面，该服务器将请求重定向到Jboss服务器。 这使得WSDL具有错误的soap：地址位置。 我能够通过server \ default \ deploy \ jbossws.sar \ jbossws.beans \ META-INF中的配置文件更改端口和主机名，但是我无法将协议切换到https 。
我发现的唯一方法是指定我自己的WSDL（通过这里 ）。 通过在WSDL中指定https，JBoss会发现它是https。 但是，尽管在生产中这很好，但在QA中没有使用https（并且连接到它的服务需要有效的https，因此自签名证书不会这样做）。 因此，虽然我可以获得QA的真实证书（假证书颁发机构不会这样做），但我宁愿将其作为QA中的http。 有没有办法强制JBoss更改协议或以其他方式更改地址，以便它在soap：地址中使用http？
编辑：似乎这个问题最近在他们的bug数据库中提出并被拒绝。 这对我来说意味着他们有一个解决方法。 但它是什么？
进一步编辑：此时，我知道EJB3拦截器不起作用（ 它们根本没有被激活 ），并且SOAPHandler不拦截调用以检索WSDL（经过测试 – 它们会拾取其他所有内容）。 所以filter的想法很吸引人，但目前还不清楚它的位置。
JBoss显示的URL是：
端点名称jboss.ws:context=QuickBooks-QuickBooksWebService,endpoint=QBWSBeanEJB端点地址https://127.0.0.1:8443/QuickBooks-QuickBooksWebService/QBWSBeanEJB?wsdl
（注意，当我使用自定义WSDL强制https但JBoss配置为重写它时）。
我正在使用的JBossWS版本是与4.2.2捆绑在一起的版本，根据这个版本是2.0.1
编辑：关于重写 ，这确实是尝试过。 这是我发现的。 我可以让它重写主机（或不需要）和端口，但仅限于已识别的协议。 因此，为了让它发出https，我必须将bean的传输保证配置为CONFIDENTIAL，并在JBoss服务器上启用https，然后所有请求都被重定向到JBoss中的https。 我没有测试这是否适用于mod_jk（如果需要CONFIDENTIAL，AJP协议是否仍然有效，如果请求来自AJP，WSDL会获得正确的协议吗？我没有测试它），但是这样做具有相同的净效果 – 请求必须超过https。 没有办法让请求通过http或AJP进入，然后让它发出一个soap：地址作为https，特别是基于每个服务器配置（在QA和dev，http，但在生产https中，即使ssl被Apache终止。 使用自定义WSDL让我更接近，因为请求是在HTTP上进行的，但soap：地址表示https。 完美的生产（使用重写function将端口推送到443而不是8443），但对于QA无用（我不关心开发，因为开发版可能会有所不同，如果需要可以创建一个不同的jar，但我’如果我可以避免它，我对QA和具有不同构建过程的制作不满意。
为什么不在Web应用程序上设置servletfilter来监视WSDL请求并使用其配置中的值重写响应中的soap:address ？ 然后你可以随意设置它。
它可能不是最优雅的解决方案，我同意:-) – 但那可能是在JBoss中的可配置性，不是吗？ 如果JBoss最终引入了这个function，你可以删除filter。
更新：典型的JBoss EAR具有以下结构：
myapp.ear
| + META-INF
| + applications.xml和jboss-app.xml
| + myapp.war
| +网页和JSP / JSF页面
| + WEB-INF
| + web.xml，jboss-web.xml，faces-config.xml等。
| + lib
| +标签库JAR
| +课程
| + servlets和网页使用的其他类
| + myapp.jar
| + EJB3 bean类
| + META-INF
| + ejb-jar.xml和persistence.xml
| + lib
| + EAR的库JAR
您能否确认部署的EAR具有此结构？ 如果没有，它有什么不同？
更新＃2： JBoss自动为EJB3 bean生成一个web.xml ，它位于正在部署的EAR内的JAR中。 这个web.xml肯定是硬编码的（即不用作你可以调整的XML文件的基础），所以将这个改为包括filter（你基本上需要改变各种各样）很尴尬（尽管不是不可能） jboss-beans.xml东西指向你自己的web.xml生成器，它可以做任何你想做的事情。 如果EJB3 bean位于WAR文件中，那么开发工作就会少得多 – 那么你可以使用WAR的web.xml传统地配置Filter，你可能已经控制了它。 但是，如果您使用的是第三方JAR，那么这可能会有问题 – 或者可能不会。 在不知道细节的情况下，很难看出哪种方法最好。
从问题的作者编辑：
感谢您的所有努力。 这似乎是基本方法 – 拦截和更改WSDL。 如果你不能让你的webservice成为战争中分配的POJO，你可以在那里使用servletfilter，那么你可以创建一个代理请求的servlet，并以这种方式执行。 那是我的解决方案 。
我们在过去遇到过类似的问题，并且决定在所有QA环境中使用SSL（有缺点 – 特别是在调试HTTP流时 – 但没有缺点？）
这可能比您想象的更容易，因为您似乎可以控制所涉及的所有环境：您基本上只需要告诉Java您的自签名证书是“好的”。 为此，您需要将自己添加为Java中的证书颁发机构。
这里有一个很好的概述：
http://en.wikibooks.org/wiki/WebObjects/Web_Services/How_to_Trust_Any_SSL_Certificate
以下是Sun提供的有关KeyStore工具的信息（尽管您应该查找特定于您的版本/ JVM的参考，因为存在差异）：
http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/keytool.html
完成此操作后，QA中的自签名证书将在Java中100％“有效”。
您甚至可以在Prod中节省一些钱：如果您控制环境的两面，您可以在Prod中自行颁发证书并节省一些现金。 哎呀，如果您的用户社区很小/控制得足够多，您也可以直接在客户端浏览器中添加自签名权限（虽然看起来它的价值会更麻烦）。
希望这能让你朝着有用的方向前进！
基本上我发现的唯一解决方案是创建一个拦截和代理WSDL请求的servlet。 我从Apache的数据透视项目中复制并实现了ProxyServlet（它进行了一些非实质性的更改，例如Apache实现只写了响应而不是post）。 基本上，实现检查请求是否是对WSDL的请求，并更改WSDL中的soap：address属性。 很难，但是，它解决了这个问题，但整个事情仍然没有奏效，因为在我们进行沟通后，还有一个问题。 关于我的另一个问题我猜。