On Thursday 24 February 2011 11:05:47 AM Rhenius, Karl Stefan wrote: > Hi Sergey, > > according to your answer this seems to be a bug? (That would be great, > because I could stop trying to find the right configuration :) > > > Dan has enhanced the Neethi implementation to properly > > support the policy intersection but that is more likely to > > affect the client side. But in this case, how does the server > > knows the 2nd request is coming from the original client > > which is supporting a SecureConversation policy ? > > I attached the incoming message from my client and the servers response. > There are many header information, that could be used to track the > session, i.e. > <wsc:Identifier>BC4D3B6C7539DA347C12985615449223</wsc:Identifier> for > the SecureConversation. > > I didn't checked, how the policy is chosen, so this is just speculative: > I would add the chosen policy somewhere in the exchange or message > object, so the outgoing handler can take an appropriate format. There is > no need to track a session, the first valid policy on the incoming side > should be used for the outgoing message. > > I'm going to make a testcase for jira.
Yea. Please do. This definitely sounds like a bug, but a complicated enough one that a good test case is probably required. -- Daniel Kulp [email protected] http://dankulp.com/blog Talend - http://www.talend.com
