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
