Thanks Amila, Are there any examples for writing a handler to deal with custom headers?
Thanks \Sarwar "Amila Suriarachchi" <[EMAIL PROTECTED]> 02/08/2007 12:22 AM Please respond to [email protected] To [email protected] cc Subject Re: Axis2: skeleton differences w/Axis 1.4 here is the problem. you have a soap binding input element like this <wsdl:input> <wsdlsoap:body use="literal" /> <wsdlsoap:header message="tns:opControlRequest" part="Security" use="literal" namespace=" http://ws.test.sample.com/WSSecurity/"/> </wsdl:input> and your refering message like this <wsdl:message name="opControlRequest"> <wsdl:part name="Security" element="tns:SecurityType"/> <wsdl:part name="opControlRequest" element="tns:OpControlActionRequest"/> </wsdl:message> In this case since there are two parts for the message you have to sepcify which part to using in wsdl:input as follows <wsdlsoap:body use="literal" part="opControlRequest"/> but having done that may results the same since there is an axis2 problem. So the correct skelton is would be to generate only the body part. Axis2 does not produce any bining specific details (header part is a binding specific)in the Skelton class. In Axis 2 if you want to handle custom headers you have to write a handler for it. On 2/7/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > Hi Davanum... > I didn't think a determination had been made that this was indeed a bug in > Axis 2 which is why I have not gone the JIRA route. Was hoping someone could > just tell me I was doing something wrong with regards to my WSDL (that would > be an easy fix!) . I'll put something in JIRA if thats how you want me to > proceed. > > Thanks > \Sarwar > > > *"Davanum Srinivas" <[EMAIL PROTECTED]>* > > 02/07/2007 10:24 AM > Please respond to > [email protected] > > To > [email protected] cc > > Subject > Re: Axis2: skeleton differences w/Axis 1.4 > > > > > > > Sarwar, > > JIRA bug please :) After you create the bug, you can upload the files as > well. > > thanks, > dims > > On 2/6/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > Addendum to last post: > > Neither the unwrapping nor backwards compatilbity options in the codegen > tool helped - which leads me to believe that something in the WSDL I > attached in the last message may be amiss. Our goal is to pack portions of a > SOAP header and SOAP body using the WSDL definitions - any help appreciated. > > > > \Sarwar > > > > > > > > Sarwar Raza/US/[EMAIL PROTECTED] > > > > 02/06/2007 10:49 PM > > > > > > Please respond to > > [email protected] > > > > > > To [email protected] > > > > cc > > > > > > Subject Re: Axis2: skeleton differences w/Axis 1.4 > > > > > > > > > > > > > > > > > > Hi Anne, > > Thanks for the response. > > > > Here is what we were able to get working with Axis 1.4, and have been > > struggling with Axis 2... > > Our input message contained TWO parts, one destined for the body, and > the > > other destined for the header (we set this up in the binding). > > The header contains security info that gets used by WSSJ - pretty > typical > > usage best we can tell. > > > > When we ran WSDL2Java using Axis 1.4, the resulting stubs resulted in a > > method signature for each of the methods that looked something like: > > > > message (header, body). > > > > Using Axis2, the WSDL does get parsed correctly (even though we have > > defined two parts for the input message), but the resulting method > > signature in the skeleton code always turns out like: > > > > message(header) > > > > Note the body is absent, even though it was set up to be one of the two > > parts for the message. > > > > Other than the fact that we need to pack our security tokens into the > > header, the WSDL is pretty basic. I can't rule out that transmogrifying > > the WSDL to work with Axis 2 has led to some errors creeping in - at > this > > point, we've been staring at it for quite a while and can't see what we > > may be doing wrong. I'm attaching the WSDL here - perhaps someone can > > eyeball a problem we've missed. Note the header/body setup in the > binding > > - we construct the binding by hand - is there any way to annotate a > > message part as being destined for the header so that we could use > Eclipse > > WTP to generate the binding automagically? > > > > Thanks. > > \Sarwar > > > > > > > > > > > > > > > > "Anne Thomas Manes" <[EMAIL PROTECTED]> > > 02/06/2007 03:08 PM > > Please respond to > > [email protected] > > > > > > To > > [email protected] > > cc > > > > Subject > > Re: Axis2: skeleton differences w/Axis 1.4 > > > > > > > > > > > > > > "changing a few 'types' to 'elements'" tells me that the original WSDL > > was defined as style="rpc", and my guess is that it used RPC/encoded. > > Unfortunately, you have to do a little more than just tweak the > > "types" to "elements". For one thing, when using document style, your > > message may contain at monst one body element. That element must > > reference an element definition in your types section that contains > > all your input parameters. See my blog on wrapped document/literal for > > some guidance: > > > > > http://atmanes.blogspot.com/2005/03/wrapped-documentliteral-convention.html > > > > > > Anne > > > > On 2/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > > > Hello, > > > Just wondering if anyone has encountered this: > > > Using WSDL2JAVA on Axis 1.4, our endpoint binding implementation > > > automagically produced method signatures that took into account > multiple > > > arguments. > > > Using the same WSDL in Axis 2.0, the skeleton generated has a method > > > signature with only one of the required types as an argument. The > second > > one > > > seems to have disappeared. > > > > > > The only 'tweaks' we have made to the WSDL for Axis 2 involve > changing a > > few > > > 'types' to 'elements' to get the WSDL2JAVA to parse the WSDL. > > > > > > Can anyone eyeball something we may be missing? > > > > > > Thanks > > > \Sarwar > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > --=_alternative 001762E98525727B_=-- > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Amila Suriarachchi, WSO2 Inc.here is the problem.
you have a soap binding input element like this
<wsdl:input>
<wsdlsoap:body use="literal" />
<wsdlsoap:header message="tns:opControlRequest" part="Security" use="literal" namespace=" http://ws.test.sample.com/WSSecurity/"/>
</wsdl:input>
and your refering message like this
<wsdl:message name="opControlRequest">
<wsdl:part name="Security" element="tns:SecurityType"/>
<wsdl:part name="opControlRequest" element="tns:OpControlActionRequest"/>
</wsdl:message>
In this case since there are two parts for the message you have to sepcify which part to using in wsdl:input as follows
<wsdlsoap:body use="literal" part="opControlRequest"/>
but having done that may results the same since there is an axis2 problem. So the correct skelton is would be to generate only the body part.
Axis2 does not produce any bining specific details (header part is a binding specific)in the Skelton class. In Axis 2 if you want to handle custom headers you have to write a handler for it.
On 2/7/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Hi Davanum...
I didn't think a determination had been made that this was indeed a bug in Axis 2 which is why I have not gone the JIRA route. Was hoping someone could just tell me I was doing something wrong with regards to my WSDL (that would be an easy fix!) . I'll put something in JIRA if thats how you want me to proceed.
Thanks
\Sarwar
"Davanum Srinivas" <[EMAIL PROTECTED]> 02/07/2007 10:24 AM
[email protected]
[email protected] Re: Axis2: skeleton differences w/Axis 1.4
Sarwar,
JIRA bug please :) After you create the bug, you can upload the files as well.
thanks,
dims
On 2/6/07, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote:
>
> Addendum to last post:
> Neither the unwrapping nor backwards compatilbity options in the codegen tool helped - which leads me to believe that something in the WSDL I attached in the last message may be amiss. Our goal is to pack portions of a SOAP header and SOAP body using the WSDL definitions - any help appreciated.
>
> \Sarwar
>
>
>
> Sarwar Raza/US/[EMAIL PROTECTED]
>
> 02/06/2007 10:49 PM
>
>
> Please respond to
> [email protected]
>
>
> To [email protected]
>
> cc
>
>
> Subject Re: Axis2: skeleton differences w/Axis 1.4
>
>
>
>
>
>
>
>
> Hi Anne,
> Thanks for the response.
>
> Here is what we were able to get working with Axis 1.4, and have been
> struggling with Axis 2...
> Our input message contained TWO parts, one destined for the body, and the
> other destined for the header (we set this up in the binding).
> The header contains security info that gets used by WSSJ - pretty typical
> usage best we can tell.
>
> When we ran WSDL2Java using Axis 1.4, the resulting stubs resulted in a
> method signature for each of the methods that looked something like:
>
> message (header, body).
>
> Using Axis2, the WSDL does get parsed correctly (even though we have
> defined two parts for the input message), but the resulting method
> signature in the skeleton code always turns out like:
>
> message(header)
>
> Note the body is absent, even though it was set up to be one of the two
> parts for the message.
>
> Other than the fact that we need to pack our security tokens into the
> header, the WSDL is pretty basic. I can't rule out that transmogrifying
> the WSDL to work with Axis 2 has led to some errors creeping in - at this
> point, we've been staring at it for quite a while and can't see what we
> may be doing wrong. I'm attaching the WSDL here - perhaps someone can
> eyeball a problem we've missed. Note the header/body setup in the binding
> - we construct the binding by hand - is there any way to annotate a
> message part as being destined for the header so that we could use Eclipse
> WTP to generate the binding automagically?
>
> Thanks.
> \Sarwar
>
>
>
>
>
>
>
> "Anne Thomas Manes" <[EMAIL PROTECTED]>
> 02/06/2007 03:08 PM
> Please respond to
> [email protected]
>
>
> To
> [email protected]
> cc
>
> Subject
> Re: Axis2: skeleton differences w/Axis 1.4
>
>
>
>
>
>
> "changing a few 'types' to 'elements'" tells me that the original WSDL
> was defined as style="rpc", and my guess is that it used RPC/encoded.
> Unfortunately, you have to do a little more than just tweak the
> "types" to "elements". For one thing, when using document style, your
> message may contain at monst one body element. That element must
> reference an element definition in your types section that contains
> all your input parameters. See my blog on wrapped document/literal for
> some guidance:
>
> http://atmanes.blogspot.com/2005/03/wrapped-documentliteral-convention.html
>
>
> Anne
>
> On 2/5/07, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote:
> >
> > Hello,
> > Just wondering if anyone has encountered this:
> > Using WSDL2JAVA on Axis 1.4, our endpoint binding implementation
> > automagically produced method signatures that took into account multiple
> > arguments.
> > Using the same WSDL in Axis 2.0, the skeleton generated has a method
> > signature with only one of the required types as an argument. The second
> one
> > seems to have disappeared.
> >
> > The only 'tweaks' we have made to the WSDL for Axis 2 involve changing a
> few
> > 'types' to 'elements' to get the WSDL2JAVA to parse the WSDL.
> >
> > Can anyone eyeball something we may be missing?
> >
> > Thanks
> > \Sarwar
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> --=_alternative 001762E98525727B_=--
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Amila Suriarachchi,
WSO2 Inc.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
