cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: Collection jax-rs saga: List<List<Entity>>
Date Tue, 26 Aug 2014 11:31:25 GMT
Hi
On 26/08/14 11:29, Vassilis Virvilis wrote:
> Hi,
>
> I justed tested it and as you said it didn't help me.
>
> I can understand that jax-rs wants to encourage use of wrapper objects
> because that's what makes sense from a REST point of view with resources
> and everything. I am coming from SOAP and RPC world and I am bumping on
> cultural differences. I get that. I really do...
>

Let me clarify few more things here.
In JAX-RS you can definitely have

@POST
public void post(List<List<Entity>> complexList) {}

Note it has no a JAX-RS annotation such as @QueryParam/@FormParam/etc 
attached to it meaning a 'complexList' represents the complete HTTP 
request body. Such types will not be supported OOB but a custom MBR will 
do just fine.

Now, when we move to

@POST
public void post(@QueryParam("a") List<List<Entity>> complexList) {}

it's becoming undefined because it can not be generalized at the spec 
level. The method parameters marked with @QueryParam/etc are pointing to 
simple parameters found in URI or headers or in case of @FormParam - in 
form payloads.

> As I see it (and I may be wrong / ignorant here) is that section 3.2 has
> the four rules but doesn't say anything about ParamConverters leaving
> the door open for all kind of objects and representations. My objects
> don't have a String Constructor or fromString() but CXF doesn't complain
> about that. It tries with the ParamConverter. So in my mind it is a bit
> inconsistent and contra intuitive the fact that the ParamConverter will
> be called with inner argument in some cases and with the inner/inner
> argument in others.
>
Right, indeed, ParamConverter could've handled (@QueryParam("a") 
List<List<Entity>> complexList), but on the other hand it is probably 
the right thing to do, generally speaking, not to support such complex 
signatures to represent the individual parameter values, because the 
simple single parameter value typically found in URI or headers can not 
be conceptually mapped to List of complex entities...

You are always welcome to open a JAX-RS enhancement request though. I 
agree that purely from a techical point of view, ParamConverter could've 
handled such signatures

> But this is the spec and its interpretation. I can't do anything about
> it. I will probably create a wrapper object and move on to the next and
> final roadblock which is sending back maps of...
>
>      to be continued :-).
>
Sounds good :-)
Sergey
> Thanks for all your help. It is really appreciated.
>
>   Vassilis
>
>
> On 08/26/2014 11:38 AM, Sergey Beryozkin wrote:
>> Hi,
>> On 26/08/14 09:08, Vassilis Virvilis wrote:
>>> Hi,
>>>
>>> I just checked
>>> https://java.net/projects/jax-rs-spec/lists/jsr339-experts/archive/2014-08/message/33
>>>
>>>
>>> and the thread. As you said it is not supported officially from jax-rs
>>> spec (but looks like a meaningful extension nevertheless).
>>
>> See, as I said there, there's a 'conflict' between the use of deeply
>> nested collections and the specification having to describe what does it
>> mean to have List<List..> for simple JAX-RS parameters. @FormParam is an
>> exception among other simple parameters anyway, it refers to a message
>> body part, as opposed to QueryParam/HeaderParam/etc, for example,
>> List<List...> can not describe a standard simple repetitive query
>> parameter. As such it's better for complex representations of @FormParam
>> be taken care of by MBW or wrappers + ParamConverter.
>>
>>> Anyway thanks
>>> for the effort to represent my case to jax-rs mailing lists. I tried to
>>> subscribe to that mailing list and it is not immediately obvious how
>>> to ,
>>> do it. Probably I have to register in to that java.net site.
>>>
>>> I will try to build cxf now (Never done it before) and I will try to see
>>> why the patch you created won't help me (passing the generic type).
>>>
>> Building is easy, pull the source and then do 'mvn install -Pfastinstall'
>>
>> Thanks, Sergey
>>
>>> Thanks
>>>
>>>      Vassilis
>>>
>>> On 08/25/2014 08:34 PM, Sergey Beryozkin wrote:
>>>> Hi Again
>>>>
>>>> I've got the confirmation that deeply nested collections are not
>>>> supported as JAX-RS parameters (unless they represent the message body
>>>> to be taken care of by MessageBodyReader)
>>>>
>>>> Please check jaxrs archives.
>>>> Note, I've updated the code to pass the generic type parameter to param
>>>> converters but it won;t help per se in your case
>>>> Thanks, Sergey
>>>> On 25/08/14 17:56, Sergey Beryozkin wrote:
>>>>> Hi
>>>>> On 25/08/14 15:19, Vassilis Virvilis wrote:
>>>>>> Hi,
>>>>>>
>>>>>> MultivaluedMap worked. I can use this as a workaround to continue
my
>>>>>> porting work. Really thanks for the hint.
>>>>>>
>>>>> np, good it worked
>>>>>> Of course it is still preferable to have proper @FormParam support
>>>>>> for
>>>>>> List<List<Entity>> but at least I continue down the path...
>>>>>>
>>>>> I'm actually not sure now a code with deeply nested explicit
>>>>> collections
>>>>> is expected to be a JAX-RS portable code.
>>>>>
>>>>> Effectively, when we have
>>>>> @FormParam List<List<Entity>>
>>>>>
>>>>> We have the spec saying nothing about such combinations.
>>>>> Explicit collections with simple beans (@FormParam List<Entity>)
>>>>> is covered, what happens next.
>>>>>
>>>>> The 'depth' of the collection type can always be controlled by
>>>>> wrapping...
>>>>>
>>>>> I'd really like to encourage you to ask a question on jaxrs users
>>>>> list.
>>>>> Please ask if
>>>>>
>>>>> @POST
>>>>> form(@FormParam("a") List<List<Entity>> a)
>>>>>
>>>>> can be handled by ParamConverterProvider...
>>>>>
>>>>> I'll ask separately too
>>>>>
>>>>> Cheers, Sergey
>>>>>
>>>>>>
>>>>>>     Vassilis
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 08/25/2014 01:44 PM, Sergey Beryozkin wrote:
>>>>>>> Hi
>>>>>>> On 25/08/14 11:00, Vassilis Virvilis wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> ok that makes sense for MessageBodyReader. However I can't
remove
>>>>>>>> @FormParam because I have multiple parameter to pass. But
if I run
>>>>>>>> out
>>>>>>>> of all other options I may manually parse the document and
all the
>>>>>>>> parameters. So this is a viable solution. I think...
>>>>>>>>
>>>>>>> MultivaluedMap is a spec compliant way to capture multiple form
>>>>>>> parameters.
>>>>>>>> Can you also comment on the List<List<Entity>>
issue? What is the
>>>>>>>> expected payload in the form parameters for CXF to parse
correctly
>>>>>>>> or at
>>>>>>>> least delegate parsing to ParamConverter?
>>>>>>>>
>>>>>>> I see that the runtime does not pass a generic type of the given
>>>>>>> parameter to ParamConverterProvider, I'll fix it, so you'd have
>>>>>>> List<List<Entity>> working with the ParamConverterProvider
too.
>>>>>>> Thanks, Sergey
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>>     Vassilis
>>>>>>>>
>>>>>>>>
>>>>>>>> On 08/25/2014 12:34 PM, Sergey Beryozkin wrote:
>>>>>>>>> Hi Vassilis
>>>>>>>>> For MessageBodyReader to work you need to remove a @FormParam
>>>>>>>>> annotation, give it a try please
>>>>>>>>> Cheers, Sergey
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 25/08/14 09:33, Vassilis Virvilis wrote:
>>>>>>>>>> Hi Sergey, everybody
>>>>>>>>>>
>>>>>>>>>> I managed to do some work on Resty-GWT
>>>>>>>>>>
>>>>>>>>>> https://github.com/resty-gwt/resty-gwt/issues/195
>>>>>>>>>> https://github.com/resty-gwt/resty-gwt/pull/196
>>>>>>>>>>
>>>>>>>>>> With the patches (not yet applied) I can transmit
and receive
>>>>>>>>>> plain
>>>>>>>>>> List<Entity> with no wrapper object.
>>>>>>>>>>
>>>>>>>>>> Now I am hitting another roadblock and any input,
especially from
>>>>>>>>>> you
>>>>>>>>>> Sergey is highly appreciated. I am trying to transmit
a list of
>>>>>>>>>> lists
>>>>>>>>>> List<List<Entity>>. With my patches applied
RestyGWT sends
>>>>>>>>>> something
>>>>>>>>>> like this in @FormParam
>>>>>>>>>>
>>>>>>>>>> public void test(@FormParam("lists-of-entities")
>>>>>>>>>> List<List<Entity>>);
>>>>>>>>>>
>>>>>>>>>> the play load is
>>>>>>>>>> lists-of-entities:[...json representation of List<Entity>
as json
>>>>>>>>>> array ]
>>>>>>>>>> lists-of-entities:[...json representation of List<Entity>
as json
>>>>>>>>>> array ]
>>>>>>>>>>
>>>>>>>>>> Now I am expecting my ParamConverter to be called
with
>>>>>>>>>> List<Entity>
>>>>>>>>>> type
>>>>>>>>>> but it is called with plain Entity and it fails because
it
>>>>>>>>>> tries to
>>>>>>>>>> deserialize an array. Now why it is doing that? From
my
>>>>>>>>>> interpretation
>>>>>>>>>> of the standard is that it should break the outer
list to
>>>>>>>>>> multiple
>>>>>>>>>> parameters with the same name. How it can expect
to do the same
>>>>>>>>>> with
>>>>>>>>>> the
>>>>>>>>>> inner list? There is not enough information to assemble
it back.
>>>>>>>>>>
>>>>>>>>>> I tried to register also a MessageBodyReader but
that also
>>>>>>>>>> failed.
>>>>>>>>>> Its
>>>>>>>>>> functions are not called at all, while at the same
time
>>>>>>>>>> MessageBodyWriter is getting called and it works
all right. Note
>>>>>>>>>> that I
>>>>>>>>>> have one class implementing ParamConverterProvider,
>>>>>>>>>> MessageBodyWriter,
>>>>>>>>>> MessageBodyReader. Any ideas why it is not working?
>>>>>>>>>>
>>>>>>>>>>     Vassilis
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>


Mime
View raw message