Okay idea:
a) Can you apply your evil reflection hack so we get valid JSON output in
the short term - maintaining REST API 1.0 JSON Output
b) Can we upgrade Jackson as part of the code-sprint - producing a REST API
1.0.1 JSON Output
--
Jody Garnett
On 2 February 2017 at 23:39, Torben Barsballe <[email protected]>
wrote:
> The main reason we appear to be using Jettison is that it directly
> integrates with XStream, which means we have very little custom code for
> JSON, and just use the XML-based code, relying on XStream/Jettison for the
> conversion.
> Ultimately, changing to a different JSON library while maintaining current
> functionality would either involve forking Jettison, or tying in a new
> library with the existing REST API, which would likely be an immense amount
> of work.
>
> There is an alternate Jettison library that is supported by XStream, but
> it does not support deserialization, which is required for the REST api,
> and I don't think it is any better supported than the current one.
>
> Torben
>
> On Thu, Feb 2, 2017 at 9:36 PM, Ben Caradoc-Davies <[email protected]>
> wrote:
>
>> Torben,
>>
>> you mentioned in the pull request that the jettison project appears to be
>> poorly documented, poorly supported, and has not had many recent commits.
>> This suggests that, even if we upgrade to a later version of jettison, we
>> will be left a dependency that might cause further problems in the future.
>> Are there any comparable libraries with better support? If so, how hard
>> would it be to migrate? If we are going to break the API anyway, this would
>> be an ideal time to switch implementation.
>>
>> Kind regards,
>> Ben.
>>
>>
>> On 01/02/17 07:18, Torben Barsballe wrote:
>>
>>> Proposal created here: https://github.com/geoserver/g
>>> eoserver/wiki/GSIP-156
>>>
>>> Torben
>>>
>>> On Tue, Jan 31, 2017 at 10:49 AM, Torben Barsballe <
>>> [email protected]> wrote:
>>>
>>> Slight point of clarification - currently lists containing a mix of nulls
>>>> and objects are coming out as invalid JSON. The only observed place
>>>> where
>>>> this happens is with LayerGroups (specifically the style list, where
>>>> null
>>>> represents "use the default style").
>>>>
>>>> Since the API-breaking fix is definitely not backportable, it might make
>>>> sense to apply the alternative fix to the current stable branch
>>>> (although I
>>>> am not especially happy having that level of reflection anywhere in the
>>>> codebase)
>>>>
>>>> I am happy to make a proposal for the "proper", API-breaking fix.
>>>>
>>>> Torben
>>>>
>>>> On Tue, Jan 31, 2017 at 10:38 AM, Jody Garnett <[email protected]>
>>>> wrote:
>>>>
>>>> Taking this pull request discussion to the email list as it has some
>>>>> strategic consequences - so we probably need a proposal.
>>>>>
>>>>> * https://github.com/geoserver/geoserver/pull/2072
>>>>> * https://osgeo-org.atlassian.net/browse/GEOS-7873
>>>>>
>>>>> Torben has two "fixes":
>>>>> - a good fix, updating the version of jettison - that breaks REST API
>>>>> compatibility (sigh)
>>>>> - a bad fix, using reflection to hack - produces valid JSON code but a
>>>>> brittle fix
>>>>>
>>>>> What would we like to do? Currently empty lists are coming out as
>>>>> invalid
>>>>> JSON.
>>>>> --
>>>>> Jody Garnett
>>>>>
>>>>> ------------------------------------------------------------
>>>>> ------------------
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>>> _______________________________________________
>>>>> Geoserver-devel mailing list
>>>>> [email protected]
>>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>
>>>
>>>
>>> _______________________________________________
>>> Geoserver-devel mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>
>>>
>> --
>> Ben Caradoc-Davies <[email protected]>
>> Director
>> Transient Software Limited <http://transient.nz/>
>> New Zealand
>>
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
