4 Replies Latest reply on Aug 1, 2007 12:24 PM by Tom Barry

    Conversation ID in web service response

    Tom Barry Newbie

      I'm getting started with conversations in a JBoss Seam web service. I've got a basic web service with a method called 'start' that doesn't do anything (yet):

      @Stateless
      @Name("supportCenterService")
      @WebService(name = "SupportCenter", targetNamespace = "http://blah.service", serviceName = "SupportCenterService")
      public class SupportCenter implements SupportCenterRemote {
      
       @In(create=true)
       AgentConfigurationSource agentConfiguration;
      
       @Logger
       Log log;
      
       @WebMethod
       public void start() {
       }
      }
      


      I'm calling this web service from an Axis client generated from WSDL2Java:

      public static void start() {
       try {
       SupportCenter supportCenter = SupportCenterClientFactory.getClient();
       supportCenter.start();
       SOAPHeaderElement[] headers = ((Stub) supportCenter).getResponseHeaders();
       System.out.println("Headers: " + headers.length);
       } catch (Exception e) {
       throw new WebServiceClientException(e);
       }
       }


      The getClient method in SupportCenterClientFactory calls setMaintainSession:

      public static SupportCenter getClient() {
       try {
       URL endpointAddress = new URL(AgentGlobals.getInstance().getConfig().getWebService().getPrimaryAddress());
       SupportCenterServiceLocator serviceLocator = new SupportCenterServiceLocator();
       serviceLocator.setMaintainSession(true);
       return serviceLocator.getSupportCenterPort(endpointAddress);
       } catch (ServiceException e) {
       throw new WebServiceClientException(e);
       } catch (MalformedURLException e) {
       throw new WebServiceClientException(e);
       }
       }


      I have the following in META-INF/standard-jaxws-endpoint-config.xml:

      <jaxws-config xmlns="urn:jboss:jaxws-config:2.0"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:javaee="http://java.sun.com/xml/ns/javaee"
       xsi:schemaLocation="urn:jboss:jaxws-config:2.0 jaxws-config_2_0.xsd">
       <endpoint-config>
       <config-name>Seam WebService Endpoint</config-name>
       <pre-handler-chains>
       <javaee:handler-chain>
       <javaee:protocol-bindings>##SOAP11_HTTP</javaee:protocol-bindings>
       <javaee:handler>
       <javaee:handler-name>SOAP Request Handler</javaee:handler-name>
       <javaee:handler-class>org.jboss.seam.webservice.SOAPRequestHandler</javaee:handler-class>
       </javaee:handler>
       </javaee:handler-chain>
       </pre-handler-chains>
       </endpoint-config>
      </jaxws-config>


      So, going back to the client call, should I expect to see a conversation id in the response header? Right now, there are no headers defined in the response:

      public static void start() {
       try {
       SupportCenter supportCenter = SupportCenterClientFactory.getClient();
       supportCenter.start();
       SOAPHeaderElement[] headers = ((Stub) supportCenter).getResponseHeaders();
       System.out.println("Headers: " + headers.length); // Result is 0
       } catch (Exception e) {
       throw new WebServiceClientException(e);
       }
       }


      Am I misunderstanding something here, or am I missing something?

        • 1. Re: Conversation ID in web service response
          Shane Bryzak Master

          Can you confirm whether the conversation ID actually exists in the SOAP response? (in the actual XML)

          • 2. Re: Conversation ID in web service response
            Tom Barry Newbie

            I used SoapUI to issue the following request:

            <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:com="http://com.twocoast.tcsc.web.service">
             <soapenv:Header/>
             <soapenv:Body>
             <com:isConfigurationChangePending>
             <serverName>QUATTRO</serverName>
             </com:isConfigurationChangePending>
             </soapenv:Body>
            </soapenv:Envelope>


            and got the following response (no conversation Id):

            <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
             <env:Header/>
             <env:Body>
             <ns2:isConfigurationChangePendingResponse xmlns:ns2="http://com.twocoast.tcsc.web.service">
             <return>true</return>
             </ns2:isConfigurationChangePendingResponse>
             </env:Body>
            </env:Envelope>


            If I annotate the isConfigurationChangePending with @Begin in the seam component (which is called by the SLSB annotated with @WebService) I get the following response:

            <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
             <env:Header/>
             <env:Body>
             <env:Fault>
             <faultcode>env:Server</faultcode>
             <faultstring>java.lang.IllegalStateException: Do not start long-running conversations in direct calls to EJBs</faultstring>
             </env:Fault>
             </env:Body>
            </env:Envelope>


            I'm also seeing the following error show up in the log whenever a web request is processed (regardless of whether the method is annotated):

            22:15:29,460 WARN [arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator_4] TwoPhaseCoordinator.afterCompletion - returned failure for com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple@949f87


            FYI- I'm using seam libraries built from CVS today.

            • 3. Re: Conversation ID in web service response
              Shane Bryzak Master

              It looks like the interceptor isn't being hit, and I'm guessing it's a packaging issue. Is your standard-jaxws-endpoint-config.xml inside the JAR file containing your web services inside an EAR? Look at the packaging for the seambay example to see how it should be.

              • 4. Re: Conversation ID in web service response
                Tom Barry Newbie

                You were absolutely right, it was a packaging issue- and a stupid error on my part. Thank you...