[Geoserver-devel] jettison upgrade proposed - breaks rest api

GeoServer GeoServer Developer
1

Taking this pull request discussion to the email list as it has some strategic consequences - so we probably need a proposal.

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

2

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 <jody.garnett@anonymised.com> wrote:

Taking this pull request discussion to the email list as it has some strategic consequences - so we probably need a proposal.

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
Geoserver-devel@anonymised.com.366…sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

3

Proposal created here: https://github.com/geoserver/geoserver/wiki/GSIP-156

Torben

···

On Tue, Jan 31, 2017 at 10:49 AM, Torben Barsballe <tbarsballe@anonymised.com> 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 <jody.garnett@anonymised.com> wrote:

Taking this pull request discussion to the email list as it has some strategic consequences - so we probably need a proposal.

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
Geoserver-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

4

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/geoserver/wiki/GSIP-156

Torben

On Tue, Jan 31, 2017 at 10:49 AM, Torben Barsballe <
tbarsballe@anonymised.com> 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 <jody.garnett@anonymised.com>
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
Geoserver-devel@lists.sourceforge.net
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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/&gt;
New Zealand

5

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 <ben@anonymised.com> 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/geoserver/wiki/GSIP-156

Torben

On Tue, Jan 31, 2017 at 10:49 AM, Torben Barsballe <
tbarsballe@anonymised.com39…> 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 <jody.garnett@anonymised.com>
wrote:

Taking this pull request discussion to the email list as it has some
strategic consequences - so we probably need a proposal.

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
Geoserver-devel@anonymised.comrge.net
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
Geoserver-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/>
New Zealand

6

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

···

On 2 February 2017 at 23:39, Torben Barsballe <tbarsballe@anonymised.com> 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

–
Jody Garnett

On Thu, Feb 2, 2017 at 9:36 PM, Ben Caradoc-Davies <ben@anonymised.com> 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/geoserver/wiki/GSIP-156

Torben

On Tue, Jan 31, 2017 at 10:49 AM, Torben Barsballe <
tbarsballe@anonymised.com39…> 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 <jody.garnett@anonymised.com>
wrote:

Taking this pull request discussion to the email list as it has some
strategic consequences - so we probably need a proposal.

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
Geoserver-devel@anonymised.comrge.net
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
Geoserver-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/>
New Zealand

7

Hi Jody,
I like your proposal :slight_smile:

Cheers
Andrea

···

On Fri, Feb 3, 2017 at 4:40 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

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

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
Geoserver-devel@anonymised.com.366…sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–

–
Jody Garnett

On 2 February 2017 at 23:39, Torben Barsballe <tbarsballe@anonymised.com> 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 <ben@anonymised.com> 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/geoserver/wiki/GSIP-156

Torben

On Tue, Jan 31, 2017 at 10:49 AM, Torben Barsballe <
tbarsballe@anonymised.com39…> 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 <jody.garnett@anonymised.com>
wrote:

Taking this pull request discussion to the email list as it has some
strategic consequences - so we probably need a proposal.

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
Geoserver-devel@anonymised.comrge.net
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
Geoserver-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/>
New Zealand

==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313

fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

8

I will add it to the wiki page, trodden has a bug reports already in play GEOS-7873 / GEOS-7771.

···

On 3 February 2017 at 10:05, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi Jody,
I like your proposal :slight_smile:

Cheers
Andrea

–
Jody Garnett

On Fri, Feb 3, 2017 at 4:40 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

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

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
Geoserver-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–

==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313

fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

–
Jody Garnett

On 2 February 2017 at 23:39, Torben Barsballe <tbarsballe@anonymised.com> 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 <ben@anonymised.com191…> 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/geoserver/wiki/GSIP-156

Torben

On Tue, Jan 31, 2017 at 10:49 AM, Torben Barsballe <
tbarsballe@anonymised.com39…> 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 <jody.garnett@anonymised.com>
wrote:

Taking this pull request discussion to the email list as it has some
strategic consequences - so we probably need a proposal.

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
Geoserver-devel@anonymised.comrge.net
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
Geoserver-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/>
New Zealand

9

Evil reflection hack here: https://github.com/geoserver/geoserver/pull/2084 (if anyone wants to review).

Torben

···

On Fri, Feb 3, 2017 at 10:43 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

I will add it to the wiki page, trodden has a bug reports already in play GEOS-7873 / GEOS-7771.

–
Jody Garnett

On 3 February 2017 at 10:05, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi Jody,
I like your proposal :slight_smile:

Cheers
Andrea

On Fri, Feb 3, 2017 at 4:40 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

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

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
Geoserver-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–

==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313

fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

–
Jody Garnett

On 2 February 2017 at 23:39, Torben Barsballe <tbarsballe@anonymised.com> 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 <ben@anonymised.com> 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/geoserver/wiki/GSIP-156

Torben

On Tue, Jan 31, 2017 at 10:49 AM, Torben Barsballe <
tbarsballe@anonymised.com39…> 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 <jody.garnett@anonymised.com>
wrote:

Taking this pull request discussion to the email list as it has some
strategic consequences - so we probably need a proposal.

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
Geoserver-devel@anonymised.comrge.net
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
Geoserver-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/>
New Zealand