For the problem that we thought there is, an empty partial response
being returned as an soap envelope with http 202 was a ghost.
On the network, the soap content is definitely not sent. I see each
request is returned with the expected 202 response, as
HTTP/1.1 202 Accepted
Content-Type: text/xml;charset=UTF-8
Content-Length: 0
Server: Jetty(8.1.15.v20140411)
The bogus content shows up only in the server side logging, as
ID: 1
Response-Code: 202
Encoding: UTF-8
Content-Type: text/xml
Headers: {}
Payload: <soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";><soap:Header><MessageID
xmlns="http://schemas.xmlsoap.org/ws/2004/08/addressing";>urn:uuid:d050fe7f-ed97-4d25-9fdf-84b4776fffa8</MessageID><To
xmlns="http://schemas.xmlsoap.org/ws/2004/08/addressing";>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</To><RelatesTo
xmlns="http://schemas.xmlsoap.org/ws/2004/08/addressing";>http://www.w3.org/2005/08/addressing/unspecified</RelatesTo></soap:Header><soap:Body/></soap:Envelope>
So this is apparently not a decoupled endpoint issue but just a
logging issue. So we can fix it in 3.0.1.
regards, aki
--------------------------------------
2014-05-13 23:44 GMT+02:00 Aki Yoshida <[email protected]>:
> Hi Dennis, Dan,
> I think the oneway decoupled WS-RM scenario seems to be working fine
> when I look at the client side log transcription.
> http://pastebin.com/wRReBcqz
>
> One error, I believe, that I saw while I was trying out a few other
> things was the CloseSequence generation. I wrote to the dev list about
> this a few hours ago.
>
> Another error which Dennis mentioned to me and I can confirm is the
> partial empty response is not correctly recognized as an partial empty
> message at the server side. As a result, an empty soap envelope with
> the default ws-a header is returned with http 202 over the http
> response. I suppose this is resulted from some change somewhere in the
> code that is not setting the correct state of the partial message. But
> it seems this problem came in a while ago. I wanted to look at it
> today but didn't get to it. But I think this won't take time. If I can
> get a few hours tomorrow, I can look into it. But it won't harm much
> even the content is included as long as the http status is set to 202
> to inform the client to ignore the content. In that case, we can
> postpone this to 3.0.1.
>
> regards, aki
>
>
>
> 2014-05-13 17:07 GMT+02:00 Daniel Kulp <[email protected]>:
>>
>> Dennis,
>>
>> Any updates? Just trying to figure out what’s left. :-)
>>
>> Dan
>>
>>
>>
>> On May 12, 2014, at 2:58 PM, Dennis Sosnoski <[email protected]> wrote:
>>
>>> Hi Dan,
>>>
>>> RM is broken for oneway operations with a decoupled endpoint at present.
>>> I'm trying to track the problem down, and Aki has also taken a look. If I
>>> can't fix it myself I'll add a test case so you can take a look.
>>>
>>> I don't know that this would qualify as a show stopper, but it's pretty
>>> significant and should be an easy fix.
>>>
>>> - Dennis
>>>
>>> On 05/13/2014 02:38 AM, Daniel Kulp wrote:
>>>> Now that we finally have email back (and thus can review/track commits,
>>>> issues, call votes, etc…) I plan on doing the 3.0 builds real soon,
>>>> hopefully tomorrow. It looks like everything major is now done. All
>>>> snapshots are resolved, the tests seems to be passing, the RM issues are
>>>> resolved, etc… Thus, I’d like to get this out.
>>>>
>>>> If you have anything that would be considered a show stopper, let me know
>>>> ASAP.
>>>>
>>>> Thanks!
>>>>
>>>
>>
>> --
>> Daniel Kulp
>> [email protected] - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
