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
[
http://community.jboss.org/message/551040#551040]
Start a new discussion in JBoss Web Services CXF at Community
[
http://community.jboss.org/choose-container!input.jspa?contentType=1&...]