Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4E69DABF.8060100@sosnoski.com>
Date: Fri, 09 Sep 2011 21:22:07 +1200
From: Dennis Sosnoski <dms@sosnoski.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.9.2.20) Gecko/20110804 SUSE/3.1.12 Lightning/1.0b2 Thunderbird/3.1.12
MIME-Version: 1.0
To: dev@cxf.apache.org
Subject: Re: a quesiton on CXF 2.5 WS-RM's protocol variation handling
References: 
 <CAF8t5Xt9ZRQnO43qugsOGO42f=ikBJ0Kg=5C-gM78c6FUqT4fg@mail.gmail.com>
	<4E4C37E2.7070704@sosnoski.com>
	<CAF8t5Xs3YQQpnPNQM5p5dh2XdEH31xZNZqkbEXnSg6HwZ2XVgw@mail.gmail.com>
	<4E55DDF3.3080309@sosnoski.com>	<4E699541.10509@sosnoski.com>
 <CAF8t5XvNRnPfHaQALpLuxJWP0k3Hy9SDU3jhhnK5m2upX7ZKgg@mail.gmail.com>
In-Reply-To: 
 <CAF8t5XvNRnPfHaQALpLuxJWP0k3Hy9SDU3jhhnK5m2upX7ZKgg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Sounds good to me on both of these.

   - Dennis


On 09/09/2011 08:29 PM, Aki Yoshida wrote:
> Hi Dennis,
> okay. Thanks. I will check it out.
>
> I am also thinking about introducing a few request runtime properties
> to control some of the RM behavior.
>
> - Marking the message as the last message
> - Setting the replyTo of the createSequence to the anonymous endpoint
> for a decoupled case (Currently, both replyTo and ackTo are
> automatically set to the decoupled endpoint. Consequently, the
> CreateSequenceResponse is sent to the decouple endpoint. This is fine,
> but I think we should offer an option to get this synchronous
> CreateSequenceResponse on the http response directly).
> - Generalizing this replyTo/ackTo runtime setting to set ackTo to the
> anonymous endpoint and replyTo to the decoupled endpoint.
>
> There are very old jira tickets about these aspects (CXF-348, CXF-374).
>
> regards, aki
>
>
> 2011/9/9 Dennis Sosnoski<dms@sosnoski.com>:
>> Hi Aki,
>>
>> I added the test code to verify proper server-side handling of different
>> protocol variations (http://svn.apache.org/viewvc?rev=1166927&view=rev) so
>> if you want to try changing how RMEndpoint works, go ahead.
>>
>>   - Dennis
>>
>>
>> On 08/25/2011 05:30 PM, Dennis Sosnoski wrote:
>>> On 08/18/2011 11:32 PM, Aki Yoshida wrote:
>>>> Hi Dennis,
>>>>
>>>> 2011/8/17 Dennis Sosnoski<dms@sosnoski.com>:
>>>>> Hi Aki,
>>>>>
>>>>> On 08/18/2011 09:25 AM, Aki Yoshida wrote:
>>>>>> ...
>>>>>>
>>>>>> RMManager now manages endpoints under each supported protocol
>>>>>> variation using Map<ProtocolVariation, Map<Endpoint, RMEndpoint>>.
>>>>>> Does this mean that an Endpoint can be used in several protocol
>>>>>> variations?
>>>>> Yes. I decided to take this approach because I wanted the WS-RM
>>>>> serverside code to automatically adjust to whichever variation a client
>>>>> uses in the request, while allowing other clients to use other
>>>>> variations.
>>>> Okay. it makes sense. But could this multi-version support at the
>>>> sequence level so that you still have one RMEndpoint per Endpoint? One
>>>> RMEndpoint can respond to the create sequence message from various
>>>> clients using different versions and create each sequence bound to be
>>>> used for a specific version. So this will also work, no?
>>> I had originally looked at doing something along these lines. I think I
>>> ran into problems in handling outgoing messages, but from a look at
>>> RMOutInterceptor I'd think it'd be possible to work around any issues.
>>>
>>> I'll add some systests to assure that the code responds correctly to
>>> different protocol variations (which it does, at present). That way you
>>> can try this change and make sure nothing breaks.
>>>
>>>    - Dennis
>>>