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

On Thu, Mar 10, 2016 at 1:29 PM, Torben Barsballe <
[email protected]> 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 <
> [email protected]> wrote:
>
>> On Thu, Mar 10, 2016 at 7:18 PM, Torben Barsballe <
>> [email protected]> 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.
>>
>> -------------------------------------------------------
>>
>
>
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Reply via email to