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 <d...@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<d...@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 >> >
