XTS tests broken in AS trunk after switch to CXF stack in 3.3.0

[adinn]

The XTS test suite is severely broke in the latest AS trunk. There appear to be many failures although it is likely that these are all caused by some initial problem.

The problem manifests in the WS-C tests. Each of these tests attempts to communicate with the Activation Coordinator service using an RPC style message. The message gets through and is processed but then a problem occurs in the interceptor chain when processing the response. This results in a fault being returned to the client causing the test to abort.

The problem occurs under the MAPAggregator interceptor: Here is the stack trace on the server side:

10:55:27,901 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] Interceptor for {http://docs.oasis-open.org/ws-tx/wscoor/2006/06}ActivationService#{http://docs.oasis-open.org/ws-tx/wscoor/2006/06}CreateCoordinationContextOperation has thrown exception, unwinding now: java.lang.NullPointerException
    at org.apache.cxf.ws.addressing.ContextUtils.getAction(ContextUtils.java:826) [:2.2.8]
    at org.apache.cxf.ws.addressing.ContextUtils.getActionFromMessageAttributes(ContextUtils.java:804) [:2.2.8]
    at org.apache.cxf.ws.addressing.ContextUtils.getActionFromServiceModel(ContextUtils.java:740) [:2.2.8]
    at org.apache.cxf.ws.addressing.ContextUtils.getAction(ContextUtils.java:711) [:2.2.8]
    at org.apache.cxf.ws.addressing.MAPAggregator.assembleGeneric(MAPAggregator.java:425) [:2.2.8]
    at org.apache.cxf.ws.addressing.MAPAggregator.aggregate(MAPAggregator.java:398) [:2.2.8]
    at org.apache.cxf.ws.addressing.MAPAggregator.mediate(MAPAggregator.java:344) [:2.2.8]
    at org.apache.cxf.ws.addressing.MAPAggregator.handleMessage(MAPAggregator.java:159) [:2.2.8]
    at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243) [:2.2.8]
    at org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(OutgoingChainInterceptor.java:78) [:2.2.8]
    at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243) [:2.2.8]
    at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:110) [:2.2.8]
    at org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:98) [:2.2.8]
    at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:423) [:2.2.8]
    at org.jboss.wsf.stack.cxf.ServletControllerExt.invoke(ServletControllerExt.java:175) [:3.3.0.GA]
    at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:57) [:3.3.0.GA]
    at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:126) [:3.3.0.GA]
    at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179) [:2.2.8]
    at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103) [:2.2.8]
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:754) [:1.0.0.Beta2]
    at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159) [:2.2.8]
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:336) [:]
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [:]
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:293) [:]
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) [:]
    at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:181) [:6.0.0-SNAPSHOT]
    at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.event(CatalinaContext.java:285) [:1.1.0.CR2]
    at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.invoke(CatalinaContext.java:261) [:1.1.0.CR2]
    at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:88) [:6.0.0-SNAPSHOT]
    at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:93) [:6.0.0-SNAPSHOT]
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) [:]
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [:]
    at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) [:6.0.0-SNAPSHOT]
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [:]
    at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:53) [:6.0.0-SNAPSHOT]
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [:]
    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:876) [:]
    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [:]
    at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [:]
    at java.lang.Thread.run(Thread.java:619) [:1.6.0_14]

The method which is failing is

    public static String getAction(Extensible ext) {
        Object o = ext.getExtensionAttribute(JAXWSAConstants.WSAW_ACTION_QNAME);
        if (o == null) {
            o = ext.getExtensionAttributes().get(new QName(Names.WSA_NAMESPACE_WSDL_METADATA,
                                                           Names.WSAW_ACTION_NAME));
        }
        if (o == null) {
            o = ext.getExtensionAttributes().get(new QName(Names.WSA_NAMESPACE_WSDL_NAME_OLD,
                                                   Names.WSAW_ACTION_NAME));
        }
        if (o instanceof QName) {
            return ((QName)o).getLocalPart();
        }
        return o.toString(); // <=== fails here
    }

This looks weird to me. The ext object has an action value as follows

ext

