[jboss-user] [JBoss Web Services CXF] - Continuing problem with XTS WS-T tests in AS trunk/CXF 2.2.9

Andrew Dinn do-not-reply at jboss.com
Mon Jul 5 10:02:42 EDT 2010

Andrew Dinn [http://community.jboss.org/people/adinn] replied to the discussion

"Continuing problem with XTS WS-T tests in AS trunk/CXF 2.2.9"

To view the discussion, visit: http://community.jboss.org/message/551040#551040

Hi Jim,

Apologies for the delay in getting bak. It's been a long haul working through the rets of the changes needed after you fixed the soap fault delivery problem.
> Jim Ma wrote:
> I attched the pached jars and source files to  https://jira.jboss.org/browse/JBWS-3069 https://jira.jboss.org/browse/JBWS-3069. Please let me know if you have furthur CXF issues. Thanks.
The patches work fine and soap fault delivery is happening as expected.

Unfortunately, I then ran into a further problem which meant that I was not able to employ a separate SOAP service to dispatch/catch the faults. CXF includes metadata in its W3C endpoints so I can no longer take an endpoint derived from one of the WS-T services and pass it to the getPort method of my SoapFaultService. This means that I have had no choice but to explicitly include the soap fault delivery method in my WS-T service WSDL and generate corresponding methods on the SEI interfaces and implementation beans.

So, I am now having to use a non-standard WSDL and non-standard endpoint for these services. We can live with this because the service is a conservative extension of the expected implementation (i.e. it does everything expected and then some).

So, it looks as if you can close JBWS-3069.

I ran into one other problem which does not break anything immediately but will be an issue for interoperability, specifically with Microsoft. When my services get an incoming request they normally need to hand back an endpoint for a continuation message. If the incoming request arrives via an https scheme URL then the endpoint for the the continuation should be created using an https scheme. So, in the WebMethod implementation I use code as follows to identify the request scheme

> @WebMethod(...)
> public void foo()
> {
>     MessageContext ctx = webServiceCtx.getMessageContext();
>     HttpServletRequest request = (HttpServletRequest)ctx.get(MessageContext.SERVLET_REQUEST);
>     boolean isSecure = "https".equals(request.getScheme());
>     . . .
The problem is that when foo is a OneWay method request.getScheme always returns null. Now this does not break anything (it did when I did the equals test the other way round which is why I spotted it :-) but it does mean that I always think the client is contacting the services via a non-secure URL. Now, Microsoft's WSTX always uses https and it will throw up if handed an http endpont for the continuation message. So, I need a reliable way to obtain the request scheme when the message is OneWay. Any ideas? Or do I have to raise a JIRA feature request for this?


Reply to this message by going to Community

Start a new discussion in JBoss Web Services CXF at Community

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-user/attachments/20100705/47df54bd/attachment-0001.html 

More information about the jboss-user mailing list