I checked 2.2.1-SNAPSHOT, the problem is still there.
According to my debugger, setStatus call still happens in:
ServletDestination(AbstractHTTPDestination).flushHeaders(Message) line: 458
AbstractHTTPDestination$WrappedOutputStream.close() line: 548
CacheAndWriteOutputStream.postClose() line: 47
CacheAndWriteOutputStream(CachedOutputStream).close() line: 180
AbstractHTTPDestination$BackChannelConduit(AbstractConduit).close(Message)
line: 66
MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(Message)
line: 62
i did not do much analysis on this, but diff between 2.2 and 2.2.1-SNAPSHOT
AbstractHTTPDestination.java does not show much..:
84a85,86
> public static final String RESPONSE_COMMITED = "http.response.done";
>
240,241c242,247
< for (Object value : headerList) {
< response.addHeader(header, (String)value);
---
> StringBuilder sb = new StringBuilder();
> for (int i = 0; i < headerList.size(); i++) {
> sb.append(headerList.get(i));
> if (i + 1 < headerList.size()) {
> sb.append(',');
> }
242a249
> response.addHeader(header, sb.toString());
dkulp wrote:
>
>
> Any chance you could try the latest 2.2.1-SNAPSHOTS? I think I fixed
> this
> as part of the testing Benson and I did with the Sun Stax parser. The
> Sun
> stream write doesn't cache anything so the fault codes ended up being 200
> instead of 500 due to the response already being written. Thus the
> setStatus
> call got properly moved up to the beginning so I THINK this is now fixed.
>
> Dan
>
> On Thu April 16 2009 9:13:04 am Nerijus Areska wrote:
>> I believe this should happen on Websphere or any other Servlet spec 2.3+
>> compliant web server.
>>
>> I get an empty response from CXF, when trying to return non-valid
>> response
>> ( blank mandatory field or similar, CXF has validating mode switched on
>> ).
>> I debugged my application for a while and found out, that CXF gets a
>> fault
>> in BareOutInterceptor in marshal phase, then unwinds all other
>> interceptors, creates a new chain and invokes that. The message still
>> remains the same and keeps some cached resources/data inside ( like
>> XMLStreamWriter ).
>> In the next chain, producing fault output,
>> MessageSenderEndingInterceptor,
>> when handling the message, invokes response.setStatus(500), before
>> flushing
>> the outputStream. In normal case( e.g. user exception ), it would not do
>> that( Actually we end up with two wrapper streams in this chain, which
>> later causes some method calls resulting in setStatus(500) ). Now servlet
>> specification says, that setStatus(int) should clear the buffers, which
>> of
>> course looses my response.
>> Tomcat, Glassfish, and probably several others skip this requirement and
>> do
>> not clear the buffers, which then works ok. Websphere follows
>> specification
>> strictly at this point, and thus looses the data.
>>
>> I wrote a simple interceptor, fixing this problem for me, though i am not
>> sure about any side effects. I invoke it in Fault chain
>>
>> public class ClearOutputStreamInterceptor extends
>> AbstractSoapInterceptor
>> {
>>
>> public ClearOutputStreamInterceptor(Bus b) {
>> super(Phase.PREPARE_SEND);
>> getBefore().add(MessageSenderInterceptor.class.getName());
>> }
>>
>> public void handleMessage(SoapMessage message) {
>> message.setContent(XMLStreamWriter.class, null);
>> message.put("wrote.envelope.start", null);
>> }
>>
>> }
>
> --
> Daniel Kulp
> [email protected]
> http://www.dankulp.com/blog
>
>
--
View this message in context:
http://www.nabble.com/CXF-2.2-%28or-2.1%29-fault-on-response-results-in-empty-response-on-Websphere-6.1-tp23077696p23154510.html
Sent from the cxf-user mailing list archive at Nabble.com.
