Hi Dennis, all, In my local trunk, I modified the RM-endpoints et al so that we have one RMEndpoint per an application endpoint which handles all three protocol variations. This RMEndpoint has the information about the three protocol variations so that we can pass the protocol variation instance to some of its methods to have it behave specifically for that protocol.
To get the protocol variation information later in many places, after the protocol variation is determined, the message\s property is set accordingly. In that way, we can get the protocol variation from the message or from the sequence so that we have the protocol variation whenever we need within various processing methods. This change fixes the problems that I mentioned before and also simplifies the managed entities. With this change, we can revert the RMStore's getSequence method to the old one that had only the endpoint identifier argument and not the protocol variation argument. This protocol variation argument was not used to find the sequences of that particular protocol variation but used to instantiate a sequence that was read from the storage because the sequence's ctor needed the protocol variation. By storing the protocol variation with the sequence, we don't need this argument as we can fully recover the original sequences without it. All the ws-rm tests and systests are running fine. So, I think it is working fine and I would like to submit this change into 2.6.0-SNAPSHOT. I was wondering if this is still okay because of the shortly planned 2.6.0 release. Any thought? Thanks. Regards, aki 2012/3/22 Aki Yoshida <[email protected]>: > Hi Dennis, > > While ago, I mentioned the problem that I was having with the protocol > variations in WS-RM. > > http://cxf.547215.n5.nabble.com/a-quesiton-on-CXF-2-5-WS-RM-s-protocol-variation-handling-td4710027.html > > I would like to come back to this problem, as I am having a few > problems with server side sequence and message recoveries. > > To begin with, I assume we can assign a specific protocol variation to > a particular sequence. In other words, we can assume each sequence has > a fixed protocol version that was used to create that sequence. > > However, this assumption is broken at the RM endpoint recovery. For > the client endpoints, the sequences are assigned to the configured > static protocol variation. If you dynamically changed the protocol > variation, your sequence would be reassigned to the wrong protocol > variation. For the server endpoints, the sequences are replicated for > each protocol variation and simply assigned to their original protocol > variations. And this latter is causing an issue in several areas such > as > - the RM endpoint registration in JMX (because each endpoint gets > registered for three variations) > - each stored message gets recovered per each variation (this only > happens at the server side because the server side code is explicitly > starting each endpoint per protocol variant).. > > To solve these issues, I would like to have one RM endpoint that can > support a different protocol variation per sequence. We must also > store the protocol variation in the RMStore so that the sequence and > message recoveries will find the correct protocol variations at > restart. > > How do you think? > > Thanks. > > Regards, Aki
