You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Scott Anderson <sc...@gmail.com> on 2008/03/02 20:28:52 UTC

CXF confuses operations

If I create two operations with different messages, but which have the
parameters of the same name (which are unwrapped), CXF is unable to
distinguish which operation I was referring to, despite it being specified
in the POST URL. Is there any good solution to this, other than using GET or
changing the parameter names?
Thanks
Scott

Re: CXF confuses operations

Posted by Glen Mazza <gl...@gmail.com>.
Scott, I don't know, but I would recommend starting a new thread for this
(different) question--changing the topic under a non-relevant subject title
might reduce the number of responses you get.

Glen


Scott Anderson-5 wrote:
> 
> Is it possible to encode an enum for a parameter in a GET request? For
> this
> particular instance, I'm doing a simple query that takes an enum object,
> but
> CXF doesn't seem to know how to convert the string to an enum (it throws a
> class cast exception) unless I use POST.
> 
> Thanks,
> Scott
> 
> On Mon, Mar 3, 2008 at 11:25 PM, Glen Mazza <gl...@verizon.net>
> wrote:
> 
>> That's not WS-I Basic Profile compliant, because for many web service
>> stacks, it is the parameters that are used to determine which operation
>> is called.    If you run wsdl2java with the validation option you should
>> see a warning to that effect.  Metro also would complain about that,
>> although they provide an override option accepting that I believe.
>>
>> Glen
>>
>> Am Sonntag, den 02.03.2008, 14:28 -0500 schrieb Scott Anderson:
>> > If I create two operations with different messages, but which have the
>> > parameters of the same name (which are unwrapped), CXF is unable to
>> > distinguish which operation I was referring to, despite it being
>> specified
>> > in the POST URL. Is there any good solution to this, other than using
>> GET or
>> > changing the parameter names?
>> > Thanks
>> > Scott
>>
>>
> 
> 

-- 
View this message in context: http://www.nabble.com/CXF-confuses-operations-tp15791947p15839329.html
Sent from the cxf-user mailing list archive at Nabble.com.


Re: CXF confuses operations

Posted by Scott Anderson <sc...@gmail.com>.
Is it possible to encode an enum for a parameter in a GET request? For this
particular instance, I'm doing a simple query that takes an enum object, but
CXF doesn't seem to know how to convert the string to an enum (it throws a
class cast exception) unless I use POST.

Thanks,
Scott

On Mon, Mar 3, 2008 at 11:25 PM, Glen Mazza <gl...@verizon.net> wrote:

> That's not WS-I Basic Profile compliant, because for many web service
> stacks, it is the parameters that are used to determine which operation
> is called.    If you run wsdl2java with the validation option you should
> see a warning to that effect.  Metro also would complain about that,
> although they provide an override option accepting that I believe.
>
> Glen
>
> Am Sonntag, den 02.03.2008, 14:28 -0500 schrieb Scott Anderson:
> > If I create two operations with different messages, but which have the
> > parameters of the same name (which are unwrapped), CXF is unable to
> > distinguish which operation I was referring to, despite it being
> specified
> > in the POST URL. Is there any good solution to this, other than using
> GET or
> > changing the parameter names?
> > Thanks
> > Scott
>
>

Re: CXF confuses operations

Posted by Glen Mazza <gl...@verizon.net>.
That's not WS-I Basic Profile compliant, because for many web service
stacks, it is the parameters that are used to determine which operation
is called.    If you run wsdl2java with the validation option you should
see a warning to that effect.  Metro also would complain about that,
although they provide an override option accepting that I believe.

Glen

Am Sonntag, den 02.03.2008, 14:28 -0500 schrieb Scott Anderson:
> If I create two operations with different messages, but which have the
> parameters of the same name (which are unwrapped), CXF is unable to
> distinguish which operation I was referring to, despite it being specified
> in the POST URL. Is there any good solution to this, other than using GET or
> changing the parameter names?
> Thanks
> Scott