cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Sosnoski <>
Subject Re: a quesiton on CXF 2.5 WS-RM's protocol variation handling
Date Fri, 09 Sep 2011 09:22:07 GMT
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<>:
>> Hi Aki,
>> I added the test code to verify proper server-side handling of different
>> protocol variations ( 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<>:
>>>>> 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

View raw message