I'm going to revive this thread a bit as I'm now attempting to start work
on [GEOS-6811] <http://jira.codehaus.org/browse/GEOS-6811> and it seems
like we have multiple naming issues.
To summarize what I've gathered from this thread, it looks like the
following names need to be xml safe: featuretypes, workspaces. Everything
else, we want to be more lax. We just want to ensure the links in the REST
API are consistent/correct. Perhaps anything that is a valid file system
name and that does not contain spaces.
I'm not sure how all this will relate to colons in names. What about the
fix Jody suggested for invalid style names? Could that be something that's
done generally? A possibility we discussed was having a separate
NamesUtilities which would handle the validation/correction of invalid
names for these situations.
Is there a ticket for this issue, or should I create one? Probably linking
GEOS-6811 especially if the issue/fix is related.
On Fri, Jan 23, 2015 at 3:23 PM, Jody Garnett <jody.garn...@gmail.com>
wrote:
> Slightly related - or at least the fix is related. If we change how names
> are handled it is good to preserve backwards compatibility...
>
> Here was the fix proposed for migrating invalid style names forward while
> still allowing clients to function.
>
> What about a two stage transitional "fix":
>> a) During catalog load notice when a file uses invalid characters and
>> rename the data structure and file to use "_" in place of ":"|"&"|"!"|"~"
>> whatever...
>> b) When a style reference is parsed we can (in a similar fashion) replace
>> illegal characters with an "_"
>
>
>
> --
> Jody Garnett
>
> On 23 January 2015 at 13:49, David Winslow <dwins...@boundlessgeo.com>
> wrote:
>
>> This appears to be describing an unrelated bug. However, the URLEncoder
>> test that I proposed would also prohibit colons so, back to the drawing
>> board. Perhaps rather than try to ensure that encoding is not needed I
>> should review the REST API to make sure that decoding happens properly.
>> It's a little late in my day to start on such a review but I will
>> investigate next week to see how feasible this is.
>>
>> On Fri, Jan 23, 2015 at 4:34 PM, Jody Garnett <jody.garn...@gmail.com>
>> wrote:
>>
>>> Here is a lira covering a subset of this topic (references to workspace
>>> styles): http://jira.codehaus.org/browse/GEOS-6811
>>>
>>> --
>>> Jody Garnett
>>>
>>> On 22 January 2015 at 10:58, Andrea Aime <andrea.a...@geo-solutions.it>
>>> wrote:
>>>
>>>> On Thu, Jan 22, 2015 at 7:51 PM, David Winslow <
>>>> dwins...@boundlessgeo.com> wrote:
>>>>
>>>>> I think that adding "soft" validation for different services is going
>>>>> to be out of the scope of what I can do for this iteration. The goal here
>>>>> is not specifically to ensure that capabilities documents are valid but to
>>>>> make sure that the links in the REST API are correct/consistent. With
>>>>> this
>>>>> goal in mind I think an appropriate fix would be to validate by testing
>>>>> that the name url-encodes to itself rather than requiring it to be a valid
>>>>> XML element name. This should make the coverages with numeric prefixes
>>>>> valid again and resolve the issue that Andrea brings up.
>>>>>
>>>>
>>>> Yes, that sounds like a plan. I'd retain the xml validation for
>>>> workspaces/featuretypes, but it's just me.
>>>>
>>>>
>>>>>
>>>>> Jukka, the problem you cited with the Wicket form validating the *old*
>>>>> value does sound like it needs attention; I will try to correct that also.
>>>>>
>>>>
>>>> Great
>>>>
>>>> Cheers
>>>> Andrea
>>>>
>>>>
>>>> --
>>>> ==
>>>> GeoServer Professional Services from the experts! Visit
>>>> http://goo.gl/NWWaa2 for more information.
>>>> ==
>>>>
>>>> Ing. Andrea Aime
>>>> @geowolf
>>>> Technical Lead
>>>>
>>>> GeoSolutions S.A.S.
>>>> Via Poggio alle Viti 1187
>>>> 55054 Massarosa (LU)
>>>> Italy
>>>> 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.
>>>>
>>>> -------------------------------------------------------
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
>>>> GigeNET is offering a free month of service with a new server in
>>>> Ashburn.
>>>> Choose from 2 high performing configs, both with 100TB of bandwidth.
>>>> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
>>>> http://p.sf.net/sfu/gigenet
>>>> _______________________________________________
>>>> Geoserver-devel mailing list
>>>> Geoserver-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>>
>>>>
>>>
>>
>>
>> --
>> David Winslow
>> Software Engineer | Boundless <http://boundlessgeo.com/>
>> dwins...@boundlessgeo.com
>> 917-388-9085
>> @boundlessgeo <http://twitter.com/boundlessgeo/>
>>
>>
>>
>
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
--
Travis Brundage
Software Engineer | Boundless
tbrund...@boundlessgeo.com
250.888.2820
@boundlessgeo
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
