[ http://jira.jboss.com/jira/browse/JBTM-266?page=all ] Mark Little reassigned JBTM-266: -------------------------------- Assignee: Andrew Dinn (was: Mark Little) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBTM-266?page=com.atlassian.jira.plugi... ] Andrew Dinn closed JBTM-266. ---------------------------- Resolution: Won't Fix This is not going to work without a WSA implementation for JBossWS/Metro. I did actually manage to get close to getting this to work by hacking the Native implementation and testing it under Glassfish but then I came across two showstopper bugs: In order to support fault delivery the WS-T/C service endpoints need to provide WebMethod implementations derived from two WSDL APIs, the WS-C/T port operations and the SoapFaultService operations. Metro will not allow a web service endpoint to include WebMethod implementations not declared in the WSDL used to define its interface. JBossWS Native and CXF both allow this and the spec does not require such zealous validation. Even if the fault delivery is supported by providing a separate SoapFaultService endpoint which forwards the faults to the relevant endpoint instance Metro will not deliver the fault. It assumes that a fault posted to a JaxWS web service must be a mistake. This is so even if the WSDL for the service explicitly specifies an operation whose incoming message type and SOAP action are a fault. Once again, JBossWS Native and CXF both allow this and the spec does not require such zealous validation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira