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 collection: I
think that both interpretations are valid, but maybe I am missinig

Regarding the use of a @PreMatch filter, I don't think it is possible: I
can't read annotations on a method parameter in a @PreMatch filter since
the server resource is not bound yet, and I can't change parameter values
in a post-match filter since it is impossible to change the URI (by specs).
Furthermore, in a post-match filter the server resource is bound but not
yet "filled" with values.




2016-10-17 16:28 GMT+02:00 Sergey Beryozkin <sberyoz...@gmail.com>:

> 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
> properties.
> What you might want to experiment with is to add a prematch request filter
> which will reset a query string if needed to have List<String> working for
> either a=1&a=2 or a=1,2, etc
> Thanks, Sergey
> On 17/10/16 12:46, Diego Ruotolo wrote:
>> 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&FOO=BAR&MY_PARAM=VALUE_2, the ParamConvert should
>> receive
>> the string MY_PARAM=VALUE_1&MY_PARAM=VALUE_2, and the user should build
>> the
>> collection in in the fromString() method. In this way the user can deal
>> with both the whole collection and its single values.
>> I also suggest this behaviour should be activated through a property in
>> order not to break backward compatibility.
>> What do you think?
>> Thanks,
>> Diego
>> 2016-10-17 11:47 GMT+02:00 Sergey Beryozkin <sberyoz...@gmail.com>:
>> 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 and Collections" thread on the jaxrs
>>> users
>>> list. My understanding there was no any agreement reached.
>>> Cheers, Sergey
>>> On 16/10/16 23:48, Diego Ruotolo wrote:
>>> Hi everybody,
>>>> this is my first post to this mailing list.
>>>> I am using Apache CXF and I have the following problem: I need to read a
>>>> multiple-value query parameter that is written in a
>>>> comma-separated-values (CSV) format, hence non standard HTTP way.
>>>> I know that this will be fixed in versions 3.1.8 and 3.2.0 with the
>>>> contextual property "parse.query.value.as.collection", as written here:
>>>> https://issues.apache.org/jira/browse/CXF-6941
>>>> but the above solution works for ALL query parameters, I want to be
>>>> selective, for instance I just want query parameters annotated with
>>>> @MyAnnotation to be parsed as CSV collection, other query parameters may
>>>> accept commas as a value.
>>>> Therefore I've written a ParamConverter provided by a
>>>> ParamConverterProvider: the latter reads the annotation and returns the
>>>> appriopriate ParamConverter that converts a String into a List. But this
>>>> is not working since the returned List is used as first element of the
>>>> linked method parameter, so in the end I have a List of List.
>>>> Example:
>>>> Query parameter: MY_PARAM=VALUE_1,VALUE_2,VALUE_3
>>>> Method parameter: List<?> myParam; // Here I put "?" instead of "String"
>>>> as generic type in order to explain this example
>>>> ParamConverter fromString() method: return
>>>> Arrays.asList(value.split(",")); //returns a List<String>
>>>> Expected result: myParam is a List<String>, a list of 3 elements
>>>> (VALUE_1, VALUE_2, VALUE_3)
>>>> Actual result: myParam is a List<List<String>>, a list with one element,
>>>> this single element is a list of 3 elements (VALUE_1, VALUE_2, VALUE_3)
>>>> It seems that when used in conjuction with a List (a Collection?) method
>>>> parameter, a ParamConverter works per-element, not for the whole list.
>>>> Is this the correct behaviour? Do you know some work-around that I could
>>>> use without writing an Apache CXF Interceptor (I don't want to be bound
>>>> to an implementation of JAX-RS) ?
>>>> I've noticed that Jersey has a similar issue too:
>>>> https://java.net/jira/browse/JERSEY-2763
>>>> Thanks in advice,
>>>> best regards
>>> --
>>> Sergey Beryozkin
>>> Talend Community Coders
>>> http://coders.talend.com/

Reply via email to