You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by "Cox, Brian (GE Infra, Energy)" <br...@ge.com> on 2006/11/08 05:24:34 UTC
RPC WSDL/ Codegen?
There appears to be a problem with either the RPC WSDL code generation or the wsdl generation.
If I start with a valid RPC WSDL and generate the server skeleton using the command:
C:\1test>wsdl2java -uri BookQuoteModified.wsdl -d xmlbeans -o client -p com.ems.client
I receive a valid skeleton. If we go ahead and compile/deploy the generated skeleton, and then ask for the wsdl from the service. We are presented with a doc/literal wsdl. It seems there is an error either in the initial codegeneration or in the service wsdl generation. Has anyone else experienced this problem?
Attached is a sample RPC wsdl (BookQuote2.wsdl) which ships with Axis2.
Thanks,
Brian
<<BookQuote2.wsdl>>
Re: [Axis2] RPC WSDL/ Codegen?
Posted by tgb <TB...@SERENA.com>.
Bug submitted as AXIS2-2246
Amila Suriarachchi wrote:
>
> On 2/23/07, tgb <TB...@serena.com> wrote:
>>
>>
>> As evidence of my assertion on the "correctness" of no namespace for
>> "parts",
>> WS-I Basic 1.0 states:
>>
>> "4.7.20 Part Accessors
>> For rpc-literal envelopes, WSDL 1.1 is not clear what namespace, if any,
>> the
>> accessor elements for parameters and return value are a part of.
>> Different
>> implementations make different choices, leading to interoperability
>> problems.
>>
>> R2735 An ENVELOPE described with an rpc-literal binding MUST place the
>> part
>> accessor elements for parameters and return value in no namespace.
>>
>> R2755 The part accessor elements in a MESSAGE described with an
>> rpc-literal
>> binding MUST have a local name of the same value as the name attribute of
>> the corresponding wsdl:part element.
>>
>> Settling on one alternative is crucial to achieving interoperability. The
>> Profile places the part accessor elements in no namespace as doing so is
>> simple, covers all cases, and does not lead to logical inconsistency. "
>>
>> http://www.ws-i.org/Profiles/BasicProfile-1.2.html
>> http://www.ws-i.org/Profiles/BasicProfile-1.2.html
>>
>> This assumes WS-I basic complience is a goal for Axis2 which I'm sure is
>> the
>> case. Should I submit a bug?
>
>
> thanks Tim, please log a jira. I'll fix it to use no namespace.
>
> Tim
>>
>>
>>
>> tgb wrote:
>> >
>> > There appears to be two problems. The most obvious is that the
>> > RPC-literal message sent by the generated client and accepted by the
>> > generated service is incorrect - or so I believe. The following
>> message
>> > body is sent for the various test cases I have tried - string, complex
>> > type, nested complex type.
>> >
>> > <soapenv:Body>
>> > <ns:OperationName>
>> > <ns:PartName>
>> > .............content.....
>> > </ns:PartName>
>> > </ns:OperationName>
>> > </soapenv:Body>
>> >
>> > but it should be:
>> >
>> > <soapenv:Body>
>> > <ns:OperationName>
>> > <PartName>
>> > .............content.....
>> > </PartName>
>> > </ns:OperationName>
>> > </soapenv:Body>
>> >
>> > PartName should be a non qualified name. Axis 1.3 did it this way, and
>> > other sources support this as being the correct form for rpc-literal.
>> >
>> > The second problem that I have yet to narrow down is that with a much
>> more
>> > complex type, the generated client sends a message with a body like
>> this
>> > where the "part" element is not present:
>> >
>> > <soapenv:Body>
>> > <ns:OperationName>
>> > .............content.....
>> > </ns:OperationName>
>> > </soapenv:Body>
>> >
>> > One other differnce that may be a factor is that my complex service is
>> one
>> > way.
>> >
>> > I have attached the WSDL I'm using for the test cases in case someone
>> can
>> > point out my obvious error.
>> >
>> > Thanks,
>> > Tim
>> >
>> >
>> >
>> >
>> > tgb wrote:
>> >>
>> >> Thanks, that makes sense. I understand the workaround for getting the
>> >> service to show the correct WSDL.
>> >>
>> >> However, there seems to be a problem with the client codegen for
>> >> rpc/literal. So far I have only managed to make it work correctly
>> with
>> >> parameter that has a simple type (I tried xs:string) When I change
>> the
>> >> type of the parameter to complex type, the client no longer adds the
>> >> "part" element to the SOAP message it sends. Instead the "operation"
>> >> element contains the complex data directly as if the SOAP message was
>> a
>> >> document literal style message.
>> >>
>> >> I am using the axis2 eclipse codegen plugin 1.1.1 with the default
>> option
>> >> (ie adb generation). I'll attach the WSDLs once I think I have a
>> >> reproducible case
>> >>
>> >> Tim
>> >>
>> >>
>> >> Amila Suriarachchi wrote:
>> >>>
>> >>> hi,
>> >>> In codegeneration with wsdl, we convert the rpc style wsdl in to
>> >>> document
>> >>> style (similar in messages) by generating the elements for rpc type
>> >>> messages. And finally save the wsdl file to resource directory. When
>> >>> saving
>> >>> the wsdl file back it serializes the generated axis service object
>> >>> structure
>> >>> instead of saving the origianl wsdl as it is. That is the reason why
>> you
>> >>> get
>> >>> a wsdl which is converted to document style. So can you please
>> replace
>> >>> your
>> >>> saved wsdl in resource folder with the original wsdl and see.
>> >>> On the other hand axis2 generates a wsdl only if the Message receiver
>> is
>> >>> one
>> >>> of RPCMessageReceivers. but when generating the code from the wsdl it
>> >>> creates a custom message receiver for the given wsdl file.
>> >>>
>> >>> Amila.
>> >>> --
>> >>> Amila Suriarachchi,
>> >>> WSO2 Inc.
>> >>>
>> >>>
>> >>
>> >>
>> > http://www.nabble.com/file/6694/Axis2RPCLiteralTest.wsdl
>> > Axis2RPCLiteralTest.wsdl
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/RPC-WSDL---Codegen--tf2593238.html#a9113880
>> Sent from the Axis - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>
>>
>
>
> --
> Amila Suriarachchi,
> WSO2 Inc.
>
>
--
View this message in context: http://www.nabble.com/RPC-WSDL---Codegen--tf2593238.html#a9114466
Sent from the Axis - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: [Axis2] RPC WSDL/ Codegen?
Posted by Amila Suriarachchi <am...@gmail.com>.
On 2/23/07, tgb <TB...@serena.com> wrote:
>
>
> As evidence of my assertion on the "correctness" of no namespace for
> "parts",
> WS-I Basic 1.0 states:
>
> "4.7.20 Part Accessors
> For rpc-literal envelopes, WSDL 1.1 is not clear what namespace, if any,
> the
> accessor elements for parameters and return value are a part of. Different
> implementations make different choices, leading to interoperability
> problems.
>
> R2735 An ENVELOPE described with an rpc-literal binding MUST place the
> part
> accessor elements for parameters and return value in no namespace.
>
> R2755 The part accessor elements in a MESSAGE described with an
> rpc-literal
> binding MUST have a local name of the same value as the name attribute of
> the corresponding wsdl:part element.
>
> Settling on one alternative is crucial to achieving interoperability. The
> Profile places the part accessor elements in no namespace as doing so is
> simple, covers all cases, and does not lead to logical inconsistency. "
>
> http://www.ws-i.org/Profiles/BasicProfile-1.2.html
> http://www.ws-i.org/Profiles/BasicProfile-1.2.html
>
> This assumes WS-I basic complience is a goal for Axis2 which I'm sure is
> the
> case. Should I submit a bug?
thanks Tim, please log a jira. I'll fix it to use no namespace.
Tim
>
>
>
> tgb wrote:
> >
> > There appears to be two problems. The most obvious is that the
> > RPC-literal message sent by the generated client and accepted by the
> > generated service is incorrect - or so I believe. The following message
> > body is sent for the various test cases I have tried - string, complex
> > type, nested complex type.
> >
> > <soapenv:Body>
> > <ns:OperationName>
> > <ns:PartName>
> > .............content.....
> > </ns:PartName>
> > </ns:OperationName>
> > </soapenv:Body>
> >
> > but it should be:
> >
> > <soapenv:Body>
> > <ns:OperationName>
> > <PartName>
> > .............content.....
> > </PartName>
> > </ns:OperationName>
> > </soapenv:Body>
> >
> > PartName should be a non qualified name. Axis 1.3 did it this way, and
> > other sources support this as being the correct form for rpc-literal.
> >
> > The second problem that I have yet to narrow down is that with a much
> more
> > complex type, the generated client sends a message with a body like this
> > where the "part" element is not present:
> >
> > <soapenv:Body>
> > <ns:OperationName>
> > .............content.....
> > </ns:OperationName>
> > </soapenv:Body>
> >
> > One other differnce that may be a factor is that my complex service is
> one
> > way.
> >
> > I have attached the WSDL I'm using for the test cases in case someone
> can
> > point out my obvious error.
> >
> > Thanks,
> > Tim
> >
> >
> >
> >
> > tgb wrote:
> >>
> >> Thanks, that makes sense. I understand the workaround for getting the
> >> service to show the correct WSDL.
> >>
> >> However, there seems to be a problem with the client codegen for
> >> rpc/literal. So far I have only managed to make it work correctly with
> >> parameter that has a simple type (I tried xs:string) When I change the
> >> type of the parameter to complex type, the client no longer adds the
> >> "part" element to the SOAP message it sends. Instead the "operation"
> >> element contains the complex data directly as if the SOAP message was a
> >> document literal style message.
> >>
> >> I am using the axis2 eclipse codegen plugin 1.1.1 with the default
> option
> >> (ie adb generation). I'll attach the WSDLs once I think I have a
> >> reproducible case
> >>
> >> Tim
> >>
> >>
> >> Amila Suriarachchi wrote:
> >>>
> >>> hi,
> >>> In codegeneration with wsdl, we convert the rpc style wsdl in to
> >>> document
> >>> style (similar in messages) by generating the elements for rpc type
> >>> messages. And finally save the wsdl file to resource directory. When
> >>> saving
> >>> the wsdl file back it serializes the generated axis service object
> >>> structure
> >>> instead of saving the origianl wsdl as it is. That is the reason why
> you
> >>> get
> >>> a wsdl which is converted to document style. So can you please replace
> >>> your
> >>> saved wsdl in resource folder with the original wsdl and see.
> >>> On the other hand axis2 generates a wsdl only if the Message receiver
> is
> >>> one
> >>> of RPCMessageReceivers. but when generating the code from the wsdl it
> >>> creates a custom message receiver for the given wsdl file.
> >>>
> >>> Amila.
> >>> --
> >>> Amila Suriarachchi,
> >>> WSO2 Inc.
> >>>
> >>>
> >>
> >>
> > http://www.nabble.com/file/6694/Axis2RPCLiteralTest.wsdl
> > Axis2RPCLiteralTest.wsdl
> >
>
> --
> View this message in context:
> http://www.nabble.com/RPC-WSDL---Codegen--tf2593238.html#a9113880
> Sent from the Axis - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: [Axis2] RPC WSDL/ Codegen?
Posted by tgb <TB...@SERENA.com>.
As evidence of my assertion on the "correctness" of no namespace for "parts",
WS-I Basic 1.0 states:
"4.7.20 Part Accessors
For rpc-literal envelopes, WSDL 1.1 is not clear what namespace, if any, the
accessor elements for parameters and return value are a part of. Different
implementations make different choices, leading to interoperability
problems.
R2735 An ENVELOPE described with an rpc-literal binding MUST place the part
accessor elements for parameters and return value in no namespace.
R2755 The part accessor elements in a MESSAGE described with an rpc-literal
binding MUST have a local name of the same value as the name attribute of
the corresponding wsdl:part element.
Settling on one alternative is crucial to achieving interoperability. The
Profile places the part accessor elements in no namespace as doing so is
simple, covers all cases, and does not lead to logical inconsistency. "
http://www.ws-i.org/Profiles/BasicProfile-1.2.html
http://www.ws-i.org/Profiles/BasicProfile-1.2.html
This assumes WS-I basic complience is a goal for Axis2 which I'm sure is the
case. Should I submit a bug?
Tim
tgb wrote:
>
> There appears to be two problems. The most obvious is that the
> RPC-literal message sent by the generated client and accepted by the
> generated service is incorrect - or so I believe. The following message
> body is sent for the various test cases I have tried - string, complex
> type, nested complex type.
>
> <soapenv:Body>
> <ns:OperationName>
> <ns:PartName>
> .............content.....
> </ns:PartName>
> </ns:OperationName>
> </soapenv:Body>
>
> but it should be:
>
> <soapenv:Body>
> <ns:OperationName>
> <PartName>
> .............content.....
> </PartName>
> </ns:OperationName>
> </soapenv:Body>
>
> PartName should be a non qualified name. Axis 1.3 did it this way, and
> other sources support this as being the correct form for rpc-literal.
>
> The second problem that I have yet to narrow down is that with a much more
> complex type, the generated client sends a message with a body like this
> where the "part" element is not present:
>
> <soapenv:Body>
> <ns:OperationName>
> .............content.....
> </ns:OperationName>
> </soapenv:Body>
>
> One other differnce that may be a factor is that my complex service is one
> way.
>
> I have attached the WSDL I'm using for the test cases in case someone can
> point out my obvious error.
>
> Thanks,
> Tim
>
>
>
>
> tgb wrote:
>>
>> Thanks, that makes sense. I understand the workaround for getting the
>> service to show the correct WSDL.
>>
>> However, there seems to be a problem with the client codegen for
>> rpc/literal. So far I have only managed to make it work correctly with
>> parameter that has a simple type (I tried xs:string) When I change the
>> type of the parameter to complex type, the client no longer adds the
>> "part" element to the SOAP message it sends. Instead the "operation"
>> element contains the complex data directly as if the SOAP message was a
>> document literal style message.
>>
>> I am using the axis2 eclipse codegen plugin 1.1.1 with the default option
>> (ie adb generation). I'll attach the WSDLs once I think I have a
>> reproducible case
>>
>> Tim
>>
>>
>> Amila Suriarachchi wrote:
>>>
>>> hi,
>>> In codegeneration with wsdl, we convert the rpc style wsdl in to
>>> document
>>> style (similar in messages) by generating the elements for rpc type
>>> messages. And finally save the wsdl file to resource directory. When
>>> saving
>>> the wsdl file back it serializes the generated axis service object
>>> structure
>>> instead of saving the origianl wsdl as it is. That is the reason why you
>>> get
>>> a wsdl which is converted to document style. So can you please replace
>>> your
>>> saved wsdl in resource folder with the original wsdl and see.
>>> On the other hand axis2 generates a wsdl only if the Message receiver is
>>> one
>>> of RPCMessageReceivers. but when generating the code from the wsdl it
>>> creates a custom message receiver for the given wsdl file.
>>>
>>> Amila.
>>> --
>>> Amila Suriarachchi,
>>> WSO2 Inc.
>>>
>>>
>>
>>
> http://www.nabble.com/file/6694/Axis2RPCLiteralTest.wsdl
> Axis2RPCLiteralTest.wsdl
>
--
View this message in context: http://www.nabble.com/RPC-WSDL---Codegen--tf2593238.html#a9113880
Sent from the Axis - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: [Axis2] RPC WSDL/ Codegen?
Posted by Amila Suriarachchi <am...@gmail.com>.
On 2/22/07, tgb <TB...@serena.com> wrote:
>
>
> There appears to be two problems. The most obvious is that the
> RPC-literal
> message sent by the generated client and accepted by the generated service
> is incorrect - or so I believe. The following message body is sent for
> the
> various test cases I have tried - string, complex type, nested complex
> type.
>
> <soapenv:Body>
> <ns:OperationName>
> <ns:PartName>
> .............content.....
> </ns:PartName>
> </ns:OperationName>
> </soapenv:Body>
>
> but it should be:
>
> <soapenv:Body>
> <ns:OperationName>
> <PartName>
> .............content.....
> </PartName>
> </ns:OperationName>
> </soapenv:Body>
>
> PartName should be a non qualified name. Axis 1.3 did it this way, and
> other sources support this as being the correct form for rpc-literal.
What are those other sources? I check with the WSDL spec and basic profile
but could not find a clue to confirm this. So If you have found any thing
please let us know. Do you have any experience with .Net and other
soapstacks?
if every one does it with out using the namespace we can do the same to
axis2.
The second problem that I have yet to narrow down is that with a much more
> complex type, the generated client sends a message with a body like this
> where the "part" element is not present:
>
> <soapenv:Body>
> <ns:OperationName>
> .............content.....
> </ns:OperationName>
> </soapenv:Body>
I tested this with the current trunk. Here is the request
<ns1:NestedOperation xmlns:ns1="http://www.example.org/Axis2RPCLiteralTest/
">
<ns1:NestedOperationRequest>
<ns1:Nested>
<ns1:Field1>string 1</ns1:Field1>
</ns1:Nested>
</ns1:NestedOperationRequest>
</ns1:NestedOperation>
Can you please test this with a nightly build? but I think this should work
correctly with the axis2 1.1.1 as well.
Thanks,
> Tim
>
>
> --
Amila Suriarachchi,
WSO2 Inc.
Re: [Axis2] RPC WSDL/ Codegen?
Posted by tgb <TB...@SERENA.com>.
There appears to be two problems. The most obvious is that the RPC-literal
message sent by the generated client and accepted by the generated service
is incorrect - or so I believe. The following message body is sent for the
various test cases I have tried - string, complex type, nested complex type.
<soapenv:Body>
<ns:OperationName>
<ns:PartName>
.............content.....
</ns:PartName>
</ns:OperationName>
</soapenv:Body>
but it should be:
<soapenv:Body>
<ns:OperationName>
<PartName>
.............content.....
</PartName>
</ns:OperationName>
</soapenv:Body>
PartName should be a non qualified name. Axis 1.3 did it this way, and
other sources support this as being the correct form for rpc-literal.
The second problem that I have yet to narrow down is that with a much more
complex type, the generated client sends a message with a body like this
where the "part" element is not present:
<soapenv:Body>
<ns:OperationName>
.............content.....
</ns:OperationName>
</soapenv:Body>
One other differnce that may be a factor is that my complex service is one
way.
I have attached the WSDL I'm using for the test cases in case someone can
point out my obvious error.
Thanks,
Tim
tgb wrote:
>
> Thanks, that makes sense. I understand the workaround for getting the
> service to show the correct WSDL.
>
> However, there seems to be a problem with the client codegen for
> rpc/literal. So far I have only managed to make it work correctly with
> parameter that has a simple type (I tried xs:string) When I change the
> type of the parameter to complex type, the client no longer adds the
> "part" element to the SOAP message it sends. Instead the "operation"
> element contains the complex data directly as if the SOAP message was a
> document literal style message.
>
> I am using the axis2 eclipse codegen plugin 1.1.1 with the default option
> (ie adb generation). I'll attach the WSDLs once I think I have a
> reproducible case
>
> Tim
>
>
> Amila Suriarachchi wrote:
>>
>> hi,
>> In codegeneration with wsdl, we convert the rpc style wsdl in to document
>> style (similar in messages) by generating the elements for rpc type
>> messages. And finally save the wsdl file to resource directory. When
>> saving
>> the wsdl file back it serializes the generated axis service object
>> structure
>> instead of saving the origianl wsdl as it is. That is the reason why you
>> get
>> a wsdl which is converted to document style. So can you please replace
>> your
>> saved wsdl in resource folder with the original wsdl and see.
>> On the other hand axis2 generates a wsdl only if the Message receiver is
>> one
>> of RPCMessageReceivers. but when generating the code from the wsdl it
>> creates a custom message receiver for the given wsdl file.
>>
>> Amila.
>> --
>> Amila Suriarachchi,
>> WSO2 Inc.
>>
>>
>
>
http://www.nabble.com/file/6694/Axis2RPCLiteralTest.wsdl
Axis2RPCLiteralTest.wsdl
--
View this message in context: http://www.nabble.com/RPC-WSDL---Codegen--tf2593238.html#a9098426
Sent from the Axis - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: [Axis2] RPC WSDL/ Codegen?
Posted by tgb <TB...@SERENA.com>.
Thanks, that makes sense. I understand the workaround for getting the service
to show the correct WSDL.
However, there seems to be a problem with the client codegen for
rpc/literal. So far I have only managed to make it work correctly with
parameter that has a simple type (I tried xs:string) When I change the type
of the parameter to complex type, the client no longer adds the "part"
element to the SOAP message it sends. Instead the "operation" element
contains the complex data directly as if the SOAP message was a document
literal style message.
I am using the axis2 eclipse codegen plugin 1.1.1 with the default option
(ie adb generation). I'll attach the WSDLs once I think I have a
reproducible case
Tim
Amila Suriarachchi wrote:
>
> hi,
> In codegeneration with wsdl, we convert the rpc style wsdl in to document
> style (similar in messages) by generating the elements for rpc type
> messages. And finally save the wsdl file to resource directory. When
> saving
> the wsdl file back it serializes the generated axis service object
> structure
> instead of saving the origianl wsdl as it is. That is the reason why you
> get
> a wsdl which is converted to document style. So can you please replace
> your
> saved wsdl in resource folder with the original wsdl and see.
> On the other hand axis2 generates a wsdl only if the Message receiver is
> one
> of RPCMessageReceivers. but when generating the code from the wsdl it
> creates a custom message receiver for the given wsdl file.
>
> Amila.
> --
> Amila Suriarachchi,
> WSO2 Inc.
>
>
--
View this message in context: http://www.nabble.com/RPC-WSDL---Codegen--tf2593238.html#a9094660
Sent from the Axis - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: [Axis2] RPC WSDL/ Codegen?
Posted by Amila Suriarachchi <am...@gmail.com>.
hi,
In codegeneration with wsdl, we convert the rpc style wsdl in to document
style (similar in messages) by generating the elements for rpc type
messages. And finally save the wsdl file to resource directory. When saving
the wsdl file back it serializes the generated axis service object structure
instead of saving the origianl wsdl as it is. That is the reason why you get
a wsdl which is converted to document style. So can you please replace your
saved wsdl in resource folder with the original wsdl and see.
On the other hand axis2 generates a wsdl only if the Message receiver is one
of RPCMessageReceivers. but when generating the code from the wsdl it
creates a custom message receiver for the given wsdl file.
Amila.
--
Amila Suriarachchi,
WSO2 Inc.
Re: [Axis2] RPC WSDL/ Codegen?
Posted by tgb <TB...@SERENA.com>.
I tried a simple example - the default rpc literal wsdl generated by eclipse
WTP. This has a single operation that takes a single string parameter and
returns a string. It appears that the generated client for this example
does send an RPC literal message and that the generated service responds
correctly even though the ?WSDL it reports shows it as being a
document/literal service.
However, my client that has the problem has a complex parameter. Also I
heard somewhere that there was a problem if the MessageType and the
Operation had the same name which mine did. I changed my WSDL to try that
as a workaround but it did not seem to fix the problem. I will try it again
and see if I can narrow it down.
thanks,
Tim
tgb wrote:
>
> Thanks. That's good to know. I'm interested in doing that. However, it
> is not the problem I'm currently having.
>
> The problem is that the codegen is generating a document/literal service
> and client from an rpc/literal WSDL. Possibly the server is just
> mis-reporting its WSDL but the client generated from an rpc/literal wsdl
> is definately sending document/literal messages. I am using the original
> rpc-literal WSDL to generate the client not the ?wsdl.
>
>
> Tim
>
>
>
> Manoj Khangaonkar wrote:
>>
>> When you query for the WSDL using ?wsdl, AXIS2 returns a generated WSDL
>> and
>> not the one you
>> deployed.
>>
>> If you want it to return the WSDL you deployed , you need to add the
>> following to services.xml
>>
>> <parameter name="useOriginalWSDL"> true </parameter>
>>
>> However see my posting to axis-dev - which is below. There are a few
>> issues
>> with this - and I'll
>> try to provide patches shortly.
>>
>> Mj
>>
>> ---------- Forwarded message ----------
>> From: Manoj Khangaonkar <kh...@gmail.com>
>> Date: Feb 19, 2007 10:57 PM
>> Subject: [AXIS2] useOriginalWSDL parameter - issues / possible solutions
>> To: axis-dev <ax...@ws.apache.org>
>>
>> Hi all,
>>
>> I observed a few issues with the useOrignalWSDL parameter. Let me list
>> them
>> and if there is consensus I can provide the necessary patch.
>>
>> My understanding of the intended behavior is that if
>>
>> <parameter name="useOrignalWSDL"> true </parameter>
>>
>> is defined in services.xml, then any explicit .wsdl file that the user
>> packaged in the services.aar is returned , when user
>> queries for WSDL with a HTTP get such as
>>
>> http://localhost:8080/services/axis2/<servicename>?wsdl<http://localhost:8080/services/axis2/%3Cservicename%3E?wsdl>
>>
>> If useOriginalWSDL parameter is omitted or value is false, any packaged
>> WSDL
>> is ignored and a generated WSDL is returned.
>>
>>
>> 1. So the default behaviour of the kernel is to return a generated WSDL
>> -
>> as if useOrginalWSDL = false. This seems a little non-intuitive. If a
>> user
>> explicitly deployed a WSDL file with his aar, chances are high that he
>> wants
>> that WSDL to be used and not the generated one. Thus the default
>> behaviour
>> should be useOrginalWSDL = true; in other words , if there is WSDL file
>> in
>> the aar, and useOrignalWSDL is not defined - then use/return the WSDL
>> file
>> in the aar. Defaulting to true is less work for everyone.
>>
>>
>> 2. When useOrignalWSDL = false and there is an explicit WSDL in the aar,
>> the
>> query
>>
>> http://localhost:8080/services/axis2/<servicename>?wsdl<http://localhost:8080/services/axis2/%3Cservicename%3E?wsdl>
>>
>> returns a WSDL where the target namespace of the types section is from
>> the
>> explicit WSDL. Some unnecessary
>> namespaces are declared as well. This is bug and should be fixed.
>>
>> 3. The code path for WSDL 20 does not check whether useOriginalWSDL is
>> true/false
>>
>>
>> 4. Lastly - is there a good use case of this parameter ? Unless there is,
>> We
>> could remove this parameter without
>> losing any functionality.
>>
>> If the use added an explicit WSDL to the aar , then that should be
>> used/returned and if there is no WSDL, it should
>> be generated.
>>
>> If I have to add/change a parameter in services.xml and redeploy -- I can
>> add/remove WSDL and redeploy.
>>
>>
>> Mj
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 2/21/07, tgb <TB...@serena.com> wrote:
>>>
>>>
>>> I am getting the same problem with my rpc/literal WSDL. I am using
>>> axis2
>>> 1.1.1 and the related codegen eclipse plugin v1.1.1. The generation
>>> works
>>> fine and I was able to deploy the service but it reports itself as
>>> document-literal at ?wsdl. The client I generated from the original
>>> rpc/literal/wsdl sends document-literal style messages.
>>>
>>> This all worked fine using axis 1.3 and eclipse 3.2 WTP 1.5.1
>>>
>>> Just wondered if you ever solved the problem or if anyone else knows if
>>> the
>>> lastest nightly build fixes this issue.
>>>
>>> I've been searching but so far haven't found anyting definitive.
>>>
>>> Thanks,
>>> Tim
>>>
>>>
>>> Cox, Brian (GE Infra, Energy) wrote:
>>> >
>>> > There appears to be a problem with either the RPC WSDL code generation
>>> or
>>> > the wsdl generation.
>>> >
>>> > If I start with a valid RPC WSDL and generate the server skeleton
>>> using
>>> > the command:
>>> >
>>> > C:\1test>wsdl2java -uri BookQuoteModified.wsdl -d xmlbeans -o client
>>> -p
>>> > com.ems.client
>>> >
>>> > I receive a valid skeleton. If we go ahead and compile/deploy the
>>> > generated skeleton, and then ask for the wsdl from the service. We
>>> are
>>> > presented with a doc/literal wsdl. It seems there is an error either
>>> in
>>> > the initial codegeneration or in the service wsdl generation. Has
>>> anyone
>>> > else experienced this problem?
>>> >
>>> > Attached is a sample RPC wsdl (BookQuote2.wsdl) which ships with
>>> Axis2.
>>> >
>>> > Thanks,
>>> >
>>> > Brian
>>> >
>>> >
>>> >
>>> > <<BookQuote2.wsdl >>
>>> >
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>>> > For additional commands, e-mail: axis-user-help@ws.apache.org
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/RPC-WSDL---Codegen--tf2593238.html#a9092547
>>> Sent from the Axis - User mailing list archive at
>>> Nabble.com<http://nabble.com/>
>>> .
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>>
>>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/RPC-WSDL---Codegen--tf2593238.html#a9093543
Sent from the Axis - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: [Axis2] RPC WSDL/ Codegen?
Posted by tgb <TB...@SERENA.com>.
Thanks. That's good to know. I'm interested in doing that. However, it is
not the problem I'm currently having.
The problem is that the codegen is generating a document/literal service and
client from an rpc/literal WSDL. Possibly the server is just mis-reporting
its WSDL but the client generated from an rpc/literal wsdl is definately
sending document/literal messages. I am using the original rpc-literal WSDL
to generate the client not the ?wsdl.
Tim
Manoj Khangaonkar wrote:
>
> When you query for the WSDL using ?wsdl, AXIS2 returns a generated WSDL
> and
> not the one you
> deployed.
>
> If you want it to return the WSDL you deployed , you need to add the
> following to services.xml
>
> <parameter name="useOriginalWSDL"> true </parameter>
>
> However see my posting to axis-dev - which is below. There are a few
> issues
> with this - and I'll
> try to provide patches shortly.
>
> Mj
>
> ---------- Forwarded message ----------
> From: Manoj Khangaonkar <kh...@gmail.com>
> Date: Feb 19, 2007 10:57 PM
> Subject: [AXIS2] useOriginalWSDL parameter - issues / possible solutions
> To: axis-dev <ax...@ws.apache.org>
>
> Hi all,
>
> I observed a few issues with the useOrignalWSDL parameter. Let me list
> them
> and if there is consensus I can provide the necessary patch.
>
> My understanding of the intended behavior is that if
>
> <parameter name="useOrignalWSDL"> true </parameter>
>
> is defined in services.xml, then any explicit .wsdl file that the user
> packaged in the services.aar is returned , when user
> queries for WSDL with a HTTP get such as
>
> http://localhost:8080/services/axis2/<servicename>?wsdl<http://localhost:8080/services/axis2/%3Cservicename%3E?wsdl>
>
> If useOriginalWSDL parameter is omitted or value is false, any packaged
> WSDL
> is ignored and a generated WSDL is returned.
>
>
> 1. So the default behaviour of the kernel is to return a generated WSDL -
> as if useOrginalWSDL = false. This seems a little non-intuitive. If a user
> explicitly deployed a WSDL file with his aar, chances are high that he
> wants
> that WSDL to be used and not the generated one. Thus the default behaviour
> should be useOrginalWSDL = true; in other words , if there is WSDL file in
> the aar, and useOrignalWSDL is not defined - then use/return the WSDL file
> in the aar. Defaulting to true is less work for everyone.
>
>
> 2. When useOrignalWSDL = false and there is an explicit WSDL in the aar,
> the
> query
>
> http://localhost:8080/services/axis2/<servicename>?wsdl<http://localhost:8080/services/axis2/%3Cservicename%3E?wsdl>
>
> returns a WSDL where the target namespace of the types section is from the
> explicit WSDL. Some unnecessary
> namespaces are declared as well. This is bug and should be fixed.
>
> 3. The code path for WSDL 20 does not check whether useOriginalWSDL is
> true/false
>
>
> 4. Lastly - is there a good use case of this parameter ? Unless there is,
> We
> could remove this parameter without
> losing any functionality.
>
> If the use added an explicit WSDL to the aar , then that should be
> used/returned and if there is no WSDL, it should
> be generated.
>
> If I have to add/change a parameter in services.xml and redeploy -- I can
> add/remove WSDL and redeploy.
>
>
> Mj
>
>
>
>
>
>
>
>
>
>
> On 2/21/07, tgb <TB...@serena.com> wrote:
>>
>>
>> I am getting the same problem with my rpc/literal WSDL. I am using axis2
>> 1.1.1 and the related codegen eclipse plugin v1.1.1. The generation
>> works
>> fine and I was able to deploy the service but it reports itself as
>> document-literal at ?wsdl. The client I generated from the original
>> rpc/literal/wsdl sends document-literal style messages.
>>
>> This all worked fine using axis 1.3 and eclipse 3.2 WTP 1.5.1
>>
>> Just wondered if you ever solved the problem or if anyone else knows if
>> the
>> lastest nightly build fixes this issue.
>>
>> I've been searching but so far haven't found anyting definitive.
>>
>> Thanks,
>> Tim
>>
>>
>> Cox, Brian (GE Infra, Energy) wrote:
>> >
>> > There appears to be a problem with either the RPC WSDL code generation
>> or
>> > the wsdl generation.
>> >
>> > If I start with a valid RPC WSDL and generate the server skeleton using
>> > the command:
>> >
>> > C:\1test>wsdl2java -uri BookQuoteModified.wsdl -d xmlbeans -o client -p
>> > com.ems.client
>> >
>> > I receive a valid skeleton. If we go ahead and compile/deploy the
>> > generated skeleton, and then ask for the wsdl from the service. We are
>> > presented with a doc/literal wsdl. It seems there is an error either
>> in
>> > the initial codegeneration or in the service wsdl generation. Has
>> anyone
>> > else experienced this problem?
>> >
>> > Attached is a sample RPC wsdl (BookQuote2.wsdl) which ships with Axis2.
>> >
>> > Thanks,
>> >
>> > Brian
>> >
>> >
>> >
>> > <<BookQuote2.wsdl >>
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: axis-user-help@ws.apache.org
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/RPC-WSDL---Codegen--tf2593238.html#a9092547
>> Sent from the Axis - User mailing list archive at
>> Nabble.com<http://nabble.com/>
>> .
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>
>>
>
>
--
View this message in context: http://www.nabble.com/RPC-WSDL---Codegen--tf2593238.html#a9093041
Sent from the Axis - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: [Axis2] RPC WSDL/ Codegen?
Posted by Manoj Khangaonkar <kh...@gmail.com>.
When you query for the WSDL using ?wsdl, AXIS2 returns a generated WSDL and
not the one you
deployed.
If you want it to return the WSDL you deployed , you need to add the
following to services.xml
<parameter name="useOriginalWSDL"> true </parameter>
However see my posting to axis-dev - which is below. There are a few issues
with this - and I'll
try to provide patches shortly.
Mj
---------- Forwarded message ----------
From: Manoj Khangaonkar <kh...@gmail.com>
Date: Feb 19, 2007 10:57 PM
Subject: [AXIS2] useOriginalWSDL parameter - issues / possible solutions
To: axis-dev <ax...@ws.apache.org>
Hi all,
I observed a few issues with the useOrignalWSDL parameter. Let me list them
and if there is consensus I can provide the necessary patch.
My understanding of the intended behavior is that if
<parameter name="useOrignalWSDL"> true </parameter>
is defined in services.xml, then any explicit .wsdl file that the user
packaged in the services.aar is returned , when user
queries for WSDL with a HTTP get such as
http://localhost:8080/services/axis2/<servicename>?wsdl<http://localhost:8080/services/axis2/%3Cservicename%3E?wsdl>
If useOriginalWSDL parameter is omitted or value is false, any packaged WSDL
is ignored and a generated WSDL is returned.
1. So the default behaviour of the kernel is to return a generated WSDL -
as if useOrginalWSDL = false. This seems a little non-intuitive. If a user
explicitly deployed a WSDL file with his aar, chances are high that he wants
that WSDL to be used and not the generated one. Thus the default behaviour
should be useOrginalWSDL = true; in other words , if there is WSDL file in
the aar, and useOrignalWSDL is not defined - then use/return the WSDL file
in the aar. Defaulting to true is less work for everyone.
2. When useOrignalWSDL = false and there is an explicit WSDL in the aar, the
query
http://localhost:8080/services/axis2/<servicename>?wsdl<http://localhost:8080/services/axis2/%3Cservicename%3E?wsdl>
returns a WSDL where the target namespace of the types section is from the
explicit WSDL. Some unnecessary
namespaces are declared as well. This is bug and should be fixed.
3. The code path for WSDL 20 does not check whether useOriginalWSDL is
true/false
4. Lastly - is there a good use case of this parameter ? Unless there is, We
could remove this parameter without
losing any functionality.
If the use added an explicit WSDL to the aar , then that should be
used/returned and if there is no WSDL, it should
be generated.
If I have to add/change a parameter in services.xml and redeploy -- I can
add/remove WSDL and redeploy.
Mj
On 2/21/07, tgb <TB...@serena.com> wrote:
>
>
> I am getting the same problem with my rpc/literal WSDL. I am using axis2
> 1.1.1 and the related codegen eclipse plugin v1.1.1. The generation works
> fine and I was able to deploy the service but it reports itself as
> document-literal at ?wsdl. The client I generated from the original
> rpc/literal/wsdl sends document-literal style messages.
>
> This all worked fine using axis 1.3 and eclipse 3.2 WTP 1.5.1
>
> Just wondered if you ever solved the problem or if anyone else knows if
> the
> lastest nightly build fixes this issue.
>
> I've been searching but so far haven't found anyting definitive.
>
> Thanks,
> Tim
>
>
> Cox, Brian (GE Infra, Energy) wrote:
> >
> > There appears to be a problem with either the RPC WSDL code generation
> or
> > the wsdl generation.
> >
> > If I start with a valid RPC WSDL and generate the server skeleton using
> > the command:
> >
> > C:\1test>wsdl2java -uri BookQuoteModified.wsdl -d xmlbeans -o client -p
> > com.ems.client
> >
> > I receive a valid skeleton. If we go ahead and compile/deploy the
> > generated skeleton, and then ask for the wsdl from the service. We are
> > presented with a doc/literal wsdl. It seems there is an error either in
> > the initial codegeneration or in the service wsdl generation. Has
> anyone
> > else experienced this problem?
> >
> > Attached is a sample RPC wsdl (BookQuote2.wsdl) which ships with Axis2.
> >
> > Thanks,
> >
> > Brian
> >
> >
> >
> > <<BookQuote2.wsdl >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
>
> --
> View this message in context:
> http://www.nabble.com/RPC-WSDL---Codegen--tf2593238.html#a9092547
> Sent from the Axis - User mailing list archive at Nabble.com<http://nabble.com/>
> .
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
Re: [Axis2] RPC WSDL/ Codegen?
Posted by tgb <TB...@SERENA.com>.
I am getting the same problem with my rpc/literal WSDL. I am using axis2
1.1.1 and the related codegen eclipse plugin v1.1.1. The generation works
fine and I was able to deploy the service but it reports itself as
document-literal at ?wsdl. The client I generated from the original
rpc/literal/wsdl sends document-literal style messages.
This all worked fine using axis 1.3 and eclipse 3.2 WTP 1.5.1
Just wondered if you ever solved the problem or if anyone else knows if the
lastest nightly build fixes this issue.
I've been searching but so far haven't found anyting definitive.
Thanks,
Tim
Cox, Brian (GE Infra, Energy) wrote:
>
> There appears to be a problem with either the RPC WSDL code generation or
> the wsdl generation.
>
> If I start with a valid RPC WSDL and generate the server skeleton using
> the command:
>
> C:\1test>wsdl2java -uri BookQuoteModified.wsdl -d xmlbeans -o client -p
> com.ems.client
>
> I receive a valid skeleton. If we go ahead and compile/deploy the
> generated skeleton, and then ask for the wsdl from the service. We are
> presented with a doc/literal wsdl. It seems there is an error either in
> the initial codegeneration or in the service wsdl generation. Has anyone
> else experienced this problem?
>
> Attached is a sample RPC wsdl (BookQuote2.wsdl) which ships with Axis2.
>
> Thanks,
>
> Brian
>
>
>
> <<BookQuote2.wsdl>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
--
View this message in context: http://www.nabble.com/RPC-WSDL---Codegen--tf2593238.html#a9092547
Sent from the Axis - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org