Return-Path: Delivered-To: apmail-incubator-cxf-dev-archive@locus.apache.org Received: (qmail 47799 invoked from network); 6 Sep 2007 15:56:51 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 6 Sep 2007 15:56:51 -0000 Received: (qmail 11494 invoked by uid 500); 6 Sep 2007 15:56:46 -0000 Delivered-To: apmail-incubator-cxf-dev-archive@incubator.apache.org Received: (qmail 11298 invoked by uid 500); 6 Sep 2007 15:56:45 -0000 Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cxf-dev@incubator.apache.org Delivered-To: mailing list cxf-dev@incubator.apache.org Received: (qmail 11289 invoked by uid 99); 6 Sep 2007 15:56:45 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Sep 2007 08:56:45 -0700 X-ASF-Spam-Status: No, hits=1.5 required=10.0 tests=SPF_PASS,WEIRD_PORT X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [207.97.245.161] (HELO smtp161.iad.emailsrvr.com) (207.97.245.161) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Sep 2007 15:56:39 +0000 Received: by relay6.relay.iad.emailsrvr.com (Authenticated sender: dan.diephouse-AT-mulesource.com) with ESMTP id AF5F46A9077 for ; Thu, 6 Sep 2007 11:56:18 -0400 (EDT) Message-ID: <46E0231A.5080304@mulesource.com> Date: Thu, 06 Sep 2007 11:56:10 -0400 From: Dan Diephouse User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: cxf-dev@incubator.apache.org Subject: WS-Addressing Issues Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org I'm having some issues getting WS-A to work for me. First, it seems that adding the WSAddressingFeature isn't enough to get WS-A to be turned on. You have to set the "usingAddressingAdvisory" property which is cryptic at best. Why isn't adding the interceptors to the client enough for it to start sending WS-A headers? Why would we want it turned off by default? Second, I'm running the WS-A sample and it appears to be sending two soap messages to the client - one partial response and one decoupled message. From the logs: INFO: Outbound Message -------------------------------------- urn:uuid:9bd2e4c4-cca0-478d-bc81-a57e92b9c1c4http://localhost:9000/SoapContext/SoapPort

http://localhost:9990/decoupled_endpoint

-------------------------------------- ... INFO: Inbound Message -------------------------------------- Headers: {null=[HTTP/1.1 202 Accepted], connection=[close], SOAPAction=[""], Server=[Jetty(6.1.5)], content-type=[text/xml; charset=utf-8]} Message: urn:uuid:d15fa093-3951-47f5-86ac-bd616f8d57d7http://www.w3.org/2005/08/addressing/anonymous

http://www.w3.org/2005/08/addressing/none

-------------------------------------- ... INFO: Inbound Message -------------------------------------- Encoding: UTF-8 Headers: {Host=[localhost:9990], User-Agent=[Java/1.5.0_10], connection=[keep-alive], SOAPAction=[""], transfer-encoding=[chunked], Pragma=[no-cache], content-type=[text/xml; charset=UTF-8], Cache-Control=[no-cache], Accept=[*]} Message: urn:uuid:9e2a0281-dcea-42b5-b5a9-a89e265d40dehttp://localhost:9990/decoupled_endpointurn:uuid:9bd2e4c4-cca0-478d-bc81-a57e92b9c1c4Bonjour -------------------------------------- Is this correct? I thought the first http response should be empty and we should only be sending the second message. Last, I'm trying to write a different HTTP conduit and destination. I.e. one that uses Mule. I think this issue applies to our JBI transport as well. In both the JBI & Mule cases (or any other ESB), you want to send messages to the bus instead of to our transport layer. The bus can then send out the messages via it's transport layer. The issue is this - our decoupled endpoint stuff is baked into the transport, which it needs to be rebaked into the Mule/JBI transports as well. Its not exactly trivial to do either, I'm still struggling to figure it out. But to expand my previous points on why decoupling in the transport is a BAD thing here are some other reasons: - Setting up a decoupled endpoint for CXF will be completely different depending on whether or not your in an ESB environment or not. In one case I have to use to set the DecoupledEndpoint, in another , in another (which doesn't support decoupled interactions right now), etc. It'd be much much better to have this configuration associated with the client. - Now any ESB transport needs to take care of setting the appropriate HTTP statuses on the messages. - I have to copy the InteroposedMessageObserver & decoupled Destination logic to my conduit - I'm probably going to end up with a bunch of if(http) logic in my transport to handle back channel stuff. Am I missing something here? This seems way harder than it should be... Have any of the servicemix people looked at this yet? Regards, - Dan -- Dan Diephouse MuleSource http://mulesource.com | http://netzooid.com/blog