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 Mike Haller <Mi...@Innovations.de> on 2005/05/12 15:54:41 UTC
No such operation 'in0'
Hi,
i've got the following exception:
--------------------------------
AxisFault
faultCode: {http://xml.apache.org/axis/}Client
faultSubcode:
faultString: No such operation 'in0'
faultActor:
faultNode:
faultDetail:
{http://xml.apache.org/axis/}stackTrace:No such operation 'in0'
at
org.apache.axis.providers.java.RPCProvider.processMessage(RPCProvider.java:179)
at
org.apache.axis.providers.java.JavaProvider.invoke(JavaProvider.java:319)
...
--------------------------------
However, the SOAP request seems to look like this (the output comes from
one custom handler):
--------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body>
<in0 xsi:nil="true" xmlns="myns1"/></soapenv:Body></soapenv:Envelope>
--------------------------------
The output of msgContext.getOperationDesc() returns the correct method
name, which is completely missing in the above soap message. I'm
wondering where the problem lies and can't find it.
Perhaps someone can direct me into the right direction?
regards
MIke
Re: No such operation 'in0'
Posted by Mike Haller <Mi...@Innovations.de>.
Thank you very very much!
Anne Thomas Manes schrieb:
> rpc/literal and wrapped document/literal may look identical on the
> wire if you define your doc/literal schema as
> elementFormDefault="unqualified". If you define the schema as
> elementFormDefault="qualified", then the parameter elements will be
> namespace qualified, and the messages won't be quite the same.
>
> The major difference between rpc/literal and wrapped doc/literal is
> that with rpc/literal you do not have a schema of the contents of the
> <soap:Body>, and with wrapped doc/literal you do have a schema. When
> using rpc/literal, you don't define the message element, you only
> define the element types, and the SOAP engine automatically builds the
> message structure based on the type definitions. You can validate the
> message using a schema, but the validation routine must understand the
> RPC generation conventions, so it's not quite as straightforward as
> when using doc/literal.
>
> Another important difference is that .NET supports wrapped doc/literal
> (by default), but it does not support rpc/literal.
>
> rpc/encoded is a significantly different creature than rpc/literal. In
> this case, the SOAP engine constructs the message not based on the
> schema definition, but based on the SOAP encoding model. Schema
> validation typically doesn't work.
>
> Anne
>
> On 5/12/05, Mike Haller <Mi...@innovations.de> wrote:
>
>>Thanks Anne!
>>
>>I changed operation style to "wrapped" in the server-config.wsdd
>>It added an additional element between the parameter and the soap body
>>element. It's working fine now! :-)
>>
>>@All
>>But - what's the difference to RPC-style then?
>>
>>However, the I kept struggling with Axis+Castor+Serializer the last few
>>hours and am very tired of all the neat little problems arising on the
>>way... my last one was a case-sensitivity problem. I had elements in my
>>schema with lower-case names (e.g. <xsd:element name="foobar"
>>type="xsd:string"/>) and Castor generated Foobar.class. The web service
>>client got an answer with the element "foobar", and so could not find
>>the appropriate deserializer. I changed all the names to have the first
>>character upper case, and everything works smooth now.
>>(I hope this is the right way to do this)
>>
>>regards
>>MIke
>>
>>Anne Thomas Manes schrieb:
>>
>>>If you're using document/literal, then you won't get an operation name
>>>unless you define one. I sugesst you use the document/literal wrapped
>>>convention, in which you wrap your input parameter with an element
>>>that has the same name as your operation.
>>>
>>>Anne
>>>
>>>On 5/12/05, Mike Haller <Mi...@innovations.de> wrote:
>>>
>>>
>>>>I changed a lot of WSDL and WSDD stuff, so now I get
>>>>
>>>><soapenv:Body>
>>>> <myparameter xsi:nil="true" xmlns=""/>
>>>></soapenv:Body>
>>>>
>>>>still missing the operation name itself.
>>>>The client send the wrong SOAP request. Where do I have to tell the
>>>>client (generated with wsdl2java) that he needs to include the operation
>>>>name?
>>>>
>>>>I think it should be something like this:
>>>>
>>>><soapenv:Body>
>>>> <myOperation>
>>>> <myParameter xsi:nil="true" xmlns=""/>
>>>> </myOperation>
>>>></soapenv:Body>
>>>>
>>>>
>>>>Mike Haller schrieb:
>>>>
>>>>
>>>>>Hi,
>>>>>
>>>>>i've got the following exception:
>>>>>
>>>>>--------------------------------
>>>>>AxisFault
>>>>>faultCode: {http://xml.apache.org/axis/}Client
>>>>>faultSubcode:
>>>>>faultString: No such operation 'in0'
>>>>>faultActor:
>>>>>faultNode:
>>>>>faultDetail:
>>>>> {http://xml.apache.org/axis/}stackTrace:No such operation 'in0'
>>>>> at
>>>>>org.apache.axis.providers.java.RPCProvider.processMessage(RPCProvider.java:179)
>>>>>
>>>>> at
>>>>>org.apache.axis.providers.java.JavaProvider.invoke(JavaProvider.java:319)
>>>>>...
>>>>>--------------------------------
>>>>>
>>>>>However, the SOAP request seems to look like this (the output comes from
>>>>>one custom handler):
>>>>>
>>>>>--------------------------------
>>>>><?xml version="1.0" encoding="UTF-8"?>
>>>>><soapenv:Envelope
>>>>>xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
>>>>>xmlns:xsd="http://www.w3.org/2001/XMLSchema"
>>>>>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body>
>>>>><in0 xsi:nil="true" xmlns="myns1"/></soapenv:Body></soapenv:Envelope>
>>>>>--------------------------------
>>>>>
>>>>>The output of msgContext.getOperationDesc() returns the correct method
>>>>>name, which is completely missing in the above soap message. I'm
>>>>>wondering where the problem lies and can't find it.
>>>>>
>>>>>Perhaps someone can direct me into the right direction?
>>>>>
>>>>>regards
>>>>>MIke
>>>>>
>>>>
>>>>
>>
Re: No such operation 'in0'
Posted by Anne Thomas Manes <at...@gmail.com>.
rpc/literal and wrapped document/literal may look identical on the
wire if you define your doc/literal schema as
elementFormDefault="unqualified". If you define the schema as
elementFormDefault="qualified", then the parameter elements will be
namespace qualified, and the messages won't be quite the same.
The major difference between rpc/literal and wrapped doc/literal is
that with rpc/literal you do not have a schema of the contents of the
<soap:Body>, and with wrapped doc/literal you do have a schema. When
using rpc/literal, you don't define the message element, you only
define the element types, and the SOAP engine automatically builds the
message structure based on the type definitions. You can validate the
message using a schema, but the validation routine must understand the
RPC generation conventions, so it's not quite as straightforward as
when using doc/literal.
Another important difference is that .NET supports wrapped doc/literal
(by default), but it does not support rpc/literal.
rpc/encoded is a significantly different creature than rpc/literal. In
this case, the SOAP engine constructs the message not based on the
schema definition, but based on the SOAP encoding model. Schema
validation typically doesn't work.
Anne
On 5/12/05, Mike Haller <Mi...@innovations.de> wrote:
> Thanks Anne!
>
> I changed operation style to "wrapped" in the server-config.wsdd
> It added an additional element between the parameter and the soap body
> element. It's working fine now! :-)
>
> @All
> But - what's the difference to RPC-style then?
>
> However, the I kept struggling with Axis+Castor+Serializer the last few
> hours and am very tired of all the neat little problems arising on the
> way... my last one was a case-sensitivity problem. I had elements in my
> schema with lower-case names (e.g. <xsd:element name="foobar"
> type="xsd:string"/>) and Castor generated Foobar.class. The web service
> client got an answer with the element "foobar", and so could not find
> the appropriate deserializer. I changed all the names to have the first
> character upper case, and everything works smooth now.
> (I hope this is the right way to do this)
>
> regards
> MIke
>
> Anne Thomas Manes schrieb:
> > If you're using document/literal, then you won't get an operation name
> > unless you define one. I sugesst you use the document/literal wrapped
> > convention, in which you wrap your input parameter with an element
> > that has the same name as your operation.
> >
> > Anne
> >
> > On 5/12/05, Mike Haller <Mi...@innovations.de> wrote:
> >
> >>I changed a lot of WSDL and WSDD stuff, so now I get
> >>
> >><soapenv:Body>
> >> <myparameter xsi:nil="true" xmlns=""/>
> >></soapenv:Body>
> >>
> >>still missing the operation name itself.
> >>The client send the wrong SOAP request. Where do I have to tell the
> >>client (generated with wsdl2java) that he needs to include the operation
> >>name?
> >>
> >>I think it should be something like this:
> >>
> >><soapenv:Body>
> >> <myOperation>
> >> <myParameter xsi:nil="true" xmlns=""/>
> >> </myOperation>
> >></soapenv:Body>
> >>
> >>
> >>Mike Haller schrieb:
> >>
> >>>Hi,
> >>>
> >>>i've got the following exception:
> >>>
> >>>--------------------------------
> >>>AxisFault
> >>> faultCode: {http://xml.apache.org/axis/}Client
> >>> faultSubcode:
> >>> faultString: No such operation 'in0'
> >>> faultActor:
> >>> faultNode:
> >>> faultDetail:
> >>> {http://xml.apache.org/axis/}stackTrace:No such operation 'in0'
> >>> at
> >>>org.apache.axis.providers.java.RPCProvider.processMessage(RPCProvider.java:179)
> >>>
> >>> at
> >>>org.apache.axis.providers.java.JavaProvider.invoke(JavaProvider.java:319)
> >>>...
> >>>--------------------------------
> >>>
> >>>However, the SOAP request seems to look like this (the output comes from
> >>>one custom handler):
> >>>
> >>>--------------------------------
> >>><?xml version="1.0" encoding="UTF-8"?>
> >>><soapenv:Envelope
> >>>xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
> >>>xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> >>>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body>
> >>><in0 xsi:nil="true" xmlns="myns1"/></soapenv:Body></soapenv:Envelope>
> >>>--------------------------------
> >>>
> >>>The output of msgContext.getOperationDesc() returns the correct method
> >>>name, which is completely missing in the above soap message. I'm
> >>>wondering where the problem lies and can't find it.
> >>>
> >>>Perhaps someone can direct me into the right direction?
> >>>
> >>>regards
> >>>MIke
> >>>
> >>
> >>
>
>
Re: No such operation 'in0'
Posted by Mike Haller <Mi...@Innovations.de>.
Thanks Anne!
I changed operation style to "wrapped" in the server-config.wsdd
It added an additional element between the parameter and the soap body
element. It's working fine now! :-)
@All
But - what's the difference to RPC-style then?
However, the I kept struggling with Axis+Castor+Serializer the last few
hours and am very tired of all the neat little problems arising on the
way... my last one was a case-sensitivity problem. I had elements in my
schema with lower-case names (e.g. <xsd:element name="foobar"
type="xsd:string"/>) and Castor generated Foobar.class. The web service
client got an answer with the element "foobar", and so could not find
the appropriate deserializer. I changed all the names to have the first
character upper case, and everything works smooth now.
(I hope this is the right way to do this)
regards
MIke
Anne Thomas Manes schrieb:
> If you're using document/literal, then you won't get an operation name
> unless you define one. I sugesst you use the document/literal wrapped
> convention, in which you wrap your input parameter with an element
> that has the same name as your operation.
>
> Anne
>
> On 5/12/05, Mike Haller <Mi...@innovations.de> wrote:
>
>>I changed a lot of WSDL and WSDD stuff, so now I get
>>
>><soapenv:Body>
>> <myparameter xsi:nil="true" xmlns=""/>
>></soapenv:Body>
>>
>>still missing the operation name itself.
>>The client send the wrong SOAP request. Where do I have to tell the
>>client (generated with wsdl2java) that he needs to include the operation
>>name?
>>
>>I think it should be something like this:
>>
>><soapenv:Body>
>> <myOperation>
>> <myParameter xsi:nil="true" xmlns=""/>
>> </myOperation>
>></soapenv:Body>
>>
>>
>>Mike Haller schrieb:
>>
>>>Hi,
>>>
>>>i've got the following exception:
>>>
>>>--------------------------------
>>>AxisFault
>>> faultCode: {http://xml.apache.org/axis/}Client
>>> faultSubcode:
>>> faultString: No such operation 'in0'
>>> faultActor:
>>> faultNode:
>>> faultDetail:
>>> {http://xml.apache.org/axis/}stackTrace:No such operation 'in0'
>>> at
>>>org.apache.axis.providers.java.RPCProvider.processMessage(RPCProvider.java:179)
>>>
>>> at
>>>org.apache.axis.providers.java.JavaProvider.invoke(JavaProvider.java:319)
>>>...
>>>--------------------------------
>>>
>>>However, the SOAP request seems to look like this (the output comes from
>>>one custom handler):
>>>
>>>--------------------------------
>>><?xml version="1.0" encoding="UTF-8"?>
>>><soapenv:Envelope
>>>xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
>>>xmlns:xsd="http://www.w3.org/2001/XMLSchema"
>>>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body>
>>><in0 xsi:nil="true" xmlns="myns1"/></soapenv:Body></soapenv:Envelope>
>>>--------------------------------
>>>
>>>The output of msgContext.getOperationDesc() returns the correct method
>>>name, which is completely missing in the above soap message. I'm
>>>wondering where the problem lies and can't find it.
>>>
>>>Perhaps someone can direct me into the right direction?
>>>
>>>regards
>>>MIke
>>>
>>
>>
Re: No such operation 'in0'
Posted by Anne Thomas Manes <at...@gmail.com>.
If you're using document/literal, then you won't get an operation name
unless you define one. I sugesst you use the document/literal wrapped
convention, in which you wrap your input parameter with an element
that has the same name as your operation.
Anne
On 5/12/05, Mike Haller <Mi...@innovations.de> wrote:
> I changed a lot of WSDL and WSDD stuff, so now I get
>
> <soapenv:Body>
> <myparameter xsi:nil="true" xmlns=""/>
> </soapenv:Body>
>
> still missing the operation name itself.
> The client send the wrong SOAP request. Where do I have to tell the
> client (generated with wsdl2java) that he needs to include the operation
> name?
>
> I think it should be something like this:
>
> <soapenv:Body>
> <myOperation>
> <myParameter xsi:nil="true" xmlns=""/>
> </myOperation>
> </soapenv:Body>
>
>
> Mike Haller schrieb:
> > Hi,
> >
> > i've got the following exception:
> >
> > --------------------------------
> > AxisFault
> > faultCode: {http://xml.apache.org/axis/}Client
> > faultSubcode:
> > faultString: No such operation 'in0'
> > faultActor:
> > faultNode:
> > faultDetail:
> > {http://xml.apache.org/axis/}stackTrace:No such operation 'in0'
> > at
> > org.apache.axis.providers.java.RPCProvider.processMessage(RPCProvider.java:179)
> >
> > at
> > org.apache.axis.providers.java.JavaProvider.invoke(JavaProvider.java:319)
> > ...
> > --------------------------------
> >
> > However, the SOAP request seems to look like this (the output comes from
> > one custom handler):
> >
> > --------------------------------
> > <?xml version="1.0" encoding="UTF-8"?>
> > <soapenv:Envelope
> > xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
> > xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body>
> > <in0 xsi:nil="true" xmlns="myns1"/></soapenv:Body></soapenv:Envelope>
> > --------------------------------
> >
> > The output of msgContext.getOperationDesc() returns the correct method
> > name, which is completely missing in the above soap message. I'm
> > wondering where the problem lies and can't find it.
> >
> > Perhaps someone can direct me into the right direction?
> >
> > regards
> > MIke
> >
>
>
Re: No such operation 'in0'
Posted by Mike Haller <Mi...@Innovations.de>.
I changed a lot of WSDL and WSDD stuff, so now I get
<soapenv:Body>
<myparameter xsi:nil="true" xmlns=""/>
</soapenv:Body>
still missing the operation name itself.
The client send the wrong SOAP request. Where do I have to tell the
client (generated with wsdl2java) that he needs to include the operation
name?
I think it should be something like this:
<soapenv:Body>
<myOperation>
<myParameter xsi:nil="true" xmlns=""/>
</myOperation>
</soapenv:Body>
Mike Haller schrieb:
> Hi,
>
> i've got the following exception:
>
> --------------------------------
> AxisFault
> faultCode: {http://xml.apache.org/axis/}Client
> faultSubcode:
> faultString: No such operation 'in0'
> faultActor:
> faultNode:
> faultDetail:
> {http://xml.apache.org/axis/}stackTrace:No such operation 'in0'
> at
> org.apache.axis.providers.java.RPCProvider.processMessage(RPCProvider.java:179)
>
> at
> org.apache.axis.providers.java.JavaProvider.invoke(JavaProvider.java:319)
> ...
> --------------------------------
>
> However, the SOAP request seems to look like this (the output comes from
> one custom handler):
>
> --------------------------------
> <?xml version="1.0" encoding="UTF-8"?>
> <soapenv:Envelope
> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body>
> <in0 xsi:nil="true" xmlns="myns1"/></soapenv:Body></soapenv:Envelope>
> --------------------------------
>
> The output of msgContext.getOperationDesc() returns the correct method
> name, which is completely missing in the above soap message. I'm
> wondering where the problem lies and can't find it.
>
> Perhaps someone can direct me into the right direction?
>
> regards
> MIke
>