Hi John,
thanks for your answer. Your proposal was my initial thought, but the
problem is that ParamConverter in Apache CXF works considering every single
element in a List, not the List as a whole, meaning that rawType in
ApacheCXF will never be a List but, in the case of List, a String.
In
Hi Diego
Hope you've had enough time to recover before a new working day :-)
Here are the reasons I won't agree with it before either JAX-RS 2.1 or
future TCK will force CXF to do it:
1. Minor:
IMHO it is wrong to expect a custom param converter to guarantee it
parses all of the query
Hi,
So just a thought. Why can't this be accomplished today with a
ParamConverter and a custom annotation?
Looking at the samples repo -
https://github.com/javaee-samples/javaee7-samples/blob/master/jaxrs/paramconverter/src/main/java/org/javaee7/jaxrs/paramconverter/MyConverterProvider.java#L18
I have to say that I don't understand your objection (in my defense: here
is almost 1:00 AM... :-) ), could you please clarify?
Probably the best solution will be to have a kinda
MultipleParamConverter interface in JAX-RS 2.1 specs defining two
methods:
T fromStrings(String[] values);
String[]
I can't agree to this. So a user registering a custom List provider
breaks the runtime ensuring the service code sees all the multiple values.
I can try and work with spec leads on clarifying it for JAX-RS 2.1.
Thanks, Sergey
On 23/10/16 23:27, Diego Ruotolo wrote:
Hi,
- when using
Hi,
- when using multiple-value parameters passed in the URI in an HTTP
>> compliant-way (PARAM=V1=V2=V3), the ParamConverter takes only
>> the first value, hence if the ParamConverter builds a list, it will be a
>> list of only one value
>>
>
> Are you saying this loses V2 & V3 ?
>
Yes, in this
Hi
Thanks for this investigation
On 23/10/16 22:57, Diego Ruotolo wrote:
Hi,
I investigated the behaviour of Jersey, and it acts like following.
Use case: a resource method that has a List as query parameter
- the method getConverter() of ParamConverterProvider interfaces receives
as
Hi,
I investigated the behaviour of Jersey, and it acts like following.
Use case: a resource method that has a List as query parameter
- the method getConverter() of ParamConverterProvider interfaces receives
as arguments: List as rawType, List as type, @QueryParameter as
annotations
- the
Hi
In the JAX-RS users thread which I referred to below I did ask about and
I don't think I got a +1 from one the spec leads on having
ParamConverterProvider supporting List, please check the archives.
And as I said IMHO the converters should not deal with interpreting for
ex the whole query
Hi Sergey,
I think you are definitively right when you say you don't want to introduce
a CXF specific extension at a standard JAX-RS interface level. But taking a
look at the JAX-RS specs it is not specified that ParamConverter should
handle just single values in a collection and not the whole
Hi Diego
But that would introduce a CXF specific extension at a standard JAX-RS
interface level. In general I'm quite open to adding new extensions but
I'd rather not to in this case...Besides, IMHO, it really should be the
job for the JAX-RS runtime, to parse the multivalued query/matrix
Hi Sergey,
thanks for your answer.
I think a good solution could be to pass the ParamConverter a string
containing all the values of a multi-valued query parameter, and let the
user build the collection object.
So, if I have a query string like:
MY_PARAM=VALUE_1=BAR_PARAM=VALUE_2, the
Hi
Thanks for this query, let me redirect to the CXF users list.
FYI, CXF JAX-RS runtime prepares a List itself and only expects
ParamConverters if any to convert individual values.
I believe RI (Jersey) will also act the same way - but I may be wrong
now. You can check a "ParamConverter
13 matches
Mail list logo
