I am mostly waiting on spare time to actually do it. I should be able to
get it done sometime this week.
Torben
On Sun, Mar 20, 2016 at 7:27 AM, Andrea Aime <[email protected]>
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 <
> [email protected]> 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
>>
>> 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.
>>>>
>>>> -------------------------------------------------------
>>>>
>>>
>>>
>>
>
>
> --
> ==
> 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=278785351&iu=/4140
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel