users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Re: JSON-P Support

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Wed, 23 Jan 2013 16:40:34 +0000

On 23/01/13 16:25, Santiago Pericas-Geertsen wrote:
>
> On Jan 23, 2013, at 11:14 AM, Sergey Beryozkin<sberyozkin_at_talend.com> wrote:
>
>> I may've misunderstood what JSON-P stands for,
>>
>> still seems to be too late; and promoting specific JSON-P types at the spec level definitely does not look right to me
>
> OK, yes I understand, an overloaded term ;)
>
I'm looking at the JSON-P spec and it looks like a nice effort and I
would not mind working with it; but I'd be very concerned at this stage
if the compliance of CXF were affected unless it would actually
implement JSON-P, I also agree with Bill re EE profile - may be even
that can be postponed till 2.1 up until JSON-P gets the higher
visibility and possibly some errata fixed given that it is a new spec too.

Thanks, Sergey

> -- Santiago
>
>>
>> Sergey
>> On 23/01/13 15:57, Sergey Beryozkin wrote:
>>> On 23/01/13 15:48, Santiago Pericas-Geertsen wrote:
>>>> Hello Experts,
>>>>
>>>> We had an outstanding AI to look at the new JSON-P [1] API for any
>>>> potential integration points. After some discussions with Jitu (the
>>>> JSON-P lead), we'd like to propose adding support for the following
>>>> types:
>>>>
>>>> (1) JsonStructure, JsonObject and JsonArray as entity parameters and
>>>> return types for JAX-RS resource methods. Note that a JsonStructure is
>>>> either a JsonObject or a JsonArray (a partition). If an entity param is
>>>> JsonObject and an array is received (or vice-versa) an exception will be
>>>> thrown.
>>>>
>>>> (2) We will _not_ provide any native support for JsonParser,
>>>> JsonGenerator, JsonReader or JsonWriter. All these are usable with
>>>> either an InputStream entity parameter or a StreamingOutput return type.
>>>>
>>>> Unless there are any strong objections, I will go ahead an update the
>>>> spec to add support for the types in (1).
>>> That is a pretty strong commitment to an approach considered to be less
>>> effective than CORS, so unless there are really strong reasons for
>>> adding this and given that we are really down to doing the cosmetic
>>> changes + client security configuration, I'm -1 on it.
>>>
>>> Thanks, Sergey
>>>>
>>>> -- Santiago
>>>>
>>>> [1] http://jcp.org/en/jsr/detail?id=353
>>>
>>>
>