You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Daniel Kulp <dk...@apache.org> on 2008/03/03 22:49:48 UTC

Re: passing a flag from impl method to interceptor



On Friday 29 February 2008, Daniel Lipofsky wrote:
> Those all sound good, but unfortunately I am pretty much
> a web-services newbie, I don't have a clue how to
> implement that, especially the @WebParam sugestion.
> Do I need some entries in the WSDL, etc?

If you want to define it in the wsdl, you would create a new schema 
element like:
<element name="overflow" type="boolean"/>

Then to your out message, just add another part like:

<part name="overflow" element="ns:overflow"/>

And then in your soap binding for the output:
                <soap:body parts="return" use="literal"/>
                <soap:header message="tns:inoutHeaderResponse"
                       part="overflow" use="literal"/>

You can see the wsdl in our samples/soap_header dir as an example.

Dan



>
> the old implementation was basically outputing this:
>
> <soap:Envelope ...
> xmlns:h="http://www.foobar.com/connector-1.5/headers_ns.xsd">
>     <soap:Header>
>         <h:overflow soap:mustUnderstand="0">false</h:overflow>
>     </soap:Header>
>     ...
>
> or
>     ...
>     <h:overflow soap:mustUnderstand="0">true</h:overflow>
>     ...
>
> so there are a few involved: a namespace, a node, and
> an attribute.  I don't have to keep it the same, so maybe
> I can make it a lot simplier, I just need to basically
> communicate overflow=[true|false] somehow.
>
> Thanks,
> Dan
>
> On Friday 29 February 2008, Daniel Kulp wrote:
> > Of course, I typed all that and forgot the most obvious way:
> >
> > Just add a parameter to your method like:
> >
> > @WebParam(header = true, mode = Mode.OUT)
> > Holder<String> header
> >
> > Dan
> >
> > On Friday 29 February 2008, Daniel Kulp wrote:
> > > OK.   This is turning into another FAQ type thing that
> >
> > possibly needs
> >
> > > a sample....
> > >
> > > There are a couple options open to you:
> > >
> > > First, you need the context injected in:
> > > @Resource
> > > WebServiceContext context;
> > >
> > > 1) Standard JAX-WS API's:  throw the value in the
> > > WebServiceContext and in a SoapHandler, use it to modify the SAAJ
> > > object model.   This is pure JAXWS and would work on any JAX-WS
> > > implementation.  The "problem" is that with the SAAJ model, it
> > > breaks streaming and performance suffers.
> > >
> > > 2) context + CXF interceptor: again, from your impl, throw
> >
> > a value in
> >
> > > the WebServiceContext and then grab that from the message in your
> > > interceptor.   You can then call the
> >
> > soapMessage.getHeaders() thing to
> >
> > > get the list of headers and add a Header object to it.
> > >
> > > 3) Context only: no interceptors needed.  In you impl do:
> > >
> > > context.
> > > ... build a org.apache.cxf.headers.Header object ...
> > > List<Header> hdrList = (List<Header>)ctx.get(Header.HEADER_LIST));
> > > hdrList.add(hdr);
> > >
> > > And example of this would be our system test that test this:
> >
> > http://svn.apache.org/repos/asf/incubator/cxf/trunk/systests/src/tes
> >t/
> >
> > >java/org/apache/cxf/systest/outofband/header/
> > >
> > >
> > > 3 is definitely the simplest.   No interceptors needed.  Nothing
> > > really to configure, etc....
> > >
> > >
> > > Dan
> > >
> > > On Friday 29 February 2008, Daniel Lipofsky wrote:
> > > > I have a csae where I want to set something in the SOAP
> > > > response header based on what happened in the execution of
> > > > the method implementation.
> > > >
> > > > I suppose I want to extend AbstractSoapInterceptor, but what
> > > > I can't figure out is how to pass a flag from the method
> > > > to the interceptor.  I thought about sticking it in the
> > > > ServletRequest attribute map but I don't see a way to access
> > > > that from the interceptor.  Any way to do it would be fine.
> > > >
> > > > also is there an example of adding an element to a SOAP header?
> > > >
> > > > Thanks,
> > > > Dan



-- 
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog