I am mostly waiting on spare time to actually do it. I should be able to get it done sometime this week.
···
On Sun, Mar 20, 2016 at 7:27 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
Hi Torben,
not sure if you were still waiting feedback on this one, but the switch from boolean to Boolean
with the getters/setters masking eventual null values looks like a sensible choice to me
Cheers
Andrea
On Thu, Mar 10, 2016 at 10:35 PM, Torben Barsballe <tbarsballe@anonymised.com> wrote:
To follow up my last message, there does appear to be some precedent for Boolean (object) value with a bolean (primitive) getter setter:
In ResourceInfoImpl, we have advertised as a Boolean object with isAdvertised and setAdvertised returning/accepting a boolean primitive.
This appears to interact with the MetadataMap for backwards compatibility with 2.1.x series.
Torben
–
==
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.
On Thu, Mar 10, 2016 at 1:29 PM, Torben Barsballe <tbarsballe@anonymised.com> wrote:
Just for the sake of discussion, wondering if this could be made easier… XStream is using direct field access is it not?
Wondering if we could hide somehow the change by making it a Boolean, have getter and setter keep on using primitive,
and have some special logic in the REST api to transfer that property, by making it also do direct field access, or having
some side way accessor to get the Boolean… probably a bad/ugly idea, but maybe you can get a better one out
of it.
There are two things happening here - Xstream is making a new object from the request (using reflection), then we are using CatalogBuilder to copy all the non-null values to the catalog object. CatalogBuilder uses reflection/direct field access (via OwsUtils.copy).
So making the underlying object a Boolean but keeping the getters/setters primitive would work, but I agree it is a bit ugly.
Torben
On Thu, Mar 10, 2016 at 12:01 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:
On Thu, Mar 10, 2016 at 7:18 PM, Torben Barsballe <tbarsballe@anonymised.com> wrote:
Doing a REST PUT to the featuretypes endpoint will disablethe featuretype and all associated layers if the enabled flag is not set in the request. This breaks the intended functionality of PUT.
See https://osgeo-org.atlassian.net/browse/GEOS-7453 for more details on the issue.
I have a few questions about this issue:
a) is it already known? I was not able to find anything in JIRA or the docs, but it seems like the sort of thing that should have come up before.
Well known: https://osgeo-org.atlassian.net/browse/GEOS-3964
b) There is a simple fix - change all boolean primitives to Boolean objects in any REST-accessible catalog objects. However, this is API-breaking and could have unforseen consequences. Is such a fix viable?
Imho yes, seems the most sensible approach (as is).
Just for the sake of discussion, wondering if this could be made easier… XStream is using direct field access is it not?
Wondering if we could hide somehow the change by making it a Boolean, have getter and setter keep on using primitive,
and have some special logic in the REST api to transfer that property, by making it also do direct field access, or having
some side way accessor to get the Boolean… probably a bad/ugly idea, but maybe you can get a better one out
of it.
I would also like to note that this issue probably affects any REST-accessible catalog object that uses primitive values.
Yep
Cheers
Andrea
–
==
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.