- extensionAttributes {java.util..HashMap} size = 1

  - [0]

   - key = javax.xml.namespace.QName {http://www.w3.org/2005/08/addressing}Action

   - value = javax.xml.namespace.QName http://docs.oasis-open.org/ws-tx/wscoor/2006/06/CreateCoordinationContextResponse

The code is not looking for this property though. The properties it is using in the lookup are

JAXWSAConstants.WSAW_ACTION_QNAME
  ==> {http://www.w3.org/2006/05/addressing/wsdl}Action
new QName(Names.WSA_NAMESPACE_WSDL_METADATA, Names.WSAW_ACTION_NAME)
  ==> "http://www.w3.org/2007/05/addressing/metadata}Action
new QName(Names.WSA_NAMESPACE_WSDL_NAME_OLD, Names.WSAW_ACTION_NAME)
  ==> {http://www.w3.org/2005/02/addressing/wsdl}Action

This seems whacko to me. Why is the lookup not using {http://www.w3.org/2005/08/addressing/wsdl}Action?

[asoldano]

This might be a bug introduced while working on JAXWS 2.2 impl in CXF, so we should come to a jira to create at Apache.

Let's clarify the situation a bit first then: it seems to me the problem here is that cxf does not consider the action provided in the message, which is what you'd expect, right?

CXF instead goes throught the model constructed from the wsdl and try to get the action from that. That's why it's looking at the soap binding part of ws-addressing (http://www.w3.org/TR/ws-addr-wsdl/), which defines namespace http://www.w3.org/2006/05/addressing/wsdl for the Action element.

[adinn]

Alessio Soldano wrote:

Let's clarify the situation a bit first then: it seems to me the problem here is that cxf does not consider the action provided in the message, which is what you'd expect, right?

CXF instead goes throught the model constructed from the wsdl and try to get the action from that. That's why it's looking at the soap binding part of ws-addressing (http://www.w3.org/TR/ws-addr-wsdl/), which defines namespace http://www.w3.org/2006/05/addressing/wsdl for the Action element.

I don't think that is what is happening here. I believe it is the endpoint annotations not the WSDL which is being used. My endpoint implemenation bean and the method which is failing are coded as follows

@WebService(targetNamespace = "http://docs.oasis-open.org/ws-tx/wscoor/2006/06", name = "ActivationPortType",
        wsdlLocation = "/WEB-INF/wsdl/wscoor-activation-binding.wsdl",
        serviceName = "ActivationService",
        portName = "ActivationPortType"
)
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
// @EndpointConfig(configName = "Standard WSAddressing Endpoint")
@HandlerChain(file="/handlers.xml")
@Addressing(required=true)
public class ActivationPortTypeImpl implements ActivationPortType
{
    @Resource private WebServiceContext webServiceCtx;

    @WebMethod(operationName = "CreateCoordinationContextOperation", action = "http://docs.oasis-open.org/ws-tx/wscoor/2006/06/CreateCoordinationContext")
    @WebResult(name = "CreateCoordinationContextResponse", targetNamespace = "http://docs.oasis-open.org/ws-tx/wscoor/2006/06", partName = "parameters")
    @Action(input="http://docs.oasis-open.org/ws-tx/wscoor/2006/06/CreateCoordinationContext", output="http://docs.oasis-open.org/ws-tx/wscoor/2006/06/CreateCoordinationContextResponse")
    public CreateCoordinationContextResponseType createCoordinationContextOperation(
        @WebParam(name = "CreateCoordinationContext", targetNamespace = "http://docs.oasis-open.org/ws-tx/wscoor/2006/06", partName = "parameters")
        CreateCoordinationContextType parameters)
    {
      . . .

As you can see the output response action is specified using the @Action annotation.

Now looking at the exception stack you cqan see that when MAPAggregator executes as part of the output pipeline processing it tries to obtain the action associated with the response message by calling ContextUtils.getAction(message). This calls Contextutils.getActionFromServiceModel(message,  null) which obtains the outbound message info and calls Contextutils.getActionFromMessageAttributes(msgInfo). The latter makes the call to ContextUtils.getAction(msgInfo) which blows up.

Now the odd thing is that message info  has an action associated with it in the extension attributes hashmap and CXF has put it there. The key for the atribute is {http://www.w3.org/2005/08/addressing}Action and the value is the one I specified in the @Action annotation. The lookup in MAPAggregator is trying to look it up using all the other possible keys (2006/05, 2007/05 etc) but not the one for the value which has been installed in the attributes map. Since this causes it to fall over when it fails to find an entry in the map I suspect the problem is that it is using the wrong key for the first test in ContextUtils.getAction(). Where it says

Object o = ext.getExtensionAttribute(JAXWSAConstants.WSAW_ACTION_QNAME);

I believe it should say

Object o = ext.getExtensionAttribute(JAXWSAConstants.WSA_ACTION_QNAME);

However, I don't see how this could ever have passed any sensible sort of QA process.

[ropalka]

public static String getAction(Extensible ext) {
    Object o = ext.getExtensionAttribute(JAXWSAConstants.WSAW_ACTION_QNAME);
    if (o == null) {
        o = ext.getExtensionAttributes().get(new QName(Names.WSA_NAMESPACE_WSDL_METADATA,
                                                       Names.WSAW_ACTION_NAME));
    }
    if (o == null) {
        o = ext.getExtensionAttributes().get(new QName(Names.WSA_NAMESPACE_WSDL_NAME_OLD,
                                               Names.WSAW_ACTION_NAME));
    }
    if (o instanceof QName) {
        return ((QName)o).getLocalPart();
    }
    return o.toString(); // <=== fails here
}

This is known/expected issue. CXF 2.2.8 (currently in use)

doesn't implement JAX-WS 2.2 yet. This should be fixed soon in upcomming CXF releases.

[asoldano]

Richard, can you elaborate on why this is expected given cxf is not full jaxws 2.2 compliant yet? afaik Andrew was running this against jbossws-cxf before the 3.3.0 update (hence with cxf 2.2.5), right?

Andrew, ok, perhaps you can provide a testcase or send me a deployment I can try to reproduce the issue with? I'd also check what happens with cxf 2.2.5...

[ropalka]

Is it true Andrew it was tested with cxf 2.2.5?

If yes, could you create a JIRA and provide a

simple test case to reproduce that problem?

[jim.ma]

The Contextutils.getActionFromMessageAttributes(msgInfo)  is intended to get action value when there is no wsdl provided in service impl class(Service built from class)  CXF simply uses MessageInfo.getExtensionAttributes() != null to check if this service is built from service class (with no wsdl location provided) . There is probably some issue when the wsdl have extension to put in the extensionAttributes of MessageInfo . The NPE guard should be added in ContextUtils.getAction() .  Andrew, can you paste the  wsdl ?  Is there anything special in your wsdl file ?

[adinn]

Richard Opalka wrote:

Is it true Andrew it was tested with cxf 2.2.5?

If yes, could you create a JIRA and provide a

simple test case to reproduce that problem?

Well, I ran this on AS trunk which uses JBossWS 3..3.0. The release notes for 3.3.0 state that it is based on CXF 2.2.8.

These tests worked fine on hudson running on AS trunk up to 31 May. After that the hudson build started failing. I believe this coincided with the installation of 3.3.0 into AS trunk and the consequent switch to use CXF as the WS stack. Now it may be that the tests also fail on an older JBossWS-CXF -- I don't know about that for sure. But they certainly fail now on 3.3.0-CXF.

The error seems obvious and simple to me:

when creating the reply message CXF processes the @Action{output=XXX} annotation and installs the extension attribute

• [key=JAXWSAConstants.WSA_ACTION_QNAME, value = XXX] in the msginfo.

when aggregating the reply MAP values CXF looks up the action in the msginfo using keys

• JAXWSAConstants.WSAW_ACTION_QNAME,
• Names.WSA_NAMESPACE_WSDL_METADATA+Names.WSAW_ACTION_NAME

•  
  Names.WSA_NAMESPACE_WSDL_NAME_OLD+Names.WSAW_ACTION_NAME
  
  

none of these match the key it used to install the property but it clearly expects that one of them must match.

Now, it looks to me like the check  is either using the wrong key (miscoded JAXWSAConstants.WSAW_ACTION_QNAME for JAXWSAConstants.WSA_ACTION_QNAME) or else has omitted to also check for th installed key. I guess it is remotely possible that this check is only supposed to find actions installed using the 3 keys it actually tries. However,  in that case i) it needs to guard against null and ii) something else later on ought to be looking for the action using the installed key. I find it hard to believe that this is actually the case.

[adinn]

Hi Jim,

Jim Ma wrote:

The Contextutils.getActionFromMessageAttributes(msgInfo)  is intended to get action value when there is no wsdl provided in service impl class(Service built from class)  CXF simply uses MessageInfo.getExtensionAttributes() != null to check if this service is built from service class (with no wsdl location provided) . There is probably some issue when the wsdl have extension to put in the extensionAttributes of MessageInfo . The NPE guard should be added in ContextUtils.getAction() .  Andrew, can you paste the  wsdl ?  Is there anything special in your wsdl file ?

There is wsdl provided in the service imple class as my earlier post showed

@WebService(targetNamespace = "http://docs.oasis-open.org/ws-tx/wscoor/2006/06", name = "ActivationPortType",
        wsdlLocation = "/WEB-INF/wsdl/wscoor-activation-binding.wsdl",
        serviceName = "ActivationService",
        portName = "ActivationPortType"
)
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
// @EndpointConfig(configName = "Standard WSAddressing Endpoint")
@HandlerChain(file="/handlers.xml")
@Addressing(required=true)
public class ActivationPortTypeImpl implements ActivationPortType
{

    . . .

There is nothing unusual about this wsdl. It extends a standard wsdl defined by OASIS WS-C with a binding for the Activation Coordinator service.

<?xml version="1.0" encoding="utf-8"?>
<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wscoor="http://docs.oasis-open.org/ws-tx/wscoor/2006/06" targetNamespace="http://docs.oasis-open.org/ws-tx/wscoor/2006/06" xmlns:wsaw="http://www.w3.org/2006/02/addressing/wsdl">

  <wsdl:import
      namespace="http://docs.oasis-open.org/ws-tx/wscoor/2006/06"
      location="wscoor.wsdl" />

  <wsdl:binding name="Activation_SOAPBinding" type="wscoor:ActivationPortType">
    <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
    <wsdl:operation name="CreateCoordinationContextOperation">
            <soap:operation soapAction="http://docs.oasis-open.org/ws-tx/wscoor/2006/06/CreateCoordinationContext"/>
            <wsdl:input message="wscoor:CreateCoordinationContext">
                <soap:body use="literal"/>
            </wsdl:input>
            <wsdl:output message="wscoor:CreateCoordinationContextResponse">
                <soap:body use="literal"/>
            </wsdl:output>
        </wsdl:operation>
  </wsdl:binding>

  <wsdl:service name="ActivationService">
     <wsdl:port binding="wscoor:Activation_SOAPBinding" name="ActivationPortType">
       <wsaw:UsingAddressing required="true"/>
      <soap:address location="http://localhost:9000/ws-c11/ActivationService"/>
    </wsdl:port>
  </wsdl:service>

</wsdl:definitions>

The imported file wscoor.wsdl is exactly as provided by the OASIS WS-C 1.1 standard. It merely defines the types and messages for the Activation Coordinator and Registration Coordinator web services.

<?xml version="1.0" encoding="utf-8"?>
<!--
OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS President.
OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS President.
Copyright OASIS Open 2006. All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself must not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-->
<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wscoor="http://docs.oasis-open.org/ws-tx/wscoor/2006/06" targetNamespace="http://docs.oasis-open.org/ws-tx/wscoor/2006/06">
        <wsdl:types>
          <xs:schema>
        <!--
            <xs:import
                namespace='http://www.w3.org/2005/08/addressing'
                schemaLocation='ws-addr.xsd' />
        -->
            <xs:import
                namespace='http://docs.oasis-open.org/ws-tx/wscoor/2006/06'
                schemaLocation='wscoor.xsd' />
          </xs:schema>
        </wsdl:types>
  <!-- Messages -->
  <wsdl:message name="CreateCoordinationContext">
    <wsdl:part name="parameters" element="wscoor:CreateCoordinationContext"/>
  </wsdl:message>
  <wsdl:message name="CreateCoordinationContextResponse">
    <wsdl:part name="parameters" element="wscoor:CreateCoordinationContextResponse"/>
  </wsdl:message>
  <wsdl:message name="Register">
    <wsdl:part name="parameters" element="wscoor:Register"/>
  </wsdl:message>
  <wsdl:message name="RegisterResponse">
    <wsdl:part name="parameters" element="wscoor:RegisterResponse"/>
  </wsdl:message>
  <!-- Port Types -->
  <wsdl:portType name="ActivationPortType">
    <wsdl:operation name="CreateCoordinationContextOperation">
      <wsdl:input message="wscoor:CreateCoordinationContext"
        wsa:Action="http://docs.oasis-open.org/ws-tx/wscoor/2006/06/CreateCoordinationContext"/>
      <wsdl:output message="wscoor:CreateCoordinationContextResponse"
        wsa:Action="http://docs.oasis-open.org/ws-tx/wscoor/2006/06/CreateCoordinationContextResponse"/>
    </wsdl:operation>
  </wsdl:portType>
  <wsdl:portType name="RegistrationPortType">
    <wsdl:operation name="RegisterOperation">
      <wsdl:input message="wscoor:Register"
        wsa:Action="http://docs.oasis-open.org/ws-tx/wscoor/2006/06/Register"/>
      <wsdl:output message="wscoor:RegisterResponse"
        wsa:Action="http://docs.oasis-open.org/ws-tx/wscoor/2006/06/RegisterResponse"/>
    </wsdl:operation>
  </wsdl:portType>
</wsdl:definitions>

Anyway, the problem does not seem to me to be anything to do with the wsdl nor indeed the service impl bean definition. Both the wsdl and the @Action annotation specify that the reponse should use the same action

http://docs.oasis-open.org/ws-tx/wscoor/2006/06/CreateCoordinationContextResponse

and indeed that is the actionstored in the msginfo hashmap. The problem is that CXF is storing it with one key and looking it up with different keys.

I don't think the problem is safeguarded just by checking for null. Somehgow the MAPAggregator shoudl idenitfy that an Acton was provided. I think it should be looking for a map entry with the key under which the action has been installed. If it does not detect it this way how else will it idenitfy that the action was specified in the wsdl and in the @Action annotation?

[asoldano]

https://jira.jboss.org/browse/JBWS-3060

Andrew, if you can isolate a testcase, feel free to attach that to the jira. Otherwise I'll try to get that from the WS-C stuff here http://anonsvn.jboss.org/repos/labs/labs/jbosstm/trunk/XTS/WS-C/ , right? Thanks.

[jim.ma]

Hi Andrew ,

I noticed the action namespace for wsdl:input is "http://www.w3.org/2005/08/addressing" in the wscoor.wsdl:

<wsdl:input  message="wscoor:CreateCoordinationContext"
wsa:Action="http://docs.oasis-open.org/ws-tx/wscoor/2006/06/CreateCoordinationContext"/>

From http://www.w3.org/TR/2006/CR-ws-addr-wsdl-20060529 Example 4-2, should it be wsaw:Action="..." ? 

If the wsa:Action is also valid namespace for ws-addressing action, then it is an issue in CXF.

[adinn]

Jim Ma wrote:

Hi Andrew ,

I noticed the action namespace for wsdl:input is "http://www.w3.org/2005/08/addressing" in the wscoor.wsdl:

<wsdl:input  message="wscoor:CreateCoordinationContext"
wsa:Action="http://docs.oasis-open.org/ws-tx/wscoor/2006/06/CreateCoordinationContext"/>

From http://www.w3.org/TR/2006/CR-ws-addr-wsdl-20060529 Example 4-2, should it be wsaw:Action="..." ? 

If the wsa:Action is also valid namespace for ws-addressing action, then it is an issue in CXF.

Hmm, interestingly the published wscoor.wsdl has changed. The version I posted above was the published one when I built the code two years ago and is the one my code includes. Looking at the latest version of the wsdl on the OASIS site I notice that the wsa:Action attributes have been removed from the port specifications. However, the schema file wscoor.xsd which the wsld file references still employs the 2005/08 namespace.

I will try rebuilding the app with the latest published wsdl i.e. without the Action attributes in the wsdl. However, even if this does work the question is whether CXF ought to handle actions registered using the 2005/08 namespace. There may be other apps out  there with out of date wsdl.

[adinn]

Andrew Dinn wrote:

I will try rebuilding the app with the latest published wsdl i.e. without the Action attributes in the wsdl. However, even if this does work the question is whether CXF ought to handle actions registered using the 2005/08 namespace. There may be other apps out  there with out of date wsdl.

I rebuilt the services with all wsa:Action attributes removed from the WSDL and the Activation Service is now handing out contexts again.

However, now I am running into problems because messages to the other WS-TX services (and also to my test services) are being misdirected. I think this is probably because there is no longer any Action specified in the WSDL -- CXF appears to be directing the messages to servers based on the message content type. I will try adding @Action annotations to all the other service endpoint implementation methods to see if this resolves the problem.

[adinn]

Ok, I updated all my enpoint beans to include @Action annotations but  I am still seeing some really weird stuff happening when messages are being delivered to endpoints. Here is an example:

15:38:04,038 INFO  [STDOUT] KEV: processing SOAP action http://fabrikam123.com/InitiatorPortType/Response
15:38:04,067 ERROR [org.jboss.wsf.common.invocation.InvocationHandlerJAXWS] Method invocation failed with exception: com.jboss.transaction.txinterop.webservices.atinterop.sei.ParticipantPortTypeImpl.response(): java.lang.NoSuchMethodException: com.jboss.transaction.txinterop.webservices.atinterop.sei.ParticipantPortTypeImpl.response()
    at java.lang.Class.getMethod(Class.java:1605) [:1.6.0_14]
    at org.jboss.wsf.common.invocation.AbstractInvocationHandler.getImplMethod(AbstractInvocationHandler.java:92) [:1.3.0.GA]
    at org.jboss.wsf.common.invocation.AbstractInvocationHandlerJSE.invoke(AbstractInvocationHandlerJSE.java:122) [:1.3.0.GA]
    at org.jboss.wsf.stack.cxf.AbstractInvoker._invokeInternal(AbstractInvoker.java:154) [:3.3.0.GA]
    at org.jboss.wsf.stack.cxf.AbstractInvoker.invoke(AbstractInvoker.java:104) [:3.3.0.GA]
    at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58) [:2.2.8]
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0_14]
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [:1.6.0_14]
    at java.util.concurrent.FutureTask.run(FutureTask.java:138) [:1.6.0_14]
    at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) [:2.2.8]
    at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:106) [:2.2.8]
    at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243) [:2.2.8]
    at org.apache.cxf.phase.PhaseInterceptorChain.resume(PhaseInterceptorChain.java:218) [:2.2.8]
    at org.apache.cxf.ws.addressing.ContextUtils$1.run(ContextUtils.java:420) [:2.2.8]
    at org.apache.cxf.workqueue.AutomaticWorkQueueImpl$2.run(AutomaticWorkQueueImpl.java:253) [:2.2.8]
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_14]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_14]
    at java.lang.Thread.run(Thread.java:619) [:1.6.0_14]

Now this is rather weird because the message with action http://fabrikam123.com/InitiatorPortType/Response is never sent to the Participant service implemented by class ParticipantPortTypeImpl. Not surprisingly given the action definition it is sent to service Initiator implemented by class InitiatorPortTypeImpl. So, mmy code is sending messages to one service and they are being delivered to another service. Of course when running on trunk with native a few weeks back this worked fine. Also when I last tested it on a CXF build some months back it worked fine.

I will try to debug the code path through to AbstractInvocationHandler.getImplMethod() in order to see why it is looking at the wrong class and get back with any info I can find.

[adinn]

Andrew Dinn wrote:

. . .

Now this is rather weird because the message with action http://fabrikam123.com/InitiatorPortType/Response is never sent to the Participant service implemented by class ParticipantPortTypeImpl. Not surprisingly given the action definition it is sent to service Initiator implemented by class InitiatorPortTypeImpl. So, mmy code is sending messages to one service and they are being delivered to another service. Of course when running on trunk with native a few weeks back this worked fine. Also when I last tested it on a CXF build some months back it worked fine.

I will try to debug the code path through to AbstractInvocationHandler.getImplMethod() in order to see why it is looking at the wrong class and get back with any info I can find.

I debugged a case where the message has been misdirected and it appears that the delivery process goes awry in class org.jboss.wsf.stack.cxf.AbstractInvoker inside method _invokeInternal(Exchange exchange, Object o, WrappedMessageContext ctx). The problem appears to relate to the use of an InheritableThreadLocal. Here is the code:

private Object _invokeInternal(Exchange exchange, Object o, WrappedMessageContext ctx)
   {
      BindingOperationInfo bop = exchange.get(BindingOperationInfo.class);
      MethodDispatcher md = (MethodDispatcher)exchange.get(Service.class).get(MethodDispatcher.class.getName());
      Method m = md.getMethod(bop);

      Object[] params = NO_ARGS;
      List<Object> paramList = null;
      if (m.getParameterTypes().length != 0)
      {
         if (o instanceof List<?>)
         {
            paramList = CastUtils.cast((List<?>)o);
            params = paramList.toArray();
         }
         else
         {
            params = new Object[]{o};
         }
      }

      Endpoint ep = EndpointAssociation.getEndpoint();
      InvocationHandler invHandler = ep.getInvocationHandler();

      Invocation inv = invHandler.createInvocation();
      InvocationContext invContext = inv.getInvocationContext();
      inv.getInvocationContext().addAttachment(WebServiceContext.class, getWebServiceContext(ctx));
      invContext.addAttachment(MessageContext.class, ctx);
      inv.setJavaMethod(m);
      inv.setArgs(params);

      Object retObj = null;
      try
      {
         invHandler.invoke(ep, inv);

         . . .

The debugger shows the following:

ctx { javax.xml.ws.wsdl.service --> {http://fabrikam123.com}InitiatorService,

      javax.xml.ws.wsdl.port --> {http://fabrikam123.com}InitiatorPortType,

      org.apache.cxf.request.uri --> /interop11/ATInitiatorService

      . . . }

m = "public void com.jboss.transaction.txinterop.webservices.atinterop.sei.InitiatorPortTypeImpl.response()"

ep = org.jboss.wsf.framework.deployment.DefaultEndpoint@18138d9 {

  name = jboss.ws:context=interop11,endpoint=Interop11ATParticipantService

  shortName = Interop11ATParticipantService

  urlPattern = /ATParticipantService

  targetBean = com.jboss.transaction.txinterop.webservices.atinterop.sei.ParticipantPortTypeImpl

   . . . }

So, the problem appears to be that the call to EndpointAssociation.getEndpoint() is returning the wrong endpoint. Now this is strange because it is a very simple function:

  private static final ThreadLocal<Endpoint> endpoint = new InheritableThreadLocal<Endpoint>();

   public static Endpoint getEndpoint()
   {
      return endpoint.get();
   }

Now this is a one way message which, as can be seen in the exception trace, is being dispatched by a worker pool thread. The handoff to this thread happens in the interceptor chain when one of the interceptors determines that this is a one way message. The interceptor queues the partially sent message and returns early so as not to block the JaxWS client. This can be seen in ContextUtils$1.run in the stack trace which is defined inside method ContextUtils.rebaseResponse.

                    if (retrieveAsyncPostResponseDispatch(inMessage)) {
                        //need to suck in all the data from the input stream as
                        //the transport might discard any data on the stream when this
                        //thread unwinds or when the empty response is sent back
                        DelegatingInputStream in = inMessage.get(DelegatingInputStream.class);
                        if (in != null) {
                            in.cacheInput();
                        }
                       
                        // async service invocation required *after* a response
                        // has been sent (i.e. to a oneway, or a partial response
                        // to a decoupled twoway)
                       
                        // pause dispatch on current thread ...
                        inMessage.getInterceptorChain().pause();

                        // ... and resume on executor thread
                        getExecutor(inMessage).execute(new Runnable() {
                            public void run() {
                                inMessage.getInterceptorChain().resume();
                            }
                        });

As you can see the message is queued to an executor obtained from the message. When I execute getExecutor(inMessage) in the debugger it does indeed return an executor. What is more when I execute the code in getExecutor it does indeed appear to be obtained from the Initiator service not the Participant service. However, when I looked at the threads in the Executor thread pool something is very wrong. The inheritedThreadLocalMap field in some of the threads has the Initiator port as the endpoint while in other threads it has the Participant port as the endpoint. So, something is resetting the thread local endpoint of Initiator service executor  threads.

I don't know exactly why or where this is happening but I will try tracing calls to getEndpoint and setEndpoint in order to see if I can idenitfy what is doing the reset.