JBoss 4.2.2 Web服务soap:地址 [英] JBoss 4.2.2 web service soap:address

查看:93
本文介绍了JBoss 4.2.2 Web服务soap:地址的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在JBoss 4.2.2中将EJB3 bean部署为Web服务。在生产中,服务器位于Apache服务器后面,该服务器将请求重定向到Jboss服务器。这使得WSDL具有错误的soap:地址位置。我能够通过server\default\deploy\jbossws.sar\jbossws.beans \ METET-INF中的配置文件更改端口和主机名,但我无法将其更改为将协议切换为https。

I have an EJB3 bean deployed as a web service in JBoss 4.2.2. In production the server is behind an Apache server that redirects requests to the Jboss server. This makes the WSDL have the wrong soap:address location. I was able to get the port and host name changed via the configuration file in server\default\deploy\jbossws.sar\jbossws.beans\META-INF, but I haven't been able to get it to switch the protocol to https.

我发现的唯一方法是指定我自己的WSDL(通过这里)。通过在WSDL中指定https,JBoss会发现它是https。但是,尽管在生产中这很好,但在QA中没有使用https(并且连接到它的服务需要有效的https,因此自签名证书不会这样做)。因此,虽然我可以获得QA的真实证书(假证书颁发机构不会这样做),但我宁愿在质量保证中将其作为http。有没有办法强制JBoss更改协议或以其他方式更改地址,以便它在soap:地址中使用http?

The only way that I found was to specify my own WSDL (via here). By specifying https in the WSDL, JBoss picks up that it is https. However, although that is fine in production, in QA https is not used (and the service that connects to it requires valid https, so self-signed certificates won't do). So while I could get a real certificate for QA (fake certificate authorities won't do), I would rather have it be http in QA. Is there a way to force JBoss to change the protocol or otherwise change the address so that it uses http in the soap:address?

编辑:似乎这个问题是最近在他们的错误数据库中提出并被拒绝。这对我来说意味着他们有一个解决方法。但它是什么?

It seems like this issue was brought up recently in their bug database and was rejected. That would imply to me that they have a work around. But what is it?

进一步编辑:此时,我知道EJB3拦截器不起作用(它们根本没有被激活)并且SOAPHandler不拦截调用以检索WSDL(经过测试 - 它们接收其他所有内容) 。所以过滤器的想法很吸引人,但目前还不清楚它的位置。

Further At this point, I know that an EJB3 Interceptor doesn't work (they are not activated at all) and SOAPHandler's don't intercept the call to retrieve the WSDL (tested - they pick up everything else). So the filter idea is intriguing, but it is far from clear where to put it.

JBoss显示的URL是:

The URL as shown by JBoss is:

端点名称jboss.ws:context=QuickBooks-QuickBooksWebService,endpoint=QBWSBeanEJB
端点地址 https://127.0.0.1:8443/QuickBooks-QuickBooksWebService/QBWSBeanEJB?wsdl

Endpoint Name jboss.ws:context=QuickBooks-QuickBooksWebService,endpoint=QBWSBeanEJB Endpoint Address https://127.0.0.1:8443/QuickBooks-QuickBooksWebService/QBWSBeanEJB?wsdl

(请注意,我使用的时候)自定义WSDL强制https,但JBoss配置为重写它。)

(Note that is when I use the custom WSDL to force https but JBoss is configured to rewrite it).

我正在使用的JBossWS的版本是与4.2.2捆绑的版本,根据为2.0.1

The version of JBossWS I'm using is what is bundled with 4.2.2, which according to this is 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。完美的生产(使用重写功能将端口推送到443而不是8443),但对QA无用(我不关心开发,因为开发构建可能会有所不同,如果需要可以创建一个不同的jar,但我'如果可以避免的话,我不满意QA和生产有不同的构建过程。)

