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<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
