Accessing headers in server's response

[st...@smals.be]

Hello


I wanted to read the header in the response from a ws server. As I use the 
client stub
generated by Axis2, it turned out to be a rather clever thing to do.
My header are explicit and are typed in the XSD, therefore Axis2 wsdl2java 
generates a class to
represent them (and, unfortunately, never populate it from within the 
stub). The class
is SyncResponseHeader. And this is how I get it from a class which 
inherits from the generated
Stub (so "this" is the Stub).


SOAPEnvelope env = 
this._serviceClient.getLastOperationContext().getMessageContext("In").getEnvelope();
SOAPHeader h =  env.getHeader();
SyncResponseHeader resp = 
SyncResponseHeader.Factory.parse(h.getFirstElement().getXMLStreamReaderWithoutCaching());

(maybe I should use "handlers" ? but I don't know how to do that)

I'd like to mention something now. It looks like I'm not the one who 
encountered this issue.
There was an answer in this mail:

http://marc.info/?l=axis-user&m=116502112920378&w=2

Even though the answer was useful I think it misses the point. Newbie 
users like me are
expecting wsdl2java to produce a stub that is usable << as is >>. So 
although Axis behaves
as expected (which by no means that what I expect is what it should do 
:)), if the stub doesn't, then it's of no use. It's even worse if we have 
to
modify the stub ourselves because each time the WSDL changes, we have to 
remodify the stub.
I know the stub is probably not designed for << production use >> but 
that's how I use it.

So, next time there's an answer about the stub, I think it would be better 
to provide an answer
which does not imply modifying the stub (again, most of the time I inherit 
form it which
allows some flexibility).

stF

Re: Accessing headers in server's response

[Amila Suriarachchi <am...@gmail.com>]

On Wed, Jun 18, 2008 at 2:44 PM, <st...@smals.be> wrote:

>
> Hello
>
>
> I wanted to read the header in the response from a ws server. As I use the
> client stub
> generated by Axis2, it turned out to be a rather clever thing to do.
> My header are explicit and are typed in the XSD, therefore Axis2 wsdl2java
> generates a class to
> represent them (and, unfortunately, never populate it from within the
> stub). The class
> is SyncResponseHeader. And this is how I get it from a class which inherits
> from the generated
> Stub (so "this" is the Stub).
>
>
> SOAPEnvelope env =
> this._serviceClient.getLastOperationContext().getMessageContext("In").getEnvelope();
> SOAPHeader h =  env.getHeader();
> SyncResponseHeader resp =
> SyncResponseHeader.Factory.parse(h.getFirstElement().getXMLStreamReaderWithoutCaching());
>
> (maybe I should use "handlers" ? but I don't know how to do that)


The operation method returns the response object corresponds to soap body
Element. If you want to get the header out side the stub you can use
stub._getServiceClient() method. then you don't have to change the stub.

>
>
> I'd like to mention something now. It looks like I'm not the one who
> encountered this issue.
> There was an answer in this mail:
>
> http://marc.info/?l=axis-user&m=116502112920378&w=2
>
> Even though the answer was useful I think it misses the point. Newbie users
> like me are
> expecting wsdl2java to produce a stub that is usable << as is >>. So
> although Axis behaves
> as expected (which by no means that what I expect is what it should do :)),
> if the stub doesn't, then it's of no use. It's even worse if we have to
> modify the stub ourselves because each time the WSDL changes, we have to
> remodify the stub.
> I know the stub is probably not designed for << production use >> but
> that's how I use it.

No it is design to use in production use. Try to write that code in your
client using _getServiceClient() method without modifying the stub.

thanks,
Amila.

>
>
> So, next time there's an answer about the stub, I think it would be better
> to provide an answer
> which does not imply modifying the stub (again, most of the time I inherit
> form it which
> allows some flexibility).
>
> stF




-- 
Amila Suriarachchi,
WSO2 Inc.