You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Nerijus Areska <ne...@gmail.com> on 2009/04/16 15:13:04 UTC
CXF 2.2 (or 2.1) fault on response results in empty response on
Websphere 6.1
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);
}
}
--
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-tp23077696p23077696.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: how to get method name from SoapMessage
Posted by Daniel Kulp <dk...@apache.org>.
On Thu April 23 2009 4:20:31 pm Tedman Leung wrote:
> Does anyone know the easiest way to find out what web service and method
> is being called given the SoapMessage on the server side?
>
> I'm trying to determine that in an InInterceptor in the handleMessage()
> method right now.
Depends on where in the chain you are. In the early parts of the chain,
it's not really possible as the body hasn't been processed yet. It may not
even have been pulled off the wire. Or it could be encrypted. Etc.....
In the latter parts of the chain, you can call
message.getExchange().get(BindingOperationInfo.class) and from that gather
whatever information you want.
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
how to get method name from SoapMessage
Posted by Tedman Leung <te...@sfu.ca>.
Does anyone know the easiest way to find out what web service and method
is being called given the SoapMessage on the server side?
I'm trying to determine that in an InInterceptor in the handleMessage()
method right now.
--
Ted Leung
tedman@sfu.ca
Re: CXF 2.2 (or 2.1) fault on response results in empty response on
Websphere 6.1
Posted by Carlo Camerino <cm...@gmail.com>.
Hi,
I would just like to inquire on what steps you did to make cxf run on
websphere properly?
I am able to run it by following some parts of the wiki but i'm not sure if
the ws-security features are still enabled...
What way did you do it?
Thanks
2009/4/18 Daniel Kulp <dk...@apache.org>
>
> 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
> dkulp@apache.org
> http://www.dankulp.com/blog
>
Re: CXF 2.2 (or 2.1) fault on response results in empty response on
Websphere 6.1
Posted by Nerijus Areska <ne...@gmail.com>.
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
> dkulp@apache.org
> 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.
Re: CXF 2.2 (or 2.1) fault on response results in empty response on Websphere 6.1
Posted by Daniel Kulp <dk...@apache.org>.
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
dkulp@apache.org
http://www.dankulp.com/blog