With regards to the rewriting, this was indeed attempted. Here is what I found. I could get it to rewrite the host (or not as needed) and the port, but only for the recognized protocol. So in order to get it emit an https, I had to configure the bean's transport guarantee to CONFIDENTIAL, and enable https on the JBoss server, then all requests were redirected to https within JBoss. I didn't test if this would even work with mod_jk (does the AJP protocol still work if CONFIDENTIAL is required, and will the WSDL get the right protocol if the request comes over AJP? I didn't test it), however doing that has the same net effect - the requests must go over https. There is no way to have the request come in over http or AJP and then have it emit a soap:address as https, specifically configured on a per-server basis (in QA and dev, http, in but in production https even though the ssl was terminated by Apache). Using the custom WSDL got me closer, in that the request is coming in on HTTP, but the soap:address says https. Perfect for production (using the rewrite feature to push the port to 443 instead of 8443), but useless for QA (dev I don't care about, because the dev build could be different and create a different jar if needed, but I'm not comfortable with QA and production having different build processes if I can avoid it).

推荐答案

你为什么不设置Web应用程序上的servlet过滤器,用于监视WSDL请求并使用其配置中的值重写响应中的 soap:address ?然后你可以根据需要进行设置。

Why don't you set up a servlet filter on your web application which watches for WSDL requests and rewrites the soap:address in the responses using values from its configuration? Then you can set it up however you want.

它可能不是最优雅的解决方案,我同意:-) - 但那可能是为了可配置性在JBoss,不是吗?如果JBoss最终引入了这个功能,你可以删除过滤器。

It may not be the most elegant solution, I agree :-) - but then that would have been for the configurability to be in JBoss, wouldn't it? And if JBoss eventually introduces this feature, you can just remove the filter.

更新:典型的JBoss EAR具有以下结构:

Update: A typical JBoss EAR has the following structure:


myapp.ear
|+ META-INF
   |+ applications.xml and jboss-app.xml
|+ myapp.war
   |+ web pages and JSP /JSF pages
   |+ WEB-INF
      |+ web.xml, jboss-web.xml, faces-config.xml etc.
      |+ lib
         |+ tag library JARs
      |+ classes
         |+ servlets and other classes used by web pages
|+ myapp.jar
   |+ EJB3 bean classes
   |+ META-INF
      |+ ejb-jar.xml and persistence.xml
|+ lib
   |+ Library JARs for the EAR

您能确认部署的EAR是否具有此结构?如果没有,它有什么不同?

Can you confirm that your deployed EAR has this structure? If not, how is it different?

更新#2: JBoss会自动生成 web.xml 用于EJB3 bean,它们位于正在部署的EAR内的JAR中。这个 web.xml 绝对是硬编码的(即不用作你可以调整的XML文件的基础),所以它很尴尬(尽管不是不可能)更改此项以包含过滤器(您基本上需要更改 jboss-beans.xml 中的各种内容以指向您自己的 web.xml 生成器,它可以做你想做的任何事情)。如果EJB3 bean在WAR文件中,那么开发工作就会少得多 - 那么你可以使用WAR的 web.xml 来传统地配置过滤器,你可能已经控制了它过度。但是,如果您使用的是第三方JAR,那么这可能会有问题 - 或者可能不会。在不知道细节的情况下,很难看出哪种方法最好。

Update #2: JBoss automatically generates a web.xml for EJB3 beans which are in a JAR inside the EAR being deployed. This web.xml is definitely hard-coded (i.e. doesn't use as a basis an XML file which you can tweak) and so it is awkward (though not impossible) to change this to include a filter (you basically need to change various things in jboss-beans.xml to point to your own web.xml generator, which can do whatever you want). It would be a lot less development work if the EJB3 beans were in the WAR file - then you can configure the Filter conventionally using the WAR's web.xml, which you presumably have control over. However, that might be problematic if that's a third-party JAR you're using - or it might not. Without knowing the details it's hard to see which the best approach will be.

从问题的作者编辑:

感谢您的努力。这似乎是基本方法 - 拦截和更改WSDL。如果你不能让你的webservice成为战争中分配的POJO,你可以在那里使用servlet过滤器,那么你可以创建一个代理请求的servlet,并以这种方式执行。 这是我的解决方案

Thanks for all the effort. This appears to be the basic approach - intercept and change the WSDL. If you can't make your webservice a POJO assigned in the war, where you can use a servlet filter, then you can make a servlet that proxies the request, and do it that way. That was my solution.

这篇关于JBoss 4.2.2 Web服务soap:地址的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