Re: CXF 2.2 (or 2.1) fault on response results in empty response on Websphere 6.1

[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: how to get method name from SoapMessage

[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

[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