Forgot to clarify that when the runtime sees List (or other collection),
it assumes it is List<SomeClass> 'maximum', i.e, it does not try to deal
with List<T> as if T were possibly some List<...>, etc
So effectively, the fix I did might help in some rare cases, may be when
one has a bean class parameterized, or may be JAX-RS GenericEntity<T>,
though it's a guess only about the latter.
Cheers, Sergey
On 26/08/14 09:38, 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